Ssl – When are OCSP requests sent by web browsers

ocspssl

I'm testing my https page via webpagespeedtest on IE8, and in one run I noticed a bunch of OSCP requests sent to oscp.godaddy.com. I never noticed any such requests in previous runs.

When do browsers decide to send such requests? Does it have to do with the fact I moved hosting providers yesterday?

Best Answer

IE relies on CryptoAPI for performing any certificate revocation/status checking task, so chances are:

an SSL certificate was presented to the browser
this was validated using the chain of CDPs listed by that certificate, and any CA CDPs (CRL Distribution Points - URLs from which CRLs are available) in the chain of certificates that were issued
a valid version of the CRL for a certificate in its issuance chain wasn't cached locally

And so CryptoAPI's chaining engine decided it needed newer information on whether one of those certificates had been revoked recently or not.

Any given operation on a certificate might cause CRL retrieval or OCSP-based checking; Windows will cache the CRL response for its validity period (or an OCSP response as specified by its max-age HTTP header), which might explain why you see it once in a while, but not regularly/frequently.

To "walk the chain" of CDPs yourself, open the certificate and go to the Certification Path tab - this shows the hierarchy of CAs which produced the certificate. Open each one, and look at its Details tab - the CRL location(s) at each level are what the client needs to check and cache in order to fully trust the certificate (the issuing Root must be trusted by your machine for anything in the chain to work); if OCSP is enabled, the AIA extensions are signficant as well.

Alternatively, save out the cert to a .CER file, and run the always-hilarious

CERTUTIL -verify -urlfetch mycert.cer

command to see the chaining engine in action.

Related Solutions

Ssl – Differences between IE6 and later with regard to HTTPS handling

Have you sniffed the client-to-server handshake between IE6 and the IIS machines yet? (http://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake_in_detail) I suspect that this will give you the first bit of information about what's going wrong, especially if you compare the handshake to a working IE7-based client-to-server conversation. An incompatible handshake is my guess as to what's happening.

Here's Microsoft's "official" "changes to HTTPS in IE 7" document: http://msdn.microsoft.com/en-us/library/bb250503(VS.85).aspx

I'm wondering about the "Use TLS 1.0" checkbox in the "Advanced" settings of your IE6 clients. IE7 enables TLS 1.0 by default, and IE6 disables it. It's unclear if your Customer's pentesters played around with the settings on the servers, clients, or both. I can imagine that, assuming they were playing around with the servers, they disabled SSL v2 on the servers (see http://support.microsoft.com/kb/187498) but didn't tell anybody to enable TLS 1.0 on the IE6 clients.

On the servers, they would have altered/created the "Enabled" DWORD value under "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server" and set it to 0, assuming they did disable SSL v2.

Apache ProxyPass SSL – How to Configure Apache ProxyPass with SSL

You'll need mod_ssl, mod_proxy and optionally mod_rewrite. Depending on your distribution and Apache version you may have to check if mod_proxy_connect and mod_proxy_http are loaded as well.

The directives for enabling SSL proxy support are in mod_ssl:

<VirtualHost 1.2.3.4:80>
    ServerName foo.com
    SSLProxyEngine On
    SSLProxyCheckPeerCN on
    SSLProxyCheckPeerExpire on
    ProxyPass / https://secure.bar.com
    ProxyPassReverse / https://secure.bar.com
</VirtualHost>

IIRC you can also use:

    RewriteRule / https://secure.bar.com [P]    # don't forget to setup SSLProxy* as well

Best Answer

Related Solutions

Ssl – Differences between IE6 and later with regard to HTTPS handling

Apache ProxyPass SSL – How to Configure Apache ProxyPass with SSL

Related Topic