That shot you heard? SSLv3 is now DEAD We really, really, really mean it this time: take SSL3 and bury it. That's the message from the home of all things Internet the Internet Engineering Task Force, which has issued the “take it behind the shed” edict in this RFC. It's actually only formalising what the IETF and industry already knew: SSLv3 is ancient and …
Great.
Can someone tell banks and places like TP Online whose instructions state that you have to use IE ("7 or above") and that you have to have SSL 3.0 enabled, and that you have to download your ultra-secure client certificate to use with the service via an SSL 3.0 webpage that fails verification in most modern browsers anyway, and only with that cert installed in your personal trust store can you connect back to their website in order to log in with credentials anyway and do things like, say, pay Teacher's Pensions or do List 99 checks on staff.
Cos that would be great.
Can someone tell banks and places like TP Online
With a bit of luck the lawyers will wake up to the problem of liability through negligence. By formally declaring SSLv3 dead and buried, and by refusing any connections from the grave there is no credible argument that anyone still relying on this code is doing anything at all for security.
This means that when problems appear it's not just consequential liability, it is also likely to attract regulatory fines as well. Personally, I think the way to fix this is to make banker bonuses payable to any victims - I reckon it would turn the City into a powerhouse of cybersecurity in, umm, a week, tops :)
Unlikely.
TP Online are still vulnerable to a vast range of ancient attacks for years and nothing's been done:
https://www.ssllabs.com/ssltest/analyze.html?d=tponline.co.uk
(Hell, it still supports SSL 2.0! That's possibly the lowest score I've ever seen in my life on SSL Labs!)
The instructions given still MUST be completed in IE 7 or above (and you can't use anything but XP or 7), the process is a faff, the signup site still gets validation errors in every other browser, and at the end of it this is used for vast amounts of Teacher's Pensions and (in some cases compulsory) security checks for teachers nationwide and has for many years, unchanged (the instructions they supply have not changed for 3 years at least).
The site is backed by BT TrustWise, Symantec, etc. and has been unchanged for several years.
The TP Online server does not exhibit any unusual properties, and there are *NO* server vulnerabilities visible in the SSL Labs Scan.
https://www.ssllabs.com/ssltest/analyze.html?d=tponline.co.uk
What this server does not provide is numerous mitigations for common and stupid Client / Browser bugs. But fixing (or not ever implementing) these stupid client side bugs is the jobs of those implementing the clients, not of those running servers and trying to offer good interop.
The design of the SSLv3 and TLS protocol will protect the handshake between properly implemented clients and properly implemented servers. BEAST and POODLE are attacks on Browsers exploiting browser design flaws.
>there are *NO* server vulnerabilities visible in the SSL Labs Scan.
When I go to that link, it tells me that --
"This server supports SSL 2, which is obsolete and insecure. Grade set to F. "
Along with a string of other grade B and grade C failures.
If only there was a way to shame companies into upgrading their security promptly.
Bank of Scotland online, for example, is still using TLS1.0 [not exactly the same as SSLv3, but not far enough removed to be considered significantly more secure] for all it's banking activity.
What are they thinking?
If you try and email their support line, you get an auto-reply which begins, "Thank you for alerting us to the suspicious e-mail you have received."
Pathetic.
How can one of the big national banks (part of Lloyds Group these days) have the temerity to operate like this?
SSLv3 is neither broken nor insecure. It actually provides *ALL* security guarantees described for TLSv1.2 in Appendix F of rfc5246:
https://tools.ietf.org/html/rfc5246#appendix-F
Appendix F. Security Analysis
The TLS protocol is designed to establish a secure connection between
a client and a server communicating over an insecure channel. This
document makes several traditional assumptions, including that
attackers have substantial computational resources and cannot obtain
secret information from sources outside the protocol. Attackers are
assumed to have the ability to capture, modify, delete, replay, and
otherwise tamper with messages sent over the communication channel.
This appendix outlines how TLS has been designed to resist a variety
of attacks.
The real problem with SSLv3 is, that what Web Browsers (and so called SSL VPNs) are doing goes beyond the design limits of SSLv3 (and that of TLSv1.2, mind you), and in some of those areas _outside_the_official_TLS_design_limits_ explored by Web Browsers and SSL VPNs, TLSv1.2 avoids some of the problems of SSLv3.
For those who didn't know, TLSv1.2 has its own security goofs, where it falls behind SSLv3. One is the weak digitally-signed, which replaces a 272-bit hash in an RSA digital signature with a much weaker 160-bit hash (sha1), rather than carrying through what has been working just fine for more than a decade as the minimum digital signature security level.
>The real problem with SSLv3 is, that what Web Browsers (and so called SSL VPNs) are doing goes beyond the design limits of SSLv3
Cryptographic protocols can't be considered in isolation. They exist for the applications which use them.
To say that SSLv3 is secure and it's the web browsers which are broken because they allow client side scripting is a bit like saying that your feet are the wrong size for your shoes.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
