SQUID 4.12 (Debian 10, OpenSSL 1.1.1d) - SSL bump no server helllo

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

SQUID 4.12 (Debian 10, OpenSSL 1.1.1d) - SSL bump no server helllo

Loučanský Lukáš
Hello,
I was wondering if anyone could take a look at this:
I'm running squid for rather long time, recently I have upgraded my squid box to Debian 10 (from Debian 9) and OpenSSL 1.1.1d
 
4.19.0-9-amd64 #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07) x86_64 GNU/Linux OpenSSL 1.1.1d  10 Sep 2019

squid -v
Squid Cache: Version 4.12
Service Name: squid

This binary uses OpenSSL 1.1.1d  10 Sep 2019. For legal restrictions on distribution see https://www.openssl.org/source/license.html

configure options:  '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=/include' '--mandir=/share/man' '--infodir=/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--libexecdir=/lib/squid4' '--srcdir=.' '--disable-maintainer-mode' '--disable-dependency-tracking' '--disable-silent-rules' '--datadir=/usr/share/squid4' '--sysconfdir=/etc/squid4' '--mandir=/usr/share/man' '--enable-inline' '--disable-arch-native' '--enable-async-io=8' '--enable-storeio=ufs,aufs,diskd,rock' '--enable-removal-policies=lru,heap' '--enable-delay-pools' '--enable-cache-digests' '--enable-icap-client' '--enable-follow-x-forwarded-for' '--enable-auth-basic=DB,fake,getpwnam,LDAP,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB' '--enable-auth-digest=file,LDAP' '--enable-auth-negotiate=kerberos,wrapper' '--enable-auth-ntlm=fake,SMB_LM' '--enable-external-acl-helpers=file_userip,kerberos_ldap_group,LDAP_group,session,SQL_session,time_quota,unix_group,wbinfo_group' '--enable-url-rewrite-helpers=fake' '--enable-security-cert-validators=fake' '--enable-storeid-rewrite-helpers=file' '--enable-eui' '--enable-esi' '--enable-icmp' '--enable-zph-qos' '--enable-ecap' '--enable-snmp' '--disable-translation' '--with-swapdir=/var/spool/squid4' '--with-logdir=/var/log/squid4' '--with-pidfile=/var/run/squid4.pid' '--with-filedescriptors=65536' '--with-large-files' '--with-default-user=proxy' '--with-openssl' '--enable-ssl-crtd' '--enable-security-cert-generators' '--enable-security-cert-validators' '--enable-linux-netfilter' 'PKG_CONFIG_PATH=:/usr/local/lib/pkgconfig:/usr/lib64/pkgconfig:/usr/share/pkgconfig' 'CFLAGS=-g -O2 -m64 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wall' 'LDFLAGS=-fPIE -pie -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-D_FORTIFY_SOURCE=2' 'CXXFLAGS=-g -O2 -m64 -fPIE -fstack-protector-strong -Wformat -Werror=format-security' 'build_alias=x86_64-linux-gnu'

Before upgrade I was running stock kernel, stock openssl and compiled squid version 4.10 with ssl support to splice (local and excepted webs), peek and terminate ssl connections based on the SNI acl.
 
Now I run into this problem - my configuration does not work anymore. So I decided to try to bump every connection. The security file certgen is making new certificates based on my CA as usual.
But the client on the intercepted connection (via changed routing table under mikrotik and then prerouted to correct squid ports for http and ssl traffic) running Chrome 83 http://download.kjj.cz/pub/ssl/idnes.cz_chrome.83.0.4103.97.pcapng sends ClientHello - and no ServerHello is received. I've tcpdumped outgoing interface on the squid box - and there was no actual connection to the desired server.
In the access.log there is something like 1592212170.495      2 10.0.0.40 NONE_ABORTED/200 0 CONNECT 185.17.117.32:443 - HIER_NONE/- -
 
But - same client, same network, same network running Firefox 77 http://download.kjj.cz/pub/ssl/idnes.cz_firefox.77.0.1.pcapng  gets ServerHello after it's ClientHello - they exchange information, exchange ciphers etc. and the web page is loaded. I've checked https certificate details - it's been issued by my CA.


access.log:
 
1592212156.764      8 10.0.0.40 TCP_MISS/301 196 GET http://idnes.cz/ - ORIGINAL_DST/185.17.117.32 -
1592212156.774      2 10.0.0.40 NONE/200 0 CONNECT 185.17.117.32:443 - HIER_NONE/- -
1592212156.825     38 10.0.0.40 TCP_MISS/302 777 GET https://idnes.cz/ - ORIGINAL_DST/185.17.117.32 text/html
1592212156.840      7 10.0.0.40 NONE/200 0 CONNECT 185.17.117.32:443 - HIER_NONE/- -
1592212156.893     28 10.0.0.40 TCP_CLIENT_REFRESH_MISS/200 40086 GET https://www.idnes.cz/ - ORIGINAL_DST/185.17.117.32 text/html


