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

[Steve Hill]

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).

> I think so, but it requires some development. Instead of rewriting
> CONNECT requests in ways that Google does not want you to do, I would do
> what Google suggests -- rewrite the IP address. Specifically, I would
> allow the eCAP/ICAP adapter to leave the CONNECT request "as is" but
> tell Squid what IP address to use when satisfying that request, as if
> that IP came from a DNS server when resolving the CONNECT host name.

I thought the same, but wasn't entirely sure if there was an existing
method of doing that before I started doing development. :)

> With this solution, no SslBump would be required at all!

Yep, and that would certainly be a good option, although I bump google
searches for other reasons (content examination) most of the time anyway.

> 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.
A nice solution would be to call an ICAP REQMOD hook for each SSL bump
step (with each ICAP request including the extra data that has been
discovered in that step).  But that would be a lot of work. :)

>> 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"
2. http_access ACL is checked and returns "proxy_auth"
3. Proxy replies with a 407
4. Client sends "CONNECT example.com" with authentication credentials
5. Proxy replies with "HTTP/1.1 200 Connection established"
6. Client sends SSL handshake.
7. Bump step 1 ACL is checked and returns "peek"
8. Proxy examines client's SSL handshake and retrieves SNI
9. Bump step 2 ACL is checked and returns "splice"
10. Proxy connects to server, forwards the client handshake and splices
the Client<->Proxy connection to the Proxy<->Server connection.

So by the time we reach (9), we've already got the credentials.  Have I
misunderstood?


The relevant parts of the config are:

http_access allow proxy_auth
http_access deny all
external_acl_type sslpeek children-max=10 concurrency=100 ttl=0
negative_ttl=0 %SRC %un %URI %ssl::>sni %>ha{User-Agent}
/usr/sbin/check_bump.sh
acl sslpeek external sslpeek
acl ssl_bump_step_1 at_step SslBump1
acl ssl_bump_step_2 at_step SslBump2
acl ssl_bump_step_3 at_step SslBump3
ssl_bump peek ssl_bump_step_1
ssl_bump bump ssl_bump_step_2 sslpeek
ssl_bump splice all
sslproxy_cert_error allow all


The debug log shows that the request is successfully authenticated:

Acl.cc(138) matches: checking proxy_auth
UserData.cc(22) match: user is steve, case_insensitive is 0
UserData.cc(28) match: aclMatchUser: user REQUIRED and auth-info present.
Acl.cc(340) cacheMatchAcl: ACL::cacheMatchAcl: miss for 'proxy_auth'.
Adding result 1
Acl.cc(158) matches: checked: proxy_auth = 1

But then later in the log I see:

external_acl.cc(1416) Start: fg lookup in 'sslpeek' for
'2a00:1940:1:8:468a:5bff:fe9a:cd7f - www.hsbc.co.uk:443 www.hsbc.co.uk
Mozilla/5.0%20(X11;%20Fedora;%20Linux%20x86_64;%20rv:39.0)%20Gecko/20100101%20Firefox/39.0'


(the user name is shown as "-" rather than being filled in).

Setting a->require_auth in parse_externalAclHelper() makes it work, but
obviously just makes %un behave like %LOGIN (requires auth, rather than
just being filled in if it is present), so isn't a solution.


>> Any advice gratefully received, looks like I'm spending next week
>> working through these issues. :)
> 
> You may get more advice on the squid-users list, where there are
> probably more folks facing similar problems.

I had posted about the %un issue on squid-users the previous week but
had no reply - I figured that the new bump functionality is probably not
yet being used widely enough for many outside the development folks to
be playing with it.

Many thanks for the reply.

-- 

 - 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-1792-825748 / sip:sales at opendium.com

Support contacts:
   Email:            support at opendium.com
   Phone:            +44-1792-824568 / sip:support at opendium.com