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:st...@opendium.com Email: st...@opendium.com Phone: sip:st...@opendium.com Sales / enquiries contacts: Email: sa...@opendium.com Phone: +44-844-9791439 / sip:sa...@opendium.com Support contacts: Email: supp...@opendium.com Phone: +44-844-4844916 / sip:supp...@opendium.com