Now that a new SSL vulnerability is out (http://extendedsubset.com/?p=8) should we regenerate binary distributions that include copies of openssl (I think only the Windows MSIs) ? Does it affect any of our ssl APIs? -- --Guido van Rossum (python.org/~guido)
On Fri, Nov 6, 2009 at 3:22 PM, Guido van Rossum <guido@python.org> wrote:
Now that a new SSL vulnerability is out (http://extendedsubset.com/?p=8) should we regenerate binary distributions that include copies of openssl (I think only the Windows MSIs) ?
Does it affect any of our ssl APIs?
-- --Guido van Rossum (python.org/~guido)
The proposal on the table is to add a TLS extension that takes care of the problem, leave clients unchanged, and to stop servers from rehandshaking with clients that don't support the extension. AFAICS, that's all supposed to be handled by openssl. Certainly the EVP stuff won't need to be modified. The version of openssl being distributed should definitely be brought up to 0.9.8l though. Geremy Condra
Guido, I'm working from <http://extendedsubset.com/Renegotiating_TLS.pdf>. I believe geremy is right. The current SSL module does not expose much of the SSL API, so servers implemented in Python, using it, should (fortuituously) be immune to the some of the attacks outlined, simply because there's no way to do an application-initiated renegotiation, which the first two scenarios presuppose. On the other hand, there's no way to do application-directed session resumption, either, which might be a good add to support new or updated application protocols which address this problem. So I think there's not much we can do in Python source code to address this, unless there's a switch we can throw in the existing OpenSSL API to turn off renegotiation completely. I'll look, and I'll talk this over with our security group. Building binaries with newer versions of OpenSSL is pretty much always a good idea, it seems to me. More generally, this is a nice description of how simply layering TLS onto existing application protocols like HTTP doesn't always work very well. Bill
On 10:18 pm, janssen@parc.com wrote:
Guido,
I'm working from <http://extendedsubset.com/Renegotiating_TLS.pdf>.
I believe geremy is right. The current SSL module does not expose much of the SSL API, so servers implemented in Python, using it, should (fortuituously) be immune to the some of the attacks outlined, simply because there's no way to do an application-initiated renegotiation, which the first two scenarios presuppose. On the other hand, there's no way to do application-directed session resumption, either, which might be a good add to support new or updated application protocols which address this problem.
Also, for Python 2.5 and earlier, any SSL-based code is vulnerable to a MitM anyway, so this can only be an issue for code using the new APIs in Python 2.6. Jean-Paul
On Fri, Nov 6, 2009 at 2:36 PM, <exarkun@twistedmatrix.com> wrote:
Also, for Python 2.5 and earlier, any SSL-based code is vulnerable to a MitM anyway, so this can only be an issue for code using the new APIs in Python 2.6.
That's not going to stop the wannabe-self-proclaimed-so-called-vulnerability-"experts" from whining about Python not releasing updated binary distributions though. :-( -- --Guido van Rossum (python.org/~guido)
Also, for Python 2.5 and earlier, any SSL-based code is vulnerable to a MitM anyway, so this can only be an issue for code using the new APIs in Python 2.6.
That's not going to stop the wannabe-self-proclaimed-so-called-vulnerability-"experts" from whining about Python not releasing updated binary distributions though. :-(
The Windows binaries currently build with 0.9.8g. Since changing that would be a source code change (even though just a single line), I think a full source release would be necessary (most likely then for both 2.6 and 3.1). Regards, Martin
On Nov 8, 2009, at 12:56 PM, Martin v. Löwis wrote:
Also, for Python 2.5 and earlier, any SSL-based code is vulnerable to a MitM anyway, so this can only be an issue for code using the new APIs in Python 2.6.
That's not going to stop the wannabe-self-proclaimed-so-called-vulnerability-"experts" from whining about Python not releasing updated binary distributions though. :-(
The Windows binaries currently build with 0.9.8g. Since changing that would be a source code change (even though just a single line), I think a full source release would be necessary (most likely then for both 2.6 and 3.1).
I don't think it's worth making a quick 2.6.5 release for this if it's primary intent is to produce new Windows binaries. I'm okay with making the changes to the tree, but we'll release 2.6.5 on a "normal" schedule. -Barry
Barry Warsaw wrote:
I don't think it's worth making a quick 2.6.5 release for this if it's primary intent is to produce new Windows binaries. I'm okay with making the changes to the tree, but we'll release 2.6.5 on a "normal" schedule.
Perhaps publish a source patch relative to 2.6.4 for people that would like to rebuild their own Windows binaries with just that change? Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
On Nov 10, 2009, at 8:28 AM, Nick Coghlan wrote:
Barry Warsaw wrote:
I don't think it's worth making a quick 2.6.5 release for this if it's primary intent is to produce new Windows binaries. I'm okay with making the changes to the tree, but we'll release 2.6.5 on a "normal" schedule.
Perhaps publish a source patch relative to 2.6.4 for people that would like to rebuild their own Windows binaries with just that change?
+1. A link to that could easily go on the 2.6.4 page. Perhaps the right way to do it is to put the blessed patch in roundup and add a link to that patch file on the website. -Barry
Guido van Rossum schrieb:
On Fri, Nov 6, 2009 at 2:36 PM, <exarkun@twistedmatrix.com> wrote:
Also, for Python 2.5 and earlier, any SSL-based code is vulnerable to a MitM anyway, so this can only be an issue for code using the new APIs in Python 2.6.
That's not going to stop the wannabe-self-proclaimed-so-called-vulnerability-"experts" from whining about Python not releasing updated binary distributions though. :-(
Yet it has been quiet on the Finnish front so far :) Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
participants (8)
-
"Martin v. Löwis" -
Barry Warsaw -
Bill Janssen -
exarkun＠twistedmatrix.com -
Georg Brandl -
geremy condra -
Guido van Rossum -
Nick Coghlan