martin wrote:The Windows certificate store does not actually contain all trusted certificates. They are somehow automatically downloaded using Windows Update (!?) when HTTPS-requests are made using WinInet.
the windows cert store should contain every trusted root certificate as far as i know.
Intermediate certificates should be sent by the server along the server-certificate, if an intermediate certificate is necessary. An additional download of certificates should not be necessary, but is necessary, if the server is not completely correctly configured and does not send the intermediate certificate. It is implementation specific that the client tries to get the intermediate certificate he does not know (i guess that is what Windows Update is used for). Many implementations will abort the connection, if the intermediate certificate is not supplied by the server and the chain to the trusted root can not be built.
martin wrote:OpenSSL does not come with a certificate store, nor does it actually has any real built-in support to handle a full CRL-check. Instead, you're supposed to download the CRL's as needed and to do that some CA's require an agreement with them. And some certs are embedded as resources in the crypt32.dll.
The CRL check is indeed a bit tricky. But i have never heard of an agreement to be necessary to do this. As long as you only validate the certificate by using the CRL-Download-Link supplied in the certificate, no agreement should be necessary, as this is a standard procedure. If an OCSP Link is present, it should be preferred to be used for validation. If the Certificate uses OCSP-Stapling, that should be preferred over both.
As CRL and OCSP need additional lookups/connections they both slow down the handshake. Also any man in the middle could block those connections and make the validation fail. For that reason no browser actually validates this during the handshake. Some browsers try the CRL/OCSP lookup after the connection is established and warn the user, if the outcome shows, that the cert is revoked. It could be too late by then, but it is better than nothing.
martin wrote:Reading more about this, it's a pretty sad story. Apparently Chrome no longer does CRL-requests but are using their own proprietary format CRLset instead. This file includes ~2% of all actual revocations. This appears completely broken to me (you simply cannot assume that Chrome will care about revoked certs any more since they only include a small portion of all revoked).
As I understand it, Firefox do not download the CRL-lists either. One reason is that the CRL-lists can get pretty big (some are apparently >40MB) and downloading such a list prior to a user visiting a site will make the web too slow. It would also introduce a single-point-of-failure (if the CRL-list server is down). Also, to make this actually work you would have to download the list all the time, like every 4 hour and then the required bandwidth becomes pretty high.
The CRLset approach by chrome is a trade-off, but Firefox is going that direction too now (https://wiki.mozilla.org/CA:RevocationPlan
). Althoug it contains only a few revoked certificates, this can be enough to secure most connections, as long as it contains all revoked intermediate certificates. Revoked root certificates are removed from the trust store by windows update after some time afaik. The downside of this approach is, that it does not cover every certificate revoked by smaller sites (which has recently been done by many after the heartbleed bug).
For the caching time of CRL files and OCSP answers i would rely on the HTTP caching mechanisms like the HTTP ETag, the If-Modified-Since-Header or the Cache-Control: max-age- / Expires-Heades (if the OCSP protocol does not specify otherwise).
Maybe we should just invent another way of handling cert validation
To not slow down the connection we should not validate any CRL/OCSP at connection time (or maybe only OCSP with 1-2 seconds timeout?).
Instead hMailServer would just log something like the following line:
Code: Select all
... SSL Connection established: IP:18.104.22.168 MX-Hostname:gmail-smtp-in.l.google.com Recipient-Hostname:gmail.com CertificateHash:sd9f87sfd98s7fd98s7df9s8df7s9d8f7s9df7 Chipher:.... KeyExchange:....OCSP-Stapling-valid:false
The information in that line could then be used afterwards to check if the connection was secure by using any means of validation the admin would like to use in an external script for example.