tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Tomcat 8 HTTPS issue with old browser
Date Tue, 04 Oct 2016 20:33:31 GMT
Hash: SHA256


On 10/4/16 7:59 AM, André Warnier (tomcat) wrote:
> On 04.10.2016 12:43, Garratt, Dave wrote:
>> To elaborate, there is only this single application running on
>> the server. All other web applications use Windows IIS.
>> I have mentioned that the problem is down to the old software on
>> the scanner but it’s a huge international organisation and making
>> a upgrade to their entire line of devices is likely to take some
>> time.
>> However silly it may seem this is a “tick the box” exercise when
>> it comes to security - HTTPS - yes/no.
>> On the assumption that a weak encryption is better than none then
>> I can’t really argue with the customer.
> Maybe you cannot argue with the customer, that is for your
> commercial environment to decide.  But on the professional ethics
> side of thing, I would disagree with you on the previous item.  A
> weak encryption can be worse than none, because it gives a false
> sense of security. It may lead the customer to think that he is
> protected, when in reality he is not. And it may be your duty as a
> technical adviser, to point this out.


Weak encryption is *worse* than no encryption IMO. You can argue about
the definition of "weak", of course.

SSLv2 is definitely weak. A NULL symmetric cipher is definitely weak.
Is RSA key negotiation weak? I think reasonable people can disagree
over that, but I won't deploy it on any production machine unless
there are no alternatives.

Since this is a barcode reader, it's unlikely that there are any
problems with *confidentiality* of the data being transmitted. If you
have to login to a "secure" server before reading barcodes, then you
may have to consider the secrecy of the credentials for authentication
even when the majority of the traffic will be non-private.

Assuming the confidentiality isn't a problem, then the only reasons to
use encryption are authentication (of the server by the client) and
integrity (to prove that nobody has meddled with the message).

If RSA authentication is good enough (and for most people, it is) and
there are no issues with the authentication protocol (none that I can
think of off the top of my head), then the differences between e.g.
SSLv3 and TLSv1.2 are not that great.

That's a lot of "ifs".

It's also possible to use RSA authentication in a weak way. For some
reason, Microsoft servers seem to be plagued by these issues in
particular. 1024-bit RSA keys (and thus the certificates produced with
them) have been deemed insecure for quite some time and I won't
personally use a 2048-bit key for anything anymore. If the MC9090
can't support keys of a certain length (I know of no SSL
implementation that complains about "large" RSA keys) then you may not
be able to get authentication (that the server is trusted by the
client, that is) that is trustworthy.

If you are covered by PCI-DSS then you MUST NOT use anything less than
TLSv1.1 by ... wow, it's still 2 years away. [0] At least NIST
deprecated the use of TLSv1 and earlier effective *immediately*. Of
course, it just says "you shouldn't use these", it doesn't say you
MUST NOT use these. Oh, well. At least Google has the temerity to
force changes on the Internet even if standards bodies won't keep
pace. It doesn't matter if it's not a regulatory requirement if none
of your users will visit your site unless you get serious about security

Just some food for thought.

- -chris

[0] Nice job, PCI-DSS... you were going to drive the industry forward
until the industry cried like a bunch of babies about how they had
large investments in crappy products and they didn't want to pay
actual money to upgrade them. Better to swap fictional assets at
ever-increasing margins pretending to make money to drive the stock
price up. Heaven forbid you actually do something to protect
yourselves, your shareholders, and your customers. </soapbox>
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message