Disabling SSLv3 for 2.10.10?

Daniel Atallah daniel.atallah at gmail.com
Thu Oct 16 14:52:59 EDT 2014

On Thu, Oct 16, 2014 at 2:26 PM, Mark Doliner <mark at kingant.net> wrote:

> Is POODLE a problem for us? I got the impression that it's not. It
> seems like it's an information leak that is only possible if the
> attacker can cause Pidgin to send many slightly different SSL/TLS
> requests. For browsers this happens if an active MITM injects
> javascript into an http response and the malicious javascript makes
> many custom https requests. I can't think of a scenario for how that
> might happen within Pidgin.

My understanding is that the attack is mostly the fact that by forcing a
downgrade from TLS 1.0 to SSLv3, you can use the vulnerabilities in the
SSLv3 ciphers to steal information.

You're right that the impact is probably less for us since there likely
won't be large numbers of requests to use to use for the stealing process,
but for chatty protocols which initiate lots of new connections (e.g. the
campfire third-party prpl and to a lesser extent yahoo) there's still some

> I agree that it would be nice to disable SSLv3 (or give people the
> ability to do it via a hidden pref)(FYI I disabled it for GnuTLS in
> default), but I'm worried about making this change immediately before
> releasing.

This is really the crux of it - we pretty much don't need SSLv3 support.
I guess I'd prefer to include the flag even if we make the default value
not to disable SSLv3 and add a UI preference to do so if we're not
comfortable doing it by default.

I'm pretty comfortable with the NSS change so far, and assuming that I can
come up with an acceptable fix for NSS < 3.14, I don't think it should be
all that controversial.

I'd appreciate someone familiar with gnutls taking a look at and testing
that stuff and evaluating confidence in those changes.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pidgin.im/cgi-bin/mailman/private/security/attachments/20141016/9113cd5c/attachment.html>

More information about the security mailing list