[squid-users] Ssl bump tunneling connection by using Common Name

[Alex Rousskov]

On 03/06/2017 06:46 AM, Hanoch Hanoch K wrote:

> However skype's client app uses client certificates that don't have SNI.

SNI is not a property of a client certificate. It is a property of a
client Hello message. I do not know whether some Skype clients do not
send SNI with their Hellos, but I wanted to correct the above
misconception for the record.


> the Common Name is available only in step3 of ssl bump,

This part is correct. Squid receives the server handshake messages,
including the server certificate during step3.


> where tunneling the connection is no longer possible (as documented in
> peek and splice step3 docs).

This is somewhat misleading: Splicing after step3 works fine, provided
the "peek" action matched at step2. In other words, splicing works after
peeking.

Needless to say, bumping configurations cannot peek during step3 -- they
have to either stare or bump instead.

> acl DiscoverSNIHost at_step SslBump1
> acl NoSSLIntercept ssl::server_name_regex -i ...
> ssl_bump splice NoSSLIntercept
> ssl_bump peek DiscoverSNIHost
> ssl_bump bump all

Your configuration usually peeks [at the client Hello] during step2 and
either splices or bumps during step3.


> Is there a way we can tunnel an acl based on Common Name?

Yes, but you will not be able to bump then.

If some Skype clients do not send SNI, then your options include:

* do not bump any connections;

* match Skype connections using destination IP addresses (lots of
maintenance headaches and some errors, but doable);

* enhance Squid to detect something that is unique to Skype client
handshake messages sent _before_ the client receives the server Hello.
For example, if (and only if) the Skype client sends its certificate
before receiving the server Hello, then Squid can be enhanced to detect
and interrogate that client certificate using ACLs.

Pick your poison.

Alex.