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. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
