[RFC] Certificate validation helper

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Mon, 02 Jul 2012 14:11:01 -0600

Hello,

    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 intro). From user point of view, a
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.

The helper will be optionally consulted after a successful internal
OpenSSL validation we do now. It will receive the origin server
certificate [chain] and the intended domain name. On errors, the helper
will return the validation error name (see %err_name error page macro
and %err_details logformat code), error reason (%ssl_lib_error macro),
and possibly the offending certificate (%ssl_subject and %ssl_ca_name
macros) -- similar to what the internal validation code returns now.

Squid may maintain a cache of certificate validation results to reduce
validation performance burden (indexed by certificate fingerprint?).

Squid will provide a dummy helper. Eventually, full-featured helpers may
be contributed (but I am currently not planning on writing one).

If there are no objections, I would like to detail the above on Squid
wiki and eventually submit a patch implementing this feature in v3.3. Do
you think that is a good idea?

Thank you,

Alex.
Received on Mon Jul 02 2012 - 20:11:05 MDT

This archive was generated by hypermail 2.2.0 : Tue Jul 03 2012 - 12:00:03 MDT