Re: [RFC] Certificate validation helper

On 03.07.2012 14:59, Alex Rousskov wrote:
> 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.

I know. That is why I omit the word "line" and specify <terminator>
instead of <EOL>.

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

I have one almost finished as a callback params object for replies. As
soon as it passes all the build tests I'll be submitting a patch before
starting to merge the parsers and extend the available response
key-pairs.

If you want to make a generic one for requests that would help. It's a
bit more complicated to get backward compatible due to the larger syntax
variance between helper request formats.

Amos
Received on Tue Jul 03 2012 - 22:56:14 MDT