Objections Chris, > André, > > 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. > > +1 > > 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> >
PCI requires you to use TLS > 1.0 for new implementations starting last year with PCI 3.0. So if you add TLS because of PCI now (well too late IMO), you MUST NOT use TLS1.0 anymore . I do agree with you on the weakening of the requirements in 3.1 and 3.2, but of course there are also customers out there with devices that do not support TLS1.2. So if you want to be customer friendly and not block them before you even can get a message across, you may be content that the final call is only in 2018. My 2cts Peter --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
