Re: [Patch] ssl_bump X.509 version mismatch

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Thu, 21 Aug 2014 12:07:33 +1200

On 21/08/2014 3:19 a.m., Steve Hill wrote:
> 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.
>

X.509 v3 was standardized in 1996, and the current RFC5280 is dated 2008.

The basic design of TLS (not SSL) AIUI is to advertise latest version
and downgrade to remote ends capabilities only if necessary.

So are we not in a position to always use v3(+) certificate ?

Amos
Received on Thu Aug 21 2014 - 00:07:58 MDT

This archive was generated by hypermail 2.2.0 : Thu Aug 21 2014 - 12:00:13 MDT