vulnerability in SSL v3

Described here: http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html and here: http://chat.stackexchange.com/transcript/message/18153650#18153650

I am not sure what implications this has for requests (potentially none) but it is a good idea to look at it.


## I'm 100% in favor of forcing double checking that we don't use this by default and disabling it if we do

Sent from my Android device with K-9 Mail. Please excuse my brevity.


Checking now.

## 

Kevin Burke
phone: 925.271.7005 | twentymilliseconds.com

On Tue, Oct 14, 2014 at 4:04 PM, Ian Cordasco notifications@github.com
wrote:

> I'm 100% in favor of forcing double checking that we don't use this by
> 
> ## default and disabling it if we do
> 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> 
> —
> Reply to this email directly or view it on GitHub
> https://github.com/kennethreitz/requests/issues/2283#issuecomment-59131916
> .


I'm not sure that not using it by default is enough - if an attacker can interrupt the TLS v1 protocol and force the connection to downgrade to ssl v3, it's enough to read the plaintext.

I am not sure how to test this but I am reading through the code to try and understand it. Would appreciate some help from @t-8ch @alex @reaperhulk @dreid .. :)


This is such a PITA for requests, we'll break a lot of people's stuff when we do this.

We should disable by default (as in OP_NO_SSLV3), but we need to have a good way to turn that limitation off.


The attacker also needs the means to control the data the client sends. Which is quite a big 'if' for users of requests, I think.


@t-8ch I haven't read up on POODLE yet: are cookies enough?


Also, really what we actually want is people to use versions of OpenSSL new enough to support `TLS_FALLBACK_SCSV`.


Note also that this approach is _more_ extreme than what Chrome have done. From [Adam Langley's blog post](https://www.imperialviolet.org/2014/10/14/poodle.html):

> The changes that I've just landed in Chrome only disable fallback to SSLv3 – a server that correctly negotiates SSLv3 can still use it.

Now, they do plan to remove SSLv3 entirely:

> A little further down the line, perhaps in about three months, we hope to disable SSLv3 completely.

But that's Chrome, and they support a fundamentally different use-case from us. We need to be extremely careful about what we do here and how we expose it, because this will break a lot of people's code and we _will_ get complaints.


Personally I'd rather be secure than backwards compatible with a broken protocol by default 


Sure, but that breaks people's stuff. We have to accept that, and behave appropriately. We also need a fairly easy (e.g. transport adapter) way of turning it back on.


Comment away at https://github.com/shazow/urllib3/issues/487


For the record `TLS_FALLBACK_SCSV` has zero use for requests or Python except as a server. TLS has secure negotiation of the highest protocol version. However browsers, trying to be more compatible than secure, work around this secure negotiation and implement an _insecure_ negotiation. `TLS_FALLBACK_SCSV` is an extension to TLS that attempts to make their version of negotiation secure against downgrade attacks.