Re: [Patch] ssl_bump X.509 version mismatch

On 20/08/14 15:41, Alex Rousskov wrote:

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

Ahh damn, I didn't check the trunk! :)
Yes, it looks like it will solve the problem.

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

I'm not especially familiar with what new stuff v4 brings to the table.
 Capping the version at 3 (until the rest of Squid can support 4) seems
reasonable, although we obviously have to be careful not to include v4
extensions in a v3 certificate.

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

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

Unfortunately I don't think I'm really knowledgeable enough about SSL to
make that judgment.

From a "neatness" point of view, I like the idea of the forgery being as
indistinguishable as possible from the original, but as you say that may
not always be best in practice.

I guess we need to think about what the implications are of:
1. Using the lowest version that we require
2. Sticking to the version of the original certificate.

In the case of (1), this presumably means that old software that doesn't
support version 3 certificates will be able to talk to version 3
services. That's a reasonably good thing - we're essentially gatewaying
between old and new technologies, very similar to being able to use an
IPv4-only client to talk to an IPv6-only server via a dual-stacked Squid.

On the other hand, software that can't handle v3 certificates would
presumably not be normally able to talk with the web server anyway, so
in the case of (2) we're not breaking anything that would have worked if
we weren't bumping the connection.

Both solutions should work ok, so if you think that past experience
indicates it better to not mimic the version number then I'm certainly
happy to go along with that.

Many thanks.

-- 
 - Steve Hill
   Technical Director
   Opendium Limited     http://www.opendium.com
Direct contacts:
   Instant messager: xmpp:steve_at_opendium.com
   Email:            steve_at_opendium.com
   Phone:            sip:steve_at_opendium.com
Sales / enquiries contacts:
   Email:            sales_at_opendium.com
   Phone:            +44-844-9791439 / sip:sales_at_opendium.com
Support contacts:
   Email:            support_at_opendium.com
   Phone:            +44-844-4844916 / sip:support_at_opendium.com