Support Certificate Revocation Lists where possible

In 3.4 the standard library's previously woeful `ssl` module is being vastly improved, and one of the nice things it is getting is [support for Certificate Revocation Lists](http://docs.python.org/3.4/library/ssl.html#ssl.SSLContext.load_verify_locations). I'd like us to investigate supporting CRLs in versions of Python where they are available. If we can do this, it'll continue the ongoing trend of Requests being the single most secure way to do HTTP in Python.

It's highly probable that this will need to be a two-pronged approach: urllib3 will probably want to support some genericised CRL options, with Requests pasting over the genericness with a built-in "correct" behaviour. For that reason, I want to start a discussion with the relevant people to work out how we can do this.

Requests people: @kennethreitz, @sigmavirus24
urllib3 people: @shazow 
Our SSL guy: @t-8ch.

People who might be interested in either helping or providing insight and code review (to make sure we don't get this wrong) are @tiran (heavily involved with the standard library's `ssl` module) and @alex (currently on a big crypto kick). If either of you two are actually not interested that's totally fine. =)

Initial views: how should we split this work up, and how safe can Requests' defaults be?


Also, which version(s) of python are we targetting? Just 3.4? Perhaps the better question to ask is: "Which version(s) of Python can we reasonably target?" Is 2.6 an option?


With the standard library we're limited to 3.4.


With the caveat that I know nothing of how the CRLs have been (or should be) implemented, is there no possible way to backport them via a package like certifi?


I don't _think_ so. I'm pretty sure that we need to pass the [`VERIFY_CRL_CHECK_CHAIN`](http://docs.python.org/3.4/library/ssl.html#ssl.VERIFY_CRL_CHECK_CHAIN) to the [`SSLContext.verify_flags`](http://docs.python.org/3.4/library/ssl.html#ssl.SSLContext.verify_flags). That option was only added in 3.4, so unless we think we can work around that I don't think OpenSSL will check the CRLs.


Correct! You need to set that option.

I'm currently traveling and will reply in a couple of days.

Cory Benfield notifications@github.com schrieb:

> I don't _think_ so. I'm pretty sure that we need to pass the
> [`VERIFY_CRL_CHECK_CHAIN`](http://docs.python.org/3.4/library/ssl.html#ssl.VERIFY_CRL_CHECK_CHAIN)
> to the
> [`SSLContext.verify_flags`](http://docs.python.org/3.4/library/ssl.html#ssl.SSLContext.verify_flags).
> That option was only added in 3.4, so unless we think we can work
> around that I don't think OpenSSL will check the CRLs.
> 
> ---
> 
> Reply to this email directly or view it on GitHub:
> https://github.com/kennethreitz/requests/issues/1865#issuecomment-32693638

Sent from my Android phone with K-9 Mail.


No, although you can load CRLs with standard methods, the SSL module has no way to enable CRL checks prior to 3.4.

Ian Cordasco notifications@github.com schrieb:

> With the caveat that I know nothing of how the CRLs have been (or
> should be) implemented, is there no possible way to backport them via a
> package like certifi?
> 
> ---
> 
> Reply to this email directly or view it on GitHub:
> https://github.com/kennethreitz/requests/issues/1865#issuecomment-32693484

Sent from my Android phone with K-9 Mail.


You might be able to backport it via pyopenssl, much like how SNI and TLS Compression being disabled was done in urllib3.


I recommend that you don't invest too much time into CRL. I implemented it for Python 3.4 because it was a low hanging fruit. I only had to add the distribution points from X509v3 and expose one simple getter/setter.

Nowadays OCSP is used in favor of CRL because OCSP is much more lightweight. A TLS server can acquire a temporary OCSP token from its CA and send this OCSP info to its client. It's cheap and fast. OCSP is harder to handle on the client side, thought. :/

Donald Stufft notifications@github.com schrieb:

> You might be able to backport it via pyopenssl, much like how SNI and
> TLS Compression being disabled was done in urllib3.
> 
> ---
> 
> Reply to this email directly or view it on GitHub:
> https://github.com/kennethreitz/requests/issues/1865#issuecomment-33153172

Sent from my Android phone with K-9 Mail.


Mm, though OCSP requires us to trust the server. ;)


CRLs kinda suck in general. 
- They require access to the CRL lists, most implementations will "soft" fail, so if you can't reach the CRL lists it just won't validate against the CRL, making it trivially easy for a MITM attacker to block access to a CRL verification in a lot of cases.
- I think there have been problems with the CRL hosts not being on the greatest connections and going down/being slow but I can't find a source for this.


All agreed, but do they suck to a degree that outweighs their usefulness? =D


Well Firefox deprecated them in favor of OCSP in some version of Firefox (28?), I don't think Google Chrome has had CRL checking on by default in a long time if ever, No idea about Safari or IE.


In that case, this is totally not worth it. =D

Thanks all!


No, the OCSP response is signed by the CA not the TLS server. The server just retrieves and caches the OCSP response for a short time and forwards the token as part of the handshake. The client needs to verify the time stamp and CA signature. The client is free to ignore the token and retrieve a new one from the CA's OCSP server.

Cory Benfield notifications@github.com schrieb:

> Mm, though OCSP requires us to trust the server. ;)
> 
> ---
> 
> Reply to this email directly or view it on GitHub:
> https://github.com/kennethreitz/requests/issues/1865#issuecomment-33155170

Sent from my Android phone with K-9 Mail.