Re: [Patch] ssl_bump X.509 version mismatch

On 08/20/2014 07:50 AM, Steve Hill wrote:

> I've been debugging an issue with some versions of Firefox failing to
> accept the forged certificate generated by squid when bumping some self
> signed certs. Firefox gives me the very generic error:
>
> "Certificate extension value is invalid. (Error code:
> sec_error_extension_value_invalid)"

This is probably fixed in trunk r13533. The problem may not be limited
to self-signed certificates. See the change log for details.

> + // Copy the X.509 version
> + X509_set_version(cert.get(), X509_get_version(properties.mimicCert.get()));

This alternative should work for this use case, although it raises two
yellow flags:

*v4: I am worried that Squid might generate certificates that Squid
itself cannot use if we just blindly copy the version value like that. I
have seen posts discussing v4 certificates... On the other hand, I do
not know whether Squid can successfully negotiate a secure connection
with a server using x509 v4. Perhaps Squid should mimic the original
version after lowering it to v3 if needed?

*v3 where v2 would suffice: There are cases where Squid is correctly
generating a v2 certificate while mimicking a v3 certificate (because
Squid does not mimic any of the extensions in the true certificate). Is
it really a good idea to increase/mimic the version in this case? I am
not sure. What do you think?

There are two rather different mimicking approaches:

A) "mimic everything except for the stuff we know is unsafe" and
B) "mimic only the stuff we know is safe to mimic".

We started with (A) but, based on the initial SslBump experience, we now
think that (B) works better in most (but not all!) use cases. Your patch
(if applied literally) follows (A). The current code uses (B). Do you
think we should replace trunk r13533 with your patch or some adjusted
version of it as discussed in the yellow flags above?

Thank you,

Alex.
Received on Wed Aug 20 2014 - 14:41:59 MDT