So in Firefox - it seems to be working. I have modified opensll.cnf default configuration to avoid MinProtocol TLS1.2, but no change. I have 2048b SSL DH params specified for prime256v1 curve in the https-port definition like this https_port 3129 intercept ssl-bump  generate-host-certificates=on dynamic_cert_mem_cache_size=8MB cert=/etc/squid4/ssl/CAcert.pem tls-dh=prime256v1:/etc/squid4/ssl/dhparams_2048.pem cipher=HIGH:MEDIUM:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS

and

tls_outgoing_options options=NO_SSLv3
tls_outgoing_options cipher=HIGH:MEDIUM:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS

At first I thought I have to change my configuration or that I missed something during the compiling so I switched back to 4.10 - no change.I see 2020/06/15 11:21:45 kid2| Error negotiating SSL connection on FD 59: error:00000001:lib(0):func(0):reason(1) (1/-1) in the cache.log here and there - but it was the same before. I've actually turned debug on (by debug_options ALL,9), just to get bunch of information, tracked down connect request to the desired servers and seeing nothing...

Is it something about the patch for older TLS traffic, or is it some misconfiguration - maybe in the ciphers or TLS versions?

Thanks LL
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: SQUID 4.12 (Debian 10, OpenSSL 1.1.1d) - SSL bump no server helllo

Alex Rousskov
On 6/16/20 3:43 AM, Loučanský Lukáš wrote:

> I was wondering if anyone could take a look at this:

It might be TLS GREASE[1], but I do not see enough information to
reliably diagnose the problem. This is not your fault -- Squid just does
not log the relevant details by default (we are actively working on
improving that).

If others do not find a solution, I suggest sharing an ALL,9 log of a
problematic transaction.

Alex.

[1]
https://github.com/squid-cache/squid/commit/eec67f04490a477d69891c8b05a94bea05e5efbf


