Re: [RFC] Certificate validation helper

On 07/02/2012 06:20 PM, Amos Jeffries wrote:
> 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>

OK, but not all helper communication is line-based. We may need to send
PEM-encoded certificates back (and ssl_crtd already does that). That
requires sending multiline blocks of data.

If you want to generalize that, consider adding body start/end terminators.

> * 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.

Sounds good.

Do you want me to provide basic reusable classes for helper request
formatting and response parsing, if I have a chance?

Thank you,

Alex.
Received on Tue Jul 03 2012 - 02:59:56 MDT