According to wikipedia: http://en.wikipedia.org/wiki/Transport_Layer_Security
Seems like TLS is a replacement to SSL, but most websites are still using SSL?
A:
"If it ain't broken, don't touch it". SSL3 works fine in most scenarios (there was a fundamental flaw found in SSL/TLS protocol back in October, but this is a flaw of applications more than of a procol itself), so developers don't hurry to upgrade their SSL modules. TLS brings a number of useful extensions and security algorithms, but they are handy addition and not a must. So TLS on most servers remains an option. If both server and client support it, it will be used.
Eugene Mayevski 'EldoS Corp
2010-09-11 12:16:56
No, this is a protocol flaw, and developers should upgrade their SSL stacks. This being said, there are guidelines for using the renegotiation extension in [RFC 5746](http://tools.ietf.org/html/rfc5746) for SSLv3, in addition for the ones for TLS.
Bruno
2010-09-12 01:02:28
If you kill somebody with the knife, this is not knife's flaw, but the one of your brain. Same here. If the protocol was used in the way it was not designed for, it's not a flaw of the protocol.
Eugene Mayevski 'EldoS Corp
2010-09-12 12:37:00
The protocol was designed in a way that application on top of it should treat it as a normal socket as much as possible. The renegotiation issue, without the new extension, forces awareness by the application layer (e.g. HTTP). There is an interested thread on this topic on the IETF TLS mailing list: http://www.ietf.org/mail-archive/web/tls/current/msg04000.html
Bruno
2010-09-12 22:51:28
Exactly. Renegotiation is a special case that requires the application-level protocol to know about it (this case). So it's a problem of the application-level protocol if it explicitly used renegotiation.
Eugene Mayevski 'EldoS Corp
2010-09-13 07:03:29
I agree some of it should be done at the application level, but I'm not aware of any implementation and protocol takes that into account. The stacks can usually cope with renegotiation that they initiate legitimately, but not so much if a MITM initiates it (which is the problem). That's why the IETF TLS group chose to fix it at the TLS level, and that's also why people really should switch on that extension, or disable renegotiation altogether.
Bruno
2010-09-13 09:33:07
+2
A:
In short, TLSv1.0 is more or less SSLv3.1. You can find more details in this question on ServerFault.
Most websites actually support both SSLv3 and TLSv1.0 at least, as this study indicates (Lee, Malkin, and Nahum's paper: Cryptographic Strength of SSL/TLS Servers: Current and Recent Practices, IMC 2007) (link obtained from the IETF TLS list). More than 98% support TLSv1+.
I think the reason why SSLv3 is still in use was for legacy support (although most browsers support TLSv1 and some TLSv1.1 or even TLSv1.2 nowadays). Until not so long ago, some distributions still had SSLv2 (considered insecure) on by default along with the others.
(You may also find this question interesting, although it's about the usage pattern of TLS rather than SSL vs. TLS (you could in fact have the same pattern with SSL). This does not apply to HTTPS anyway, since HTTPS uses SSL/TLS from the beginning of the connection.)
Bruno
2010-09-12 00:55:25