New version of OpenSSL released - OpenSSL 0.9.8l

New version of OpenSSL released - OpenSSL 0.9.8l
Due to the recent publishing of information regarding a TLS/SSL protocol vulnerability (previous ISC diary entry can be found here http://isc.sans.org/diary.html?storyid=7534) OpenSSL has released a new version (OpenSSL 0.9.8l). It should be noted that this update does not "fix" the vulnerability in the protocol. It appears that they have made the choice to simply remove TLS/SSL renegotiation from their package by default. I would urge anyone who is running a SSL enabled site that uses OpenSSL to thoroughly test their application as well as any software clients that are in used with their application. There has been some discussion on the effects of simply removing renegotiation from these packages or disabling them by default (as OpenSSL has done). There will no doubt be instances where clients/servers will cease to function properly when renegotiation is disabled or removed. The nice thing about what OpenSSL has done is if you do run into issues, it appears to be an easy fix (set a flag and -hup!). So as always make sure to test vigorously before you deploy! You can get this new version of OpenSSL at the link below. http://www.openssl.org/source/ Release note from OpenSSL package: Disable renegotiation completely - this fixes a severe security problem (CVE-2009-3555) at the cost of breaking all renegotiation. Renegotiation can be re-enabled by setting SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION in s3->flags at run-time. This is really not recommended unless you know what you're doing. [Ben Laurie] This event will no doubt develop over the next coming weeks and months, it should be interesting to see how far research goes into other protocols that ride on top of TLS/SSL channels. Let us not forget that not all traffic that is TLS/SSL encrypted is HTTP. Just off the top of my head I can think of LDAP, MSSQL, Email, and let us not forget SSL VPNS! Since this is a bug in a low lying protocol that higher level applications/protocols rely on there will no doubt be allot of interest issues raised. No doubt plenty of people including myself will have a busy weekend rereading the TLS specification. For those who are bored, feel free to read that specification at the URL below. TLS 1.0: http://www.ietf.org/rfc/rfc2246.txt SSL 3.0: http://tools.ietf.org/html/draft-ietf-tls-ssl-version3-00 Andre Ludwig	AndreL 56 Posts Nov 6th 2009
Thread locked Subscribe	Nov 6th 2009 1 decade ago
"It appears that they have made the choice to simply remove TLS/SSL negotiation" Should "negotiation" be "renegotiation"?	Anonymous
Quote	Nov 6th 2009 1 decade ago
Whoops, good eye not sure how I missed that one. Thanks for spotting that.	AndreL 56 Posts
Quote	Nov 6th 2009 1 decade ago

Due to the recent publishing of information regarding a TLS/SSL protocol vulnerability (previous ISC diary entry can be found here http://isc.sans.org/diary.html?storyid=7534) OpenSSL has released a new version (OpenSSL 0.9.8l). It should be noted that this update does not "fix" the vulnerability in the protocol. It appears that they have made the choice to simply remove TLS/SSL renegotiation from their package by default. I would urge anyone who is running a SSL enabled site that uses OpenSSL to thoroughly test their application as well as any software clients that are in used with their application. There has been some discussion on the effects of simply removing renegotiation from these packages or disabling them by default (as OpenSSL has done). There will no doubt be instances where clients/servers will cease to function properly when renegotiation is disabled or removed. The nice thing about what OpenSSL has done is if you do run into issues, it appears to be an easy fix (set a flag and -hup!). So as always make sure to test vigorously before you deploy!

You can get this new version of OpenSSL at the link below.

http://www.openssl.org/source/

Release note from OpenSSL package:

    Disable renegotiation completely - this fixes a severe security
    problem (CVE-2009-3555) at the cost of breaking all
    renegotiation. Renegotiation can be re-enabled by setting
    SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION in s3->flags at
    run-time. This is really not recommended unless you know what
    you're doing.
    [Ben Laurie]

This event will no doubt develop over the next coming weeks and months, it should be interesting to see how far research goes into other protocols that ride on top of TLS/SSL channels. Let us not forget that not all traffic that is TLS/SSL encrypted is HTTP. Just off the top of my head I can think of LDAP, MSSQL, Email, and let us not forget SSL VPNS! Since this is a bug in a low lying protocol that higher level applications/protocols rely on there will no doubt be allot of interest issues raised. No doubt plenty of people including myself will have a busy weekend rereading the TLS specification. For those who are bored, feel free to read that specification at the URL below.

TLS 1.0: http://www.ietf.org/rfc/rfc2246.txt

SSL 3.0: http://tools.ietf.org/html/draft-ietf-tls-ssl-version3-00

Andre Ludwig

AndreL