Squid Web Cache wiki

Squid Web Cache documentation

🔗 Feature: SSL Server Certificate Validator

🔗 Motivation

Awaken by DigiNotar CA compromise, various web agents now try harder to validate SSL certificates (see 2011 squid-dev thread titled “SSL Bump Certificate Blacklist” for a good introduction). From user point of view, an SSL bumping Squid is the ultimate authority on server certificate validation, so we need to go beyond basic OpenSSL checks as well.

Various protocols and other validation approaches are floating around: CRLs, OCSP, SCVP, DNSSEC DANE, SSL Notaries, etc. There is no apparent winner at the moment so we are in a stage of local experimentation through trial-and-error. We have seriously considered implementing one of the above mentioned approaches in Squid, but it looks like it would be better to add support for a general validation helper instead, so that admins can experiment with different approaches.

🔗 Implementation sketch

The helper will be optionally consulted after an internal OpenSSL validation we do now, regardless of that validation results. The helper will receive:

If the helper decides to honor an OpenSSL error or report another validation error(s), the helper will return:

The returned information mimics what the internal OpenSSL-based validation code collects now. Returned errors, if any, will be fed to sslproxy_cert_error, triggering the existing SSL error processing code.

Helper responses will be cached to reduce validation performance burden (indexed by validation query parameters).

🔗 Helper communication protocol

This interface is similar to the SSL certificate generation interface.

Input line received from Squid:

request size [kv-pairs]

:warning: line refers to a logical input. body may contain \n characters so each line in this format is delimited by a 0x01 byte instead of the standard \n byte.

Example request:

0 cert_validate 1519 host=dmz.example-domain.com
cert_0=-----BEGIN CERTIFICATE-----
MIID+DCCA2GgAwIBAgIJAIDcHRUxB2O4MA0GCSqGSIb3DQEBBAUAMIGvMQswCQYD
...
YpVJGt5CJuNfCcB/
-----END CERTIFICATE-----
error_name_0=X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT
error_cert_0=cert0

Result line sent back to Squid:

result size kv-pairs

Example response message:

ERR 1444 cert_10=-----BEGIN CERTIFICATE-----
MIIDojCCAoqgAwIBAgIQE4Y1TR0/BvLB+WUF1ZAcYjANBgkqhkiG9w0BAQUFADBr
...
398znM/jra6O1I7mT1GvFpLgXPYHDw==
-----END CERTIFICATE-----
error_name_0=X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT
error_reason_0=Checked by Cert Validator
error_cert_0=cert_10

🔗 Design decision points

Why should the helper be consulted after OpenSSL validation? This allows the helper to use and possibly adjust OpenSSL-detected errors. We could add an squid.conf option to control consultation order, but we could not find a good use case to justify its overheads.

Why should the helper be consulted even if OpenSSL already declared a certificate invalid? OpenSSL may get it wrong. For example, its CRL might be out of date or simply not configured correctly. We could add an squid.conf option to control whether the helper is consulted after an OpenSSL-detected error, but since such errors should be rare, the option will likely add overheads to the common case without bringing any functionality advantages for the rare erronous case.

Categories: Feature

Navigation: Site Search, Site Pages, Categories, 🔼 go up