> I'm running squid for rather long time, recently I have upgraded my squid box to Debian 10 (from Debian 9) and OpenSSL 1.1.1d
>  
> 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07) x86_64 GNU/Linux OpenSSL 1.1.1d  10 Sep 2019
>
> squid -v
> Squid Cache: Version 4.12
> Service Name: squid
>
> This binary uses OpenSSL 1.1.1d  10 Sep 2019. For legal restrictions on distribution see https://www.openssl.org/source/license.html
>
> configure options:  '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=/include' '--mandir=/share/man' '--infodir=/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--libexecdir=/lib/squid4' '--srcdir=.' '--disable-maintainer-mode' '--disable-dependency-tracking' '--disable-silent-rules' '--datadir=/usr/share/squid4' '--sysconfdir=/etc/squid4' '--mandir=/usr/share/man' '--enable-inline' '--disable-arch-native' '--enable-async-io=8' '--enable-storeio=ufs,aufs,diskd,rock' '--enable-removal-policies=lru,heap' '--enable-delay-pools' '--enable-cache-digests' '--enable-icap-client' '--enable-follow-x-forwarded-for' '--enable-auth-basic=DB,fake,getpwnam,LDAP,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB' '--enable-auth-digest=file,LDAP' '--enable-auth-negotiate=kerberos,wrapper' '--enable-auth-ntlm=fake,SMB_LM' '--enable-external-acl-helpers=file_userip,kerberos_ldap_group,LDAP_group,session,SQL_session,time_quota,unix_group,wbinfo_group' '--enable-url-rewrite-helpers=fake' '--enable-security-cert-validators=fake' '--enable-storeid-rewrite-helpers=file' '--enable-eui' '--enable-esi' '--enable-icmp' '--enable-zph-qos' '--enable-ecap' '--enable-snmp' '--disable-translation' '--with-swapdir=/var/spool/squid4' '--with-logdir=/var/log/squid4' '--with-pidfile=/var/run/squid4.pid' '--with-filedescriptors=65536' '--with-large-files' '--with-default-user=proxy' '--with-openssl' '--enable-ssl-crtd' '--enable-security-cert-generators' '--enable-security-cert-validators' '--enable-linux-netfilter' 'PKG_CONFIG_PATH=:/usr/local/lib/pkgconfig:/usr/lib64/pkgconfig:/usr/share/pkgconfig' 'CFLAGS=-g -O2 -m64 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wall' 'LDFLAGS=-fPIE -pie -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-D_FORTIFY_SOURCE=2' 'CXXFLAGS=-g -O2 -m64 -fPIE -fstack-protector-strong -Wformat -Werror=format-security' 'build_alias=x86_64-linux-gnu'
>
> Before upgrade I was running stock kernel, stock openssl and compiled squid version 4.10 with ssl support to splice (local and excepted webs), peek and terminate ssl connections based on the SNI acl.
>  
> Now I run into this problem - my configuration does not work anymore. So I decided to try to bump every connection. The security file certgen is making new certificates based on my CA as usual.
> But the client on the intercepted connection (via changed routing table under mikrotik and then prerouted to correct squid ports for http and ssl traffic) running Chrome 83 http://download.kjj.cz/pub/ssl/idnes.cz_chrome.83.0.4103.97.pcapng sends ClientHello - and no ServerHello is received. I've tcpdumped outgoing interface on the squid box - and there was no actual connection to the desired server.
> In the access.log there is something like 1592212170.495      2 10.0.0.40 NONE_ABORTED/200 0 CONNECT 185.17.117.32:443 - HIER_NONE/- -
>  
> But - same client, same network, same network running Firefox 77 http://download.kjj.cz/pub/ssl/idnes.cz_firefox.77.0.1.pcapng  gets ServerHello after it's ClientHello - they exchange information, exchange ciphers etc. and the web page is loaded. I've checked https certificate details - it's been issued by my CA.
>
>
> access.log:
>  
> 1592212156.764      8 10.0.0.40 TCP_MISS/301 196 GET http://idnes.cz/ - ORIGINAL_DST/185.17.117.32 -
> 1592212156.774      2 10.0.0.40 NONE/200 0 CONNECT 185.17.117.32:443 - HIER_NONE/- -
> 1592212156.825     38 10.0.0.40 TCP_MISS/302 777 GET https://idnes.cz/ - ORIGINAL_DST/185.17.117.32 text/html
> 1592212156.840      7 10.0.0.40 NONE/200 0 CONNECT 185.17.117.32:443 - HIER_NONE/- -
> 1592212156.893     28 10.0.0.40 TCP_CLIENT_REFRESH_MISS/200 40086 GET https://www.idnes.cz/ - ORIGINAL_DST/185.17.117.32 text/html
>
>
> So in Firefox - it seems to be working. I have modified opensll.cnf default configuration to avoid MinProtocol TLS1.2, but no change. I have 2048b SSL DH params specified for prime256v1 curve in the https-port definition like this https_port 3129 intercept ssl-bump  generate-host-certificates=on dynamic_cert_mem_cache_size=8MB cert=/etc/squid4/ssl/CAcert.pem tls-dh=prime256v1:/etc/squid4/ssl/dhparams_2048.pem cipher=HIGH:MEDIUM:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS
>
> and
>
> tls_outgoing_options options=NO_SSLv3
> tls_outgoing_options cipher=HIGH:MEDIUM:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS
>
> At first I thought I have to change my configuration or that I missed something during the compiling so I switched back to 4.10 - no change.I see 2020/06/15 11:21:45 kid2| Error negotiating SSL connection on FD 59: error:00000001:lib(0):func(0):reason(1) (1/-1) in the cache.log here and there - but it was the same before. I've actually turned debug on (by debug_options ALL,9), just to get bunch of information, tracked down connect request to the desired servers and seeing nothing...
>
> Is it something about the patch for older TLS traffic, or is it some misconfiguration - maybe in the ciphers or TLS versions?
>
> Thanks LL
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users
>

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: SQUID 4.12 (Debian 10, OpenSSL 1.1.1d) - SSL bump no server helllo

Loučanský Lukáš
But - according to
https://github.com/squid-cache/squid/commit/eec67f04490a477d69891c8b05a94bea05e5efbfGREASE 
- as unknown extensions is meant to be ignored (?). The same said here
https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/d_f6higCJzcBut 
- these information are years old - so I guess squid already does the
right thing.

Anyway - with debug_options ALL,1 83,2:

2020/06/16 23:24:34.831 kid2| 83,2| client_side.cc(3180)
parseTlsHandshake: error on FD 22: check failed: vMajor == 3
     exception location: Handshake.cc(119) ParseProtocolVersion

from chrome

2020/06/16 23:24:37.794 kid2| 83,2| client_side.cc(2684)
clientNegotiateSSL: New session 0x562491ae96c0 on FD 69
(192.168.xx.yy:53569)
2020/06/16 23:24:37.845 kid2| 83,2| client_side.cc(2684)
clientNegotiateSSL: New session 0x562490828890 on FD 70
(192.168.xx.yy:53570)
2020/06/16 23:24:37.845 kid2| clientProcessHit: URL mismatch,
'[unknown_URI]' != 'https://www.idnes.cz/'
2020/06/16 23:24:38.007 kid1| 83,2| client_side.cc(2684)
clientNegotiateSSL: New session 0x55e735276ad0 on FD 57
(192.168.xx.yy:53572)
2020/06/16 23:24:38.013 kid2| 83,2| client_side.cc(2684)
clientNegotiateSSL: New session 0x56249117f780 on FD 71
(192.168.xx.yy:53571)
2020/06/16 23:24:38.018 kid1| 83,2| client_side.cc(2684)
clientNegotiateSSL: New session 0x55e730cfb640 on FD 59
(192.168.xx.yy:53573)
2020/06/16 23:24:38.025 kid2| 83,2| client_side.cc(2684)
clientNegotiateSSL: New session 0x562495f16e00 on FD 73
(192.168.xx.yy:53574)
2020/06/16 23:24:38.028 kid2| 83,2| client_side.cc(2645)
clientNegotiateSSL: Session 0x562492e12150 reused on FD 74
(192.168.xx.yy:53576)
2020/06/16 23:24:38.028 kid2| clientProcessHit: URL mismatch,
'[unknown_URI]' != 'https://1gr.cz/js/uni/uni.js?rr=37'

from firefox

LL

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: SQUID 4.12 (Debian 10, OpenSSL 1.1.1d) - SSL bump no server helllo

Amos Jeffries
Administrator
In reply to this post by Loučanský Lukáš


Sent from my alcatel U5
On 17/06/2020 09:36, Lukáš Loučanský wrote:


> But - according to
> https://github.com/squid-cache/squid/commit/eec67f04490a477d69891c8b05a94bea05e5efbfGREASE 
> - as unknown extensions is meant to be ignored (?). The same said here
> https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/d_f6higCJzcBut 
> - these information are years old - so I guess squid already does the
> right thing.
>

This is not a safe assumption. Squid tries to use the TLS library for as much as possible, but there are many bits like extension handling which have to be rewritten for SSL-Bump to work. Those are all recent code additions.


> Anyway - with debug_options ALL,1 83,2:
>
> 2020/06/16 23:24:34.831 kid2| 83,2| client_side.cc(3180)
> parseTlsHandshake: error on FD 22: check failed: vMajor == 3
>     exception location: Handshake.cc(119) ParseProtocolVersion
>

That is somewhat useful. TLS version being received is not valid.


Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: SQUID 4.12 (Debian 10, OpenSSL 1.1.1d) - SSL bump no server helllo

Loučanský Lukáš
In reply to this post by Loučanský Lukáš

> That is somewhat useful. TLS version being received is not valid.

Ok - although this is squid users phorum - this could be even more useful:

Firefox - http://download.kjj.cz/pub/ssl/firefox.txt it goes throught everything to the GET / HTTP/1.1 request

Chrome - http://download.kjj.cz/pub/ssl/chrome.txt - it goes from
2020/06/17 08:06:31.292 kid1| 93,7| HttpRequest.cc(63) ~HttpRequest: destructed, this=0x55e730f38e50
2020/06/17 08:06:31.292 kid2| 24,7| BinaryTokenizer.cc(65) got: supported_version.major=202 occupying 1 bytes @0 in 0x7ffd9ba4a0f0.
2020/06/17 08:06:31.292 kid1| 24,8| SBuf.cc(70) ~SBuf: SBuf71215602 destructed
2020/06/17 08:06:31.292 kid2| 24,7| BinaryTokenizer.cc(65) got: supported_version.minor=202 occupying 1 bytes @1 in 0x7ffd9ba4a0f0.
2020/06/17 08:06:31.292 kid1| 24,8| SBuf.cc(70) ~SBuf: SBuf71215601 destructed

to
2020/06/17 08:06:31.292 kid2| 0,3| Handshake.cc(119) ParseProtocolVersion: check failed: vMajor == 3
    exception location: Handshake.cc(119) ParseProtocolVersion

It is not working in all chrome based browsers - Edge, Opera... It is working in the MSIE and FF

LL

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: SQUID 4.12 (Debian 10, OpenSSL 1.1.1d) - SSL bump no server helllo

Loučanský Lukáš
Found this:

2020/06/17 08:06:31.292 kid2| 24,7| BinaryTokenizer.cc(74) got: SupportedVersions.octets= caca0304030303020301 occupying 10 bytes @1 in 0x7ffd9ba4a0b0.
0x0301 - 0x0304 -> TLS versions to TLS1.3

0xcaca = non-existent

(a few lines further:)
BinaryTokenizer.cc(65) got: supported_version.major=202 occupying 1 bytes @0 in 0x7ffd9ba4a0f0.

Note 0xCA = 202 dec

Another examples:
2020/06/17 08:06:31.312 kid1| 24,7| BinaryTokenizer.cc(74) got: SupportedVersions.octets= 3a3a0304030303020301 occupying 10 bytes @1 in 0x7ffe348a1f30.

2020/06/17 08:06:31.312 kid1| 24,7| BinaryTokenizer.cc(65) got: supported_version.major=58 occupying 1 bytes @0 in 0x7ffe348a1f70.

Note 0x3A = 58 dec

2020/06/17 08:06:31.324 kid1| 24,7| BinaryTokenizer.cc(74) got: SupportedVersions.octets= aaaa0304030303020301 occupying 10 bytes @1 in 0x7ffe348a1f30.
2020/06/17 08:06:31.324 kid1| 24,7| BinaryTokenizer.cc(65) got: supported_version.minor=170 occupying 1 bytes @1 in 0x7ffe348a1f70.

Note 0xAA = 170 dec


So - I think this is a) badly pased string in /parser/BinaryTokenizer.cc (not likely), or b) in /security/HandShake.cc (line 526 and beyond)
Security::HandShakeParser does not ignore obviously nonse version

What I see is - that it calls tokenizer to get tkVersions, then asks ParseProtocolVersion to check it. I think that code ParseProtocolVersion checks for version 0.2 OR expects version 3.x - but gets versions 202 or 58 etc.

It seems logical to my limited knowledge to check for and ignore uknown versions (GREASed????). I think this is the while statement involved

while (!tkVersions.atEnd()) {
            const auto version = ParseProtocolVersion(tkVersions, "supported_version");
            if (!supportedVersionMax || TlsVersionEarlierThan(supportedVersionMax, version))
                supportedVersionMax = version;
        }

It calls parser - according to
2020/06/17 08:06:31.312 kid1| 0,3| Handshake.cc(119) ParseProtocolVersion: check failed: vMajor == 3    exception location: Handshake.cc(119) ParseProtocolVersion

It fails while calling it - so the check must be before calling ParseProtocolVersion or while in it - there is statement Must(vMajor==3) on line 119 - so I think this is the breakpoint call. Would simple if (vMajor <= 3)... Statement be  sufficient? What value it should return in case of non-parsable version? Sure not any value or some arbitrary value such as TLS1.something or SSLv3 ... It goes through SSLv2 to SSLv3 (implies vMajor = 3) and for versions >3.0 returns TLS1.vMinor-1 (???). So what it should do if it's called with version 0xCACA or 0x3A3A - I think that there should be check in the mentioned while statement - but it involves parsing major and minor version. This already does ParseProtocolVersion. But I think the goal of this is to find the max supported TLS version - so it should not fail on non-existent versions. So I think the mentioned while statement should sort this out, not calling parser to ask for TLS version for "random" numbers.

LL



-----Original Message-----
From: squid-users [mailto:[hidden email]] On Behalf Of Loučanský Lukáš
Sent: Wednesday, June 17, 2020 9:11 AM
To: [hidden email]
Subject: Re: [squid-users] SQUID 4.12 (Debian 10,OpenSSL 1.1.1d) - SSL bump no server helllo


> That is somewhat useful. TLS version being received is not valid.

Ok - although this is squid users phorum - this could be even more useful:

Firefox - http://download.kjj.cz/pub/ssl/firefox.txt it goes throught everything to the GET / HTTP/1.1 request

Chrome - http://download.kjj.cz/pub/ssl/chrome.txt - it goes from
2020/06/17 08:06:31.292 kid1| 93,7| HttpRequest.cc(63) ~HttpRequest: destructed, this=0x55e730f38e50
2020/06/17 08:06:31.292 kid2| 24,7| BinaryTokenizer.cc(65) got: supported_version.major=202 occupying 1 bytes @0 in 0x7ffd9ba4a0f0.
2020/06/17 08:06:31.292 kid1| 24,8| SBuf.cc(70) ~SBuf: SBuf71215602 destructed
2020/06/17 08:06:31.292 kid2| 24,7| BinaryTokenizer.cc(65) got: supported_version.minor=202 occupying 1 bytes @1 in 0x7ffd9ba4a0f0.
2020/06/17 08:06:31.292 kid1| 24,8| SBuf.cc(70) ~SBuf: SBuf71215601 destructed

to
2020/06/17 08:06:31.292 kid2| 0,3| Handshake.cc(119) ParseProtocolVersion: check failed: vMajor == 3
    exception location: Handshake.cc(119) ParseProtocolVersion

It is not working in all chrome based browsers - Edge, Opera... It is working in the MSIE and FF

LL

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: SQUID 4.12 (Debian 10, OpenSSL 1.1.1d) - SSL bump no server helllo

Loučanský Lukáš
This is the most naïve and dirtiest effort but I don't know where else it's called - not going to check it and fix calling it with nonsense numbers - so I went like this:

/// parse TLS ProtocolVersion (uint16) and convert it to AnyP::ProtocolVersion
static AnyP::ProtocolVersion
ParseProtocolVersion(Parser::BinaryTokenizer &tk, const char *contextLabel = ".version")
{
    Parser::BinaryTokenizerContext context(tk, contextLabel);
    uint8_t vMajor = tk.uint8(".major");
    uint8_t vMinor = tk.uint8(".minor");

if (vMajor>3)      return AnyP::ProtocolVersion(AnyP::PROTO_TLS, 1, 0);

    if (vMajor == 0 && vMinor == 2)
        return AnyP::ProtocolVersion(AnyP::PROTO_SSL, 2, 0);

    Must(vMajor == 3);
    if (vMinor == 0)
        return AnyP::ProtocolVersion(AnyP::PROTO_SSL, 3, 0);

    return AnyP::ProtocolVersion(AnyP::PROTO_TLS, 1, (vMinor - 1));
}


So - if someone tries to fool us with random numbers - rule it out as TLS 1.0. I know it deserves more - this code does what it is not mean to be doing etc. etc. (for every version >3 returns something) But:

2020/06/17 13:02:12.978 kid2| 24,7| BinaryTokenizer.cc(65) got: Extension.type=43 occupying 2 bytes @164 in 0x7ffcd4777170.
2020/06/17 13:02:12.978 kid2| 24,7| BinaryTokenizer.cc(65) got: Extension.data.length=11 occupying 2 bytes @166 in 0x7ffcd4777170.
2020/06/17 13:02:12.978 kid2| 24,8| SBuf.cc(38) SBuf: SBuf15611 created from id SBuf15576
2020/06/17 13:02:12.978 kid2| 24,7| BinaryTokenizer.cc(74) got: Extension.data.octets= 0a7a7a0304030303020301 occupying 11 bytes @168 in 0x7ffcd4777170.
2020/06/17 13:02:12.978 kid2| 24,8| SBuf.cc(70) ~SBuf: SBuf15611 destructed
2020/06/17 13:02:12.978 kid2| 24,7| BinaryTokenizer.cc(57) got: Extension occupying 15 bytes @164 in 0x7ffcd4777170.
2020/06/17 13:02:12.978 kid2| 24,8| SBuf.cc(38) SBuf: SBuf15612 created from id SBuf15610
2020/06/17 13:02:12.978 kid2| 24,7| BinaryTokenizer.cc(65) got: SupportedVersions.length=10 occupying 1 bytes @0 in 0x7ffcd4776fd0.
2020/06/17 13:02:12.978 kid2| 24,8| SBuf.cc(38) SBuf: SBuf15613 created from id SBuf15612
2020/06/17 13:02:12.978 kid2| 24,7| BinaryTokenizer.cc(74) got: SupportedVersions.octets= 7a7a0304030303020301 occupying 10 bytes @1 in 0x7ffcd4776fd0.
2020/06/17 13:02:12.979 kid2| 24,8| SBuf.cc(38) SBuf: SBuf15614 created from id SBuf15613
2020/06/17 13:02:12.979 kid2| 24,8| SBuf.cc(70) ~SBuf: SBuf15613 destructed
2020/06/17 13:02:12.979 kid2| 24,7| BinaryTokenizer.cc(65) got: supported_version.major=122 occupying 1 bytes @0 in 0x7ffcd4777010.
2020/06/17 13:02:12.979 kid2| 24,7| BinaryTokenizer.cc(65) got: supported_version.minor=122 occupying 1 bytes @1 in 0x7ffcd4777010.
2020/06/17 13:02:12.979 kid2| 24,7| BinaryTokenizer.cc(65) got: supported_version.major=3 occupying 1 bytes @2 in 0x7ffcd4777010.
2020/06/17 13:02:12.979 kid2| 24,7| BinaryTokenizer.cc(65) got: supported_version.minor=4 occupying 1 bytes @3 in 0x7ffcd4777010.
2020/06/17 13:02:12.979 kid2| 24,7| BinaryTokenizer.cc(65) got: supported_version.major=3 occupying 1 bytes @4 in 0x7ffcd4777010.
2020/06/17 13:02:12.979 kid2| 24,7| BinaryTokenizer.cc(65) got: supported_version.minor=3 occupying 1 bytes @5 in 0x7ffcd4777010.
2020/06/17 13:02:12.979 kid2| 24,7| BinaryTokenizer.cc(65) got: supported_version.major=3 occupying 1 bytes @6 in 0x7ffcd4777010.
2020/06/17 13:02:12.979 kid2| 24,7| BinaryTokenizer.cc(65) got: supported_version.minor=2 occupying 1 bytes @7 in 0x7ffcd4777010.
2020/06/17 13:02:12.979 kid2| 24,7| BinaryTokenizer.cc(65) got: supported_version.major=3 occupying 1 bytes @8 in 0x7ffcd4777010.
2020/06/17 13:02:12.979 kid2| 24,7| BinaryTokenizer.cc(65) got: supported_version.minor=1 occupying 1 bytes @9 in 0x7ffcd4777010.
2020/06/17 13:02:12.979 kid2| 24,8| SBuf.cc(70) ~SBuf: SBuf15614 destructed
2020/06/17 13:02:12.979 kid2| 24,8| SBuf.cc(70) ~SBuf: SBuf15612 destructed
2020/06/17 13:02:12.979 kid2| 83,7| Handshake.cc(594) parseSupportedVersionsExtension: found TLS/1.3
2020/06/17 13:02:12.979 kid2| 24,8| SBuf.cc(70) ~SBuf: SBuf15610 destructed

Note 7a7a0304030303020301, 0x7A = 122

I think fixing it everywhere would involve BinaryTokenizing extension string (like  tkVersions) and check every value sent to  ParseProtocolVersion. In the HandShake.cc file on about six occassions. It seems very likely that *some* vendors will send nonsense values to the other parts as well. So it would be nice to have them all sanitized. For me it looks like Google initiative - but I could be wrong. Anyway - what seemed to be problem with TLS on my box now seems to be problem with additive, random numbers in the supported versions string - waiting for someone to investigate it further...

LL

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: SQUID 4.12 (Debian 10, OpenSSL 1.1.1d) - SSL bump no server helllo

Loučanský Lukáš
 
Just noticed that github version of HandShake.cc is much better "patched" than my humble,pitty attempt to quick-fix the parser. So in the light of self investigation and the lack of information and experience (I'm sorry for that) I maybe over-reacted. But now it seems both modifications made it working (recompiled with github version of Handshake.cc). As I have no idea what to expect from GREASEd connections - I think it would be better - as I've already wrote - to check and sanitize every TLS header input... (version 4.12 from 9th June doesn't do that)

LL
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: SQUID 4.12 (Debian 10, OpenSSL 1.1.1d) - SSL bump no server helllo

Alex Rousskov
On 6/17/20 9:14 AM, Loučanský Lukáš wrote:

> Just noticed that github version of HandShake.cc is much better "patched"

Squid should have proper support for GREASEd TLS version values (and
more!) since master/v6 commit eec67f0. That very recent change has not
been ported to earlier Squid versions yet.

    https://github.com/squid-cache/squid/commit/eec67f0

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Squid 4.12 Arch Linux Google Chrome fails - OpenSSL 1.1.1g (was Re: SQUID 4.12 (Debian 10, OpenSSL 1.1.1d) - SSL bump no server helllo)

Amish
In reply to this post by Loučanský Lukáš

On 16/06/20 1:13 pm, Loučanský Lukáš wrote:

> But the client on the intercepted connection (via changed routing table under mikrotik and then prerouted to correct squid ports for http and ssl traffic) running Chrome 83 http://download.kjj.cz/pub/ssl/idnes.cz_chrome.83.0.4103.97.pcapng sends ClientHello - and no ServerHello is received. I've tcpdumped outgoing interface on the squid box - and there was no actual connection to the desired server.
> In the access.log there is something like 1592212170.495      2 10.0.0.40 NONE_ABORTED/200 0 CONNECT 185.17.117.32:443 - HIER_NONE/- -
>  
> But - same client, same network, same network running Firefox 77 http://download.kjj.cz/pub/ssl/idnes.cz_firefox.77.0.1.pcapng  gets ServerHello after it's ClientHello - they exchange information, exchange ciphers etc. and the web page is loaded. I've checked https certificate details - it's been issued by my CA.
>
>
> access.log:
>  
> 1592212156.764      8 10.0.0.40 TCP_MISS/301 196 GET http://idnes.cz/ - ORIGINAL_DST/185.17.117.32 -
> 1592212156.774      2 10.0.0.40 NONE/200 0 CONNECT 185.17.117.32:443 - HIER_NONE/- -
> 1592212156.825     38 10.0.0.40 TCP_MISS/302 777 GET https://idnes.cz/ - ORIGINAL_DST/185.17.117.32 text/html
> 1592212156.840      7 10.0.0.40 NONE/200 0 CONNECT 185.17.117.32:443 - HIER_NONE/- -
> 1592212156.893     28 10.0.0.40 TCP_CLIENT_REFRESH_MISS/200 40086 GET https://www.idnes.cz/ - ORIGINAL_DST/185.17.117.32 text/html
>
>
> So in Firefox - it seems to be working

I am using Arch Linux and today I upgraded squid to 4.12 (from 4.10)

I am observing very similar issue.

Clients make HTTPS request via CONNECT to port 8080.

I have configured SSL bump but it is "effectively" deactivated via
following ACL

http_port 8080 ssl-bump generate-host-certificates=on
tls-cert=/etc/squid/ssl_cert/squid.pem
tls-dh=prime256v1:/etc/squid/ssl_cert/dhparam.pem

tls_outgoing_options cafile=/etc/ssl/cert.pem

tls_outgoing_options
cipher=ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS

ssl_bump splice ssl_step1 nosslbump_ips # (acl type src)
ssl_bump peek ssl_step1
ssl_bump splice nosslbump_domains # (acl type ssl::server_name_regex)
(more ssl_bump lines not shown)

nosslbump_domains contains ".*" - so effectively nothing is bumped.

Firefox and IE work fine. But in Google chrome - sites dont open.

Access log shows NONE_ABORTED (for google chrome).

And packet sniffer shows FIN, ACK sent by squid. (I have not gone in
details as I dont understand packet details)

Am I doing anything wrong? If not, then is there any temporary
workaround without downgrading squid?

Please guide,

Thank you

Amish.

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Squid 4.12 Arch Linux Google Chrome fails - OpenSSL 1.1.1g

Alex Rousskov
On 6/29/20 11:18 AM, Amish wrote:
> I am using Arch Linux and today I upgraded squid to 4.12 (from 4.10)
> Firefox and IE work fine. But in Google chrome - sites dont open.

You may need a fix for TLS GREASEd values. The following master/v6 PR
has not been backported to v4 yet AFAICT, but it might work "as is":

    https://github.com/squid-cache/squid/pull/663

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Squid 4.12 Arch Linux Google Chrome fails - OpenSSL 1.1.1g

Amish
On 30/06/20 1:22 am, Alex Rousskov wrote:
> On 6/29/20 11:18 AM, Amish wrote:
>> I am using Arch Linux and today I upgraded squid to 4.12 (from 4.10)
>> Firefox and IE work fine. But in Google chrome - sites dont open.
> You may need a fix for TLS GREASEd values. The following master/v6 PR
> has not been backported to v4 yet AFAICT, but it might work "as is":
>
>      https://github.com/squid-cache/squid/pull/663
>
> Alex.

Thank you very much for your response. I will try it soon.

But I am confused that PR has just 1 file changed, but if I read the
comments in PR, it has many more commits.

So is the single file change enough? OR I need to apply all the commits?

Also just wondering that should we not release 4.13 because chrome is a
most popular browser and so this kind of needs urgent fix.

Thanks and regards,

Amish.

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Squid 4.12 Arch Linux Google Chrome fails - OpenSSL 1.1.1g

Alex Rousskov
On 6/29/20 8:56 PM, Amish wrote:
> On 30/06/20 1:22 am, Alex Rousskov wrote:
>> On 6/29/20 11:18 AM, Amish wrote:
>>> I am using Arch Linux and today I upgraded squid to 4.12 (from 4.10)
>>> Firefox and IE work fine. But in Google chrome - sites dont open.
>> You may need a fix for TLS GREASEd values. The following master/v6 PR
>> has not been backported to v4 yet AFAICT, but it might work "as is":
>>
>>      https://github.com/squid-cache/squid/pull/663

> But I am confused that PR has just 1 file changed, but if I read the
> comments in PR, it has many more commits.

Many commits may modify one file. If you are not familiar with git, the
easiest way to get cumulative PR changes is to add ".diff" to the PR
URL. See the very bottom of any PR page on GitHub for the link/reminder.

    https://github.com/squid-cache/squid/pull/663.diff

An arguably better way is to find the (cumulative) official commit
itself, but that requires navigating sometimes-confusing GitHub PR page
history and/or some knowledge of git and Squid merge procedures. In this
particular case, the official (master) commit is eec67f0:

    https://github.com/squid-cache/squid/commit/eec67f0
    https://github.com/squid-cache/squid/commit/eec67f0.diff


> So is the single file change enough? OR I need to apply all the
> commits?

You do not need to replay individual PR commits. When you use the
PR.diff trick, you will get a patch with all the commits squashed together.


BTW, there is a similar PR.patch trick, but it will give you a patch
with all the individual PR commits replayed in the right order. In most
cases, replaying individual commits may cause more conflicts.


HTH,

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Squid 4.12 Arch Linux Google Chrome fails - OpenSSL 1.1.1g

Amish

On 30/06/20 6:37 pm, Alex Rousskov wrote:

> On 6/29/20 8:56 PM, Amish wrote:
>> On 30/06/20 1:22 am, Alex Rousskov wrote:
>>> On 6/29/20 11:18 AM, Amish wrote:
>>>> I am using Arch Linux and today I upgraded squid to 4.12 (from 4.10)
>>>> Firefox and IE work fine. But in Google chrome - sites dont open.
>>> You may need a fix for TLS GREASEd values. The following master/v6 PR
>>> has not been backported to v4 yet AFAICT, but it might work "as is":
>>>
>>>       https://github.com/squid-cache/squid/pull/663
>> But I am confused that PR has just 1 file changed, but if I read the
>> comments in PR, it has many more commits.
> Many commits may modify one file. If you are not familiar with git, the
> easiest way to get cumulative PR changes is to add ".diff" to the PR
> URL. See the very bottom of any PR page on GitHub for the link/reminder.
>
>      https://github.com/squid-cache/squid/pull/663.diff
>
> HTH,
>
> Alex.

You misunderstood my question or may be I didnt explain it in detail.

I know how to use git. My question was that in that PR, I saw commits
modifying files like Hasdshake.h, bio.cc.

But in final PR only modification was done to Handshake.cc

So I got confused. But I guess, the final PR is only what matters for my
problem.

Thanks for the response,

Regards,

Amish.

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users