[squid-dev] Moving from Bump-Server-First to Bump/Peek/Splice

[Alex Rousskov]

On 09/12/2015 03:13 AM, Steve Hill wrote:
> On 11/09/15 21:46, Alex Rousskov wrote:
> 
>> At least two very different scenarios would result in the forged
>> certificate having forcesafesearch.google.com CN:
>>
>> 1. Squid receives www.google.com CN from Google, but uses
>> forcesafesearch.google.com CN in the forged certificate. This is what
>> you think is happening.
>>
>> 2. Squid receives forcesafesearch.google.com CN from Google and uses it
>> in the fake certificate. This is what I suspect may be happening.
> 
> I will need to test this more thoroughly, but I was testing using
> proxytunnel (to set up the CONNECT) and openssl (to do the actual ssl
> bit) and found that the CN was always identical to the contents of the
> CONNECT, even if the CONNECT was to an IP address rather than a host name.
> 
> I'll do some more testing next week and report back - I'm pretty sure
> that using an IP address in the CN is going to break things, so either I
> have a problem with my config or there's a problem with the new bump
> code (notably, just switching back to server-first without changing the
> squid version restores the old behaviour).

If you think the bumping code is buggy, consider filing a bug report
with Bugzilla to increase the chance that the bug is noticed and fixed.
If you can, please mention in your report whether recent trunk code works.


>> Alternatively, you can
>> continue to use eCAP/ICAP for transparent connections -- they generate
>> fake CONNECT requests that are sent to adaptation services...
> 
> The CONNECT requests for transparent connections only contain the IP
> address at the moment, since they happen before any of the bump steps.

When dealing with certain connections, Squid trunk sends _two_ fake
CONNECT requests for adaptation, including the second CONNECT request
during SslBump step #2. Since trunk r14293, that second fake CONNECT
request includes SNI information. Sorry, I do not know the exact
criteria when Squid sends two fake CONNECT requests instead of one.


>>> Also, I've noticed that the "%un" external ACL format code is never
>>> being filled with the user name when calling an external ACL during bump
>>> step 2, even though the request has been authenticated.
>>
>> If the TCP connection has been authenticated, then this is a bug and you
>> should file a bug report.
>>
>> If you are talking about HTTP authentication methods that authenticate
>> individual transactions and not whole connections (e.g., Basic), then
>> there is no HTTP at SslBump step #2 yet.
> 
> I am talking about Basic, but I don't understand why this wouldn't be
> authenticated by step 2, the various stages of a Basic authenticated
> connection should be:
> 
> 1. Client sends "CONNECT example.com"

You are right, I forgot that the proxy authentication information is
inside CONNECT, not inside the first encrypted/tunnelled request. I
agree that the authentication information should be there, even during
bumping step #1. Please see above regarding bugs.


Alex.