<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 2, 2015 at 11:32 AM, Brian Smith <span dir="ltr"><<a href="mailto:brian@briansmith.org" target="_blank">brian@briansmith.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div><b>How, what happens in a browser (maybe Microsoft's?) that actually supports the CRL DP extension?</b></div><div><br></div><div><div><div>1. The user attempts to connect to <a href="https://example.com" target="_blank">https://example.com</a> by starting the TLS handshake with the server it thinks is <a href="http://example.com" target="_blank">example.com</a>.</div><div><br></div><div>2. The attacker intercepts the connection, and completes the TLS handshake, stapling the last GOOD response into the connection, using the (stolen) private key of the certificate he is using for the attack.</div><div><br></div><div>3. The user's browser sees that the certificate doesn't have any OCSP URL, and so attempts to download the CRL.</div></div></div><div><br></div><div>4. The attacker blocks the CRL download.</div></div></div></div></blockquote><div><br></div><div>For what it's worth, this step is not necessary. An attacker is able to obtain the fraudulent OCSP response (see BR 1.3.1 Sec 4.9.10 - OCSP SHALL be provided for subscriber certs) and exploit the same stapling attack vector to staple the GOOD response.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>5. The user's browser gives up trying to check the certificate for revocation, and accepts the certificate.</div><div><br></div><div><div>This is exactly the same as if the CRL DP extension were not present.</div></div><div><br></div></div></div></div></blockquote></div></div></div>