Re: [RFC] Certificate validation helper

On 03.07.2012 08:11, Alex Rousskov wrote:
> 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?).

On this point. If you are using the helper API you will be wanting to
have a helper result cache. These are keyed on the input string sent to
the helper.

>
> 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?
>

I think it would be good to provide the extra flexibility.

I am in the process of modifying the helper API for consistency across
all helpers starting with 3.3. It would be great if you could design
your helper to use a generic output format for data sent back to Squid:

  [channel-ID] (OK/ERR/BH) [key-pairs] <terminator>

  * With BH optionally as a broken-helper failure state as per the NTLM
helper API.
  * Noticing how there are *no* fixed-position fields beyond the result
code.

For data from Squid to helper please design with minimum number of
fixed-position/type fields and define [key-pair] as optional
extension(s) to hold whatever data is optionally sent to the helper.
Ideally we will never transmit any fields which could be "-"/"[unknown]"
to or from the helper.

Amos
Received on Tue Jul 03 2012 - 00:20:39 MDT