Revoked SSL Certificates not causing SSL error?

eyo this is my first time submitting a bug report of value (i think)

so a day or so ago I discovered that when you don't get an SSL error when you do:

```requests.get("revoked.badssl.com")```

which isn't very good

the problem isn't with OpenSSL, opening the following fails because of the bad certificate.

```openssl s_client -connect revoked.badssl.com:443``` 

I did some digging, as I'm working with SSL in my personal project, and _I think_ know what the issue is.

when you use the regular old' ```ssl.wrap_socket()```, you get the same behavior, where the module flat out ignores the bad certificate. It seems the correct way to do this is to do something similar to the following:
```
default_context = ssl.create_default_context(purpose=ssl.Purpose.CLIENT_AUTH)
default_context.verify_mode = ssl.CERT_REQUIRED
wrapped_socket = default_context.wrap_socket(your_socket_here)
```
This will then create an error when you try to get the webpage.
It seems that the issue stems from [here](https://github.com/kennethreitz/requests/blame/362da46e9a46da6e86e1907f03014384ab210151/requests/packages/urllib3/util/ssl_.py#L98), and was somewhat referenced [here](
https://github.com/kennethreitz/requests/issues/1786#issuecomment-167593081)

running python 3.5.2 on debian stretch with requests version 2.12.3, if that helps at all

tl;dr it seems that revoked ssl certs aren't being rejected, which could be an issue

I also wanted to thank y'all for making such an amazing python HTTP(S) module. I don't know what I would do without you guys.

So we are not doing client auth here.

And the openssl client fails for me because there's no local certificate in my bundle for the issuer of that revoked certificate:

```
CONNECTED(00000003)
depth=0 /C=US/ST=California/L=San Francisco/O=BadSSL Fallback. Unknown subdomain or no SNI./CN=badssl-fallback-unknown-subdomain-or-no-sni
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /C=US/ST=California/L=San Francisco/O=BadSSL Fallback. Unknown subdomain or no SNI./CN=badssl-fallback-unknown-subdomain-or-no-sni
verify error:num=27:certificate not trusted
verify return:1
depth=0 /C=US/ST=California/L=San Francisco/O=BadSSL Fallback. Unknown subdomain or no SNI./CN=badssl-fallback-unknown-subdomain-or-no-sni
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/C=US/ST=California/L=San Francisco/O=BadSSL Fallback. Unknown subdomain or no SNI./CN=badssl-fallback-unknown-subdomain-or-no-sni
   i:/C=US/ST=California/L=San Francisco/O=BadSSL/CN=BadSSL Intermediate Certificate Authority
---
...
    Verify return code: 21 (unable to verify the first certificate)
```

> tl;dr it seems that revoked ssl certs aren't being rejected, which could be an issue

This does seem, at this point, true. That said, I believe this is because requests (and openssl) don't by default turn on OCSP which is what we'd need to use to *detect* a revoked certificate.

There are lots of opinions about OCSP and certificate revocation, but one prevailing one is that it doesn't work very well (which isn't an excuse to not support it). Either way, I believe to support it, we need some work in the standard library ssl library and in cryptography to allow us to add that support to PyOpenSSL.

I'm not 100% confident in any of this, though, so I'd advise we wait until @Lukasa is up or someone like @reaperhulk can take a look.

---

Thanks for reporting this @mendaxi 

Requests does not respect revocation notices at this time. This is unfortunate but ultimately beyond us: there are no APIs available to extract and validate stapled OCSP responses, in either PyOpenSSL or the standard library.

I should note that there is only one case where revocation is really useful, and that is with OCSP-Must-Staple. In all other cases we basically fail open, which isn't really very helpful at all. 

However, @mendaxi seems to be suggesting that setting the verify mode to CERT_REQUIRED would resolve his issue. That's weird, because Requests has been setting that flag for 6 years.

TL:DR we don't use the regular old wrap socket and haven't for a while. We have been managing our own TLS config for years and validating certificates.

@Lukasa to be clear, @mendaxi is using CLIENT_AUTH with an SSLContext object. It's failing because it's the wrong configuration to validate a certificate from a server. :)

Sorry for the wrong configuration. My bad on that.