[squid-users] [3.5.23]: mozilla.org failed using SSL transparent SSL23_GET_SERVER_HELLO:unknown protocol

[Amos Jeffries]

On 24/01/2017 2:11 p.m., David Touzeau wrote:
> De :  Amos Jeffries
> 
> On 24/01/2017 12:28 p.m., David Touzeau wrote:
>> Same issue with https://www.digitalocean.com/ is somebody did not
>> encounter the issue using Squid in transparent mode with SSL ??
>>
> 
> The TLS / HTTP Senvironment is in the process of stabilizing, but still
> quite volatile.
> 
> Since the error message says "unknown protocol" I suspect it is something
> like WebSockets, HTTP/2 or SPDY which you are actually intercepting on port
> 443. Not HTTP/1 which Squid supports.
> 
> Or maybe it is some non-TLS traffic that OpenSSL does not support.
> 
> Mozilla do cert pinning, so teh bump/intercept should probably not work
> anyway. I'm not sure about digitalocean.
> ------------------------------------------------------------------------------------------------------------------------------------
> 
> Thanks Amos for the answer but...
> 
> I did not want to bump these sites, only pass trough the squid
> port and process the request without try decrypting the protocol.

Aye. Sorry I noticed that just after pressing send.

Which means it is probably OpenSSL itself that does not know the
protocol. Could be TLS/1.3, from a big name like Mozilla port 443 is
unlikely to be non-TLS unless somebody upstream of you is doing
something funky for that specific traffic.


> 
> Tried :
> 
> acl nossl dstdomain -i .mozilla.org
> ssl_bump none nossl
> acl ssl_step1 at_step SslBump1
> acl ssl_step2 at_step SslBump2
> acl ssl_step3 at_step SslBump3
> ssl_bump peek ssl_step1
> ssl_bump splice all
> 
> or
> 
> acl nossl dst 104.16.40.2
> ssl_bump none nossl
> acl ssl_step1 at_step SslBump1
> acl ssl_step2 at_step SslBump2
> acl ssl_step3 at_step SslBump3
> ssl_bump peek ssl_step1
> ssl_bump splice all
> 
> 
> But squid is still unable to process the request.
> 
> Any workaround ?

Use 'splice' instead of 'none'. Mixing the SSL-Bump feature versions
like that is bad.

Also, what is showing up in your access.log for these transactions? The
ACL deciding not to even peek needs to correcly match the faked CONNECT
request containing only the dst-IP address.


I'm not aware of any other workaround for Squid-3. The
on_unsupported_protocol might be able to handle it in Squid-4.


Amos