OpenSSL Voluntarily (openssl-1.0.0a)
Hello. Does this affect python? Thank you. http://www.openssl.org/news/secadv_20101116.txt
On Mon, Nov 22, 2010 at 11:13 PM, Hirokazu Yamamoto < ocean-city@m2.ccsnet.ne.jp> wrote:
Hello. Does this affect python? Thank you.
No.
On Tue, 23 Nov 2010 00:07:09 -0500
Glyph Lefkowitz
On Mon, Nov 22, 2010 at 11:13 PM, Hirokazu Yamamoto < ocean-city@m2.ccsnet.ne.jp> wrote:
Hello. Does this affect python? Thank you.
No.
Well, actually it does, but Python links against the system OpenSSL on most platforms (except Windows), so it's up to the OS vendor to apply the patch. Regards Antoine.
On Nov 23, 2010, at 9:02 AM, Antoine Pitrou wrote:
On Tue, 23 Nov 2010 00:07:09 -0500 Glyph Lefkowitz
wrote: On Mon, Nov 22, 2010 at 11:13 PM, Hirokazu Yamamoto < ocean-city@m2.ccsnet.ne.jp> wrote:
Hello. Does this affect python? Thank you.
No.
Well, actually it does, but Python links against the system OpenSSL on most platforms (except Windows), so it's up to the OS vendor to apply the patch.
It does? If so, I must have misunderstood the vulnerability. Can you explain how it affects Python?
Le mardi 23 novembre 2010 à 20:56 -0500, Glyph Lefkowitz a écrit :
On Nov 23, 2010, at 9:02 AM, Antoine Pitrou wrote:
On Tue, 23 Nov 2010 00:07:09 -0500 Glyph Lefkowitz
wrote: On Mon, Nov 22, 2010 at 11:13 PM, Hirokazu Yamamoto < ocean-city@m2.ccsnet.ne.jp> wrote:
Hello. Does this affect python? Thank you.
No.
Well, actually it does, but Python links against the system OpenSSL on most platforms (except Windows), so it's up to the OS vendor to apply the patch.
It does? If so, I must have misunderstood the vulnerability. Can you explain how it affects Python?
If I believe the link above: “Any OpenSSL based TLS server is vulnerable if it is multi-threaded and uses OpenSSL's internal caching mechanism. Servers that are multi-process and/or disable internal session caching are NOT affected.” So, you just have to create a multithreaded TLS server which doesn't disable server-side session caching (it is enabled by default according to http://www.openssl.org/docs/ssl/SSL_CTX_set_session_cache_mode.html ) Regards Antoine.
On 08:02 am, solipsis@pitrou.net wrote:
Le mardi 23 novembre 2010 � 20:56 -0500, Glyph Lefkowitz a �crit :
On Nov 23, 2010, at 9:02 AM, Antoine Pitrou wrote:
On Tue, 23 Nov 2010 00:07:09 -0500 Glyph Lefkowitz
wrote: On Mon, Nov 22, 2010 at 11:13 PM, Hirokazu Yamamoto < ocean-city@m2.ccsnet.ne.jp> wrote:
Hello. Does this affect python? Thank you.
No.
Well, actually it does, but Python links against the system OpenSSL on most platforms (except Windows), so it's up to the OS vendor to apply the patch.
It does? If so, I must have misunderstood the vulnerability. Can you explain how it affects Python?
If I believe the link above: 1CAny OpenSSL based TLS server is vulnerable if it is multi-threaded and uses OpenSSL's internal caching mechanism. Servers that are multi-process and/or disable internal session caching are NOT affected. 1D
So, you just have to create a multithreaded TLS server which doesn't disable server-side session caching (it is enabled by default according to http://www.openssl.org/docs/ssl/SSL_CTX_set_session_cache_mode.html )
Hm. The session cache is enabled by default, but nothing will ever use it unless the server specifies a session id using SSL_set_session_id_context or SSL_CTX_set_session_id_context. Python doesn't expose these, so I don't think any Python SSL server can set them. The vulnerability announcement isn't 100% clear on this, but I took a look at the patch which fixes the issue and it /appears/ as though if a client never tries to re-use a session then you will be safe from this bug. However, perhaps this only means that only malicious clients (which send a session id even when they can't actually have one) will be able to trigger the bug. Or I may misunderstand how SSL sessions work in OpenSSL entirely. The documentation for them is on par with that for most of the rest of OpenSSL. Jean-Paul
On Wed, 24 Nov 2010 15:01:06 -0000 exarkun@twistedmatrix.com wrote:
If I believe the link above: 1CAny OpenSSL based TLS server is vulnerable if it is multi-threaded and uses OpenSSL's internal caching mechanism. Servers that are multi-process and/or disable internal session caching are NOT affected. 1D
So, you just have to create a multithreaded TLS server which doesn't disable server-side session caching (it is enabled by default according to http://www.openssl.org/docs/ssl/SSL_CTX_set_session_cache_mode.html )
Hm. The session cache is enabled by default, but nothing will ever use it unless the server specifies a session id using SSL_set_session_id_context or SSL_CTX_set_session_id_context. Python doesn't expose these, so I don't think any Python SSL server can set them.
Well, Python calls SSL_CTX_set_session_id_context() implicitly, starting from 3.2 (precisely so that the session cache gets used). The "documentation" I've found about the "session id context" seems to suggest that a process-wide constant is enough. (and you can verify that caching occurs using the new SSLContext.session_stats() method)
Or I may misunderstand how SSL sessions work in OpenSSL entirely. The documentation for them is on par with that for most of the rest of OpenSSL.
Agreed. Regards Antoine.
On 03:11 pm, solipsis@pitrou.net wrote:
On Wed, 24 Nov 2010 15:01:06 -0000 exarkun@twistedmatrix.com wrote:
If I believe the link above: 1CAny OpenSSL based TLS server is vulnerable if it is multi-threaded
and
uses OpenSSL's internal caching mechanism. Servers that are multi-process and/or disable internal session caching are NOT affected. 1D
So, you just have to create a multithreaded TLS server which doesn't disable server-side session caching (it is enabled by default according to http://www.openssl.org/docs/ssl/SSL_CTX_set_session_cache_mode.html )
Hm. The session cache is enabled by default, but nothing will ever use it unless the server specifies a session id using SSL_set_session_id_context or SSL_CTX_set_session_id_context. Python doesn't expose these, so I don't think any Python SSL server can set them.
Well, Python calls SSL_CTX_set_session_id_context() implicitly, starting from 3.2 (precisely so that the session cache gets used). The "documentation" I've found about the "session id context" seems to suggest that a process-wide constant is enough.
Ah. Okay, then Python 3.2 would be vulnerable. Good thing it isn't released yet. ;) Jean-Paul
On 2010/11/25 1:23, exarkun@twistedmatrix.com wrote:
Ah. Okay, then Python 3.2 would be vulnerable. Good thing it isn't released yet. ;)
It seems OpenSSL 1.0.0c out. http://openssl.org/news/secadv_20101202.txt
02-Dec-2010: Security Advisory: ciphersuite downgrade fix 02-Dec-2010: OpenSSL 1.0.0c is now available, including important bug and security fixes 02-Dec-2010: OpenSSL 0.9.8q is now available, including important bug and security fixes
Am 09.12.2010 13:49, schrieb Hirokazu Yamamoto:
On 2010/11/25 1:23, exarkun@twistedmatrix.com wrote:
Ah. Okay, then Python 3.2 would be vulnerable. Good thing it isn't released yet. ;)
It seems OpenSSL 1.0.0c out.
http://openssl.org/news/secadv_20101202.txt
02-Dec-2010: Security Advisory: ciphersuite downgrade fix 02-Dec-2010: OpenSSL 1.0.0c is now available, including important > bug and security fixes 02-Dec-2010: OpenSSL 0.9.8q is now available, including important > bug and security fixes
I don't plan upgrading the Windows build before 3.2; I have already patched the OpenSSL copy that we use. Regards, Martin
participants (5)
-
"Martin v. Löwis"
-
Antoine Pitrou
-
exarkun@twistedmatrix.com
-
Glyph Lefkowitz
-
Hirokazu Yamamoto