© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
7020100
(Get the code!)
See this issue to drop RC4 support in the Chromium project: https:/
Lots of good discussion but especially comment #44, #49, and perhaps the real key takeaway is comment #53:
------ quote ------
#53 <email address hidden>
On the topic of PCI and CVSS scores, I talked with a QSA. Because of the 4.3 scores and general badness, PCI 3.1 was released recently and marks TLS 1.0 and below as unacceptable. Anyone wanting to use it must document a Risk Mitigation and Migration Plan. Which people do by saying "We have clients who haven't upgraded." But in newly deployed infrastructure the PCI Council is actually saying that they can't deploy TLS 1.0 or below at all, and to strand any older clients.
I don't imagine this significantly affects opinions on UI treatment (including keeping the EV badging), but wanted to add some context I learned today.
See also: https:/
------ end quote------
Thus, if openjdk-6 and -7 continue to send a TLSv1.0 ClientHello by default, they soon risk losing connectivity to significant portions of the secure WWW. As a PCI compliant shop, this is already an issue here and we have some upcoming deadlines to make some changes.
At the moment, I have seen 3 specific examples of broken connectivity:
(1) web service gateway for an airline reservation system which refuses to negotiate CBC unless protocol level is TLSv1.1 or newer. This site is behind a source-IP based packet filter so I can't have anyone else test against it.
(2) The public-facing internet-booking website for an airline (VA), which refuses to negotiate CBC at all, even on TLSv1.2, and does not support AEAD ciphers. The only option for this one is RC4
(3) The SOAP service endpoint for a payment service provider; this one is a lot like (2) - only RC4. This is also behind a source IP filter
Tiago, under the circumstances, what kind of test code would you like to see? It is not possible to write a pure-Java test client and server which mimics the behavior of example (1), because an SSLServerSocket only enables/disables cipher suites globally across all protocol levels.
I'm not sure what can responsibly be done about examples like (2) and (3), but it seems probably that sites like example (1) will become more common.