Discussion:
Transparent proxy with Peek and Splice feature.
(too old to reply)
Vadim Rogoziansky
2014-11-25 18:22:07 UTC
Permalink
Hello All.

My goal is to do ssl bumping in transparent proxy mode with domain
exclude possibility.
Let me tell you about squid's strange behaviour when I'm trying to do it.

In browsers it says something like this:
/This server could not prove that it is www.ukr.net; its security
certificate is from212.42.76.253. This may be caused by a
misconfiguration or an attacker intercepting your connection.//
//NET::ERR_CERT_COMMON_NAME_INVALID//
//Subject: 212.42.76.253//
/
Looks like squid takes the CN from the certificate as IP address of the
destination domain.
But, everything works smoothly when I use proxy in non transparent mode
and put it to the browser directly . I can successfully bypass bad sites
and do ssl bumping on others. There are no certificate errors except of
some of them, you know)

My OS is /Centos 6.5 //2.6.32-358.6.2.el6.x86_64/
My squid's version:
//opt/squid/sbin/squid -v//
//Squid Cache: Version 3.5.0.2//
//Service Name: squid//
//configure options: '--with-openssl' '--enable-linux-netfilter'
'--disable-ipv6' '--enable-icap-client' '--enable-ssl-crtd'
'--prefix=/opt/squid' '--enable-external-acl-helpers=none'
'--enable-auth-negotiate=none' '--enable-follow-x-forwarded-for'
'--disable-auth-ntlm' '--disable-arch-native' '--enable-wccpv2'
'--enable-snmp'
'PKG_CONFIG_PATH=/usr/lib64/pkgconfig:/usr/share/pkgconfig'
--enable-ltdl-convenience//
/
My iptables which is doing redirecting to internal squid ports: /
//Table: nat//
//Chain PREROUTING (policy ACCEPT)//
//num target prot opt source destination//
//1 ACCEPT tcp -- 0.0.0.0/0 192.168.0.121 tcp dpt:443 /*
accept connection *///
//2 REDIRECT tcp -- 192.168.0.0/24 0.0.0.0/0 tcp
dpt:443 /* redirect */ redir ports 3132//
//3 ACCEPT tcp -- 0.0.0.0/0 192.168.0.121 tcp dpt:80 /*
accept connection *///
//4 REDIRECT tcp -- 192.168.0.0/24 0.0.0.0/0 tcp dpt:80
/* redirect */ redir ports 3131/

Here is my squid configuration file:
___________________________
visible_hostname local.local
always_direct allow all
dns_nameservers 8.8.8.8

acl step2 at_step SslBump2
ssl_bump stare step2 all
acl sslBumpDeniedDstDomain dstdomain ukr.net www.ukr.net
ssl_bump splice sslBumpDeniedDstDomain
ssl_bump bump all

http_port 3128 ssl-bump generate-host-certificates=on
dynamic_cert_mem_cache_size=4MB cert=/opt/squid/var/ssl_cert/cert.pem

http_port 3131 transparent
https_port 3132 transparent ssl-bump generate-host-certificates=on
dynamic_cert_mem_cache_size=4MB cert=/opt/squid/var/ssl_cert/cert.pem

http_access allow all

sslcrtd_program /opt/squid/libexec/ssl_crtd -s /opt/squid/var/ssl_db -M 4MB
sslcrtd_children 15

logformat logaccess [%{%d/%b/%Y %H:%M:%S}tl] %>a %Ss/%03>Hs %<st %rm
%ru %un %Sh/%<A %mt
access_log daemon:/opt/squid/var/logs/access.log logaccess
______________________________________________________

Also, I've run squid like this *//opt/squid/sbin/squid -N -X -d 2/* and
got interesting strings like:
/2014/11/26 04:28:08.622| client_side.cc(3849)
httpsSslBumpAccessCheckDone: sslBump needed
for//*local=212.42.76.246:443*////*remote=192.168.0.122:63719*//FD 40
flags=33 method 5/

Here, the local and remote IP addresses are switched (I checked such
lines when went through the squid directly).

Please, tell me what can be wrong in configuration or squid. I can
provide you with any logs which you may need.
BTW, cache.log is clean.
________________
Best regards
Amos Jeffries
2014-11-26 09:33:32 UTC
Permalink
Post by Vadim Rogoziansky
Hello All.
My goal is to do ssl bumping in transparent proxy mode with domain
exclude possibility. Let me tell you about squid's strange
behaviour when I'm trying to do it.
In browsers it says something like this: /This server could not
prove that it is www.ukr.net; its security certificate is
from212.42.76.253. This may be caused by a misconfiguration or an
attacker intercepting your connection.//
//NET::ERR_CERT_COMMON_NAME_INVALID// //Subject: 212.42.76.253// /
Looks like squid takes the CN from the certificate as IP address of
the destination domain.
Squid takes the IP address from the TCP packet. Which is all that is
available in NAT intercepted traffic at bumping step #1.

The ACLs you have therefore determine that "bump" action is to happen.
Correct?

The cert details are therefore mimic'ed from what gets delivered by
the server.

It may be that the server is depending on SNI to generate its own
cert, but since Squid deos not have that domain name already an
IP-based cert comes back.

It may also be that some ISP upstream of you is bumping the encryption
with client-first method.
Post by Vadim Rogoziansky
But, everything works smoothly when I use proxy in non transparent
mode and put it to the browser directly .
In which case the browser sends domain name to the proxy in its
CONNECT message starting the HTTPS. The possible results are very
different.

Amos
Vadim Rogoziansky
2014-11-27 13:48:37 UTC
Permalink
Hello Amos.

Thank you for answer.

There was made an investigation related to squid's peek and splice
issues in transparent mode.
One-line explanation is as follows - in intercept mode squid can't get a
server host name from the request header and uses clent IP address
instead for both fake cert generation and as a SNI record in server bump
SSL handshaking. This is the root of the problem. However this can be
fixed if squid uses SNI field taken from client TLS Hello message for
that purposes. Can you hack squid in this way? What do you think?

Many thanks.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Vadim Rogoziansky
Hello All.
My goal is to do ssl bumping in transparent proxy mode with domain
exclude possibility. Let me tell you about squid's strange
behaviour when I'm trying to do it.
In browsers it says something like this: /This server could not
prove that it is www.ukr.net; its security certificate is
from212.42.76.253. This may be caused by a misconfiguration or an
attacker intercepting your connection.//
//NET::ERR_CERT_COMMON_NAME_INVALID// //Subject: 212.42.76.253// /
Looks like squid takes the CN from the certificate as IP address of
the destination domain.
Squid takes the IP address from the TCP packet. Which is all that is
available in NAT intercepted traffic at bumping step #1.
The ACLs you have therefore determine that "bump" action is to happen.
Correct?
The cert details are therefore mimic'ed from what gets delivered by
the server.
It may be that the server is depending on SNI to generate its own
cert, but since Squid deos not have that domain name already an
IP-based cert comes back.
It may also be that some ISP upstream of you is bumping the encryption
with client-first method.
Post by Vadim Rogoziansky
But, everything works smoothly when I use proxy in non transparent
mode and put it to the browser directly .
In which case the browser sends domain name to the proxy in its
CONNECT message starting the HTTPS. The possible results are very
different.
Amos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBAgAGBQJUdZ5sAAoJELJo5wb/XPRj0qIIANBjuFvq45hPmcaj/NYL6bza
7ttt5Gn+tn8E5KH7T4wfQhUXr91UIsYWfOswfnVAAlBevIO/iFVoDN5hAOveuhIl
ra/0eGti1EpZ3LHJiAqmo0mHsrz3v9+PAduVrXgUJLyYDiM0xctg0nRhj2u166VX
j0IL3g8CKEw+KiWVJM9HdLaDEz9fYtHBO8UHhKDDE94O9yxScIvB+GAhN4YlTtrE
z65VJkSCEw+3vH6XcrrkF2aEnB20jeEGiV5puO2cPoJpgcg3ic8sMVEfa/Z1qwqa
KCkj2XI28wBCIovCV+AfBhpvW0o8eVFbt4ESodLTmwjUvU+m8zxky/9cjO5kyLE=
=kgug
-----END PGP SIGNATURE-----
_______________________________________________
squid-users mailing list
http://lists.squid-cache.org/listinfo/squid-users
Amos Jeffries
2014-11-29 04:17:19 UTC
Permalink
Post by Vadim Rogoziansky
Hello Amos.
Thank you for answer.
There was made an investigation related to squid's peek and splice
issues in transparent mode. One-line explanation is as follows - in
intercept mode squid can't get a server host name from the request
header and uses clent IP address instead for both fake cert
generation and as a SNI record in server bump SSL handshaking. This
is the root of the problem. However this can be fixed if squid uses
SNI field taken from client TLS Hello message for that purposes.
Can you hack squid in this way? What do you think?
I think peek-n-splice is supposed to already be doing that.

However it does depend on whether you are bumping the connection at
step 1 (before ClientHello), step 2 (after ClientHello, before
ServerHello), or step 3 (after both ClientHello and ServerHello) of
the TLS handshake whether the SNI details are present.

Amos
Vadim Rogoziansky
2014-12-02 18:32:36 UTC
Permalink
Yeap, squid perfectly "splice" the destination domain after step1 or
step2 or step3 when the browser is set to use proxy directly.
But, it does not work in case of transparent proxy. Squid uses client IP
address instead of SNI details.

I've attached squid debug log.
The example of using client IP address is below:
2014/11/27 01:15:22.851| DomainData.cc(110) match: aclMatchDomainList:
'212.42.77.232' NOT found

Thank you guys.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Vadim Rogoziansky
Hello Amos.
Thank you for answer.
There was made an investigation related to squid's peek and splice
issues in transparent mode. One-line explanation is as follows - in
intercept mode squid can't get a server host name from the request
header and uses clent IP address instead for both fake cert
generation and as a SNI record in server bump SSL handshaking. This
is the root of the problem. However this can be fixed if squid uses
SNI field taken from client TLS Hello message for that purposes.
Can you hack squid in this way? What do you think?
I think peek-n-splice is supposed to already be doing that.
However it does depend on whether you are bumping the connection at
step 1 (before ClientHello), step 2 (after ClientHello, before
ServerHello), or step 3 (after both ClientHello and ServerHello) of
the TLS handshake whether the SNI details are present.
Amos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBAgAGBQJUeUjPAAoJELJo5wb/XPRj6QEIAOHrR8wmDcjkfgUh2UtPwpHP
vVkPMEuIrUq9Gxx3uSojCZjlFJPuCQ2UafS1p8LuxcEQ+TRmUFbAu4AkKoO2RoZ5
7fCGoiXTwn4TzFf0pLh9SPBq9j12OJ3uT28EEqbILrT0sbKP02xK/qiJfCLR61Ev
vprAdggapbKg/ns1l1H3BBgZR2A4W/abQPIq6/Eu/r+7nYK6L2oOdqPDWTJjudMV
8D9sdOD9mYYryrdptU0GLh9Q/V5QEhipSkuA936iZ0Dfa2ZSr4gphJyaRAFWSMf3
q502lZy+ASkDa2vAbjALRBgn3VwYWl8KBQcypUKF4UXtaLtF0EIrLMun+p4QxUM=
=44aG
-----END PGP SIGNATURE-----
_______________________________________________
squid-users mailing list
http://lists.squid-cache.org/listinfo/squid-users
Vadim Rogoziansky
2014-12-09 11:52:38 UTC
Permalink
Yeap, squid perfectly "splice" the destination domain after step1 or
step2 or step3 when the browser is set to use proxy directly.
But, it does not work in case of transparent proxy. Squid uses the
destination IP address instead of SNI details.

The example of using client IP address is below:
2014/11/27 01:15:22.851| DomainData.cc(110) match: aclMatchDomainList:
'212.42.77.232' NOT found

Thank you guys.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Vadim Rogoziansky
Hello Amos.
Thank you for answer.
There was made an investigation related to squid's peek and splice
issues in transparent mode. One-line explanation is as follows - in
intercept mode squid can't get a server host name from the request
header and uses clent IP address instead for both fake cert
generation and as a SNI record in server bump SSL handshaking. This
is the root of the problem. However this can be fixed if squid uses
SNI field taken from client TLS Hello message for that purposes.
Can you hack squid in this way? What do you think?
I think peek-n-splice is supposed to already be doing that.
However it does depend on whether you are bumping the connection at
step 1 (before ClientHello), step 2 (after ClientHello, before
ServerHello), or step 3 (after both ClientHello and ServerHello) of
the TLS handshake whether the SNI details are present.
Amos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBAgAGBQJUeUjPAAoJELJo5wb/XPRj6QEIAOHrR8wmDcjkfgUh2UtPwpHP
vVkPMEuIrUq9Gxx3uSojCZjlFJPuCQ2UafS1p8LuxcEQ+TRmUFbAu4AkKoO2RoZ5
7fCGoiXTwn4TzFf0pLh9SPBq9j12OJ3uT28EEqbILrT0sbKP02xK/qiJfCLR61Ev
vprAdggapbKg/ns1l1H3BBgZR2A4W/abQPIq6/Eu/r+7nYK6L2oOdqPDWTJjudMV
8D9sdOD9mYYryrdptU0GLh9Q/V5QEhipSkuA936iZ0Dfa2ZSr4gphJyaRAFWSMf3
q502lZy+ASkDa2vAbjALRBgn3VwYWl8KBQcypUKF4UXtaLtF0EIrLMun+p4QxUM=
=44aG
-----END PGP SIGNATURE-----
_______________________________________________
squid-users mailing list
http://lists.squid-cache.org/listinfo/squid-users
Vadim Rogoziansky
2014-12-19 12:29:16 UTC
Permalink
Any ideas, any thoughts?
Thanks.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Vadim Rogoziansky
Hello Amos.
Thank you for answer.
There was made an investigation related to squid's peek and splice
issues in transparent mode. One-line explanation is as follows - in
intercept mode squid can't get a server host name from the request
header and uses clent IP address instead for both fake cert
generation and as a SNI record in server bump SSL handshaking. This
is the root of the problem. However this can be fixed if squid uses
SNI field taken from client TLS Hello message for that purposes.
Can you hack squid in this way? What do you think?
I think peek-n-splice is supposed to already be doing that.
However it does depend on whether you are bumping the connection at
step 1 (before ClientHello), step 2 (after ClientHello, before
ServerHello), or step 3 (after both ClientHello and ServerHello) of
the TLS handshake whether the SNI details are present.
Amos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBAgAGBQJUeUjPAAoJELJo5wb/XPRj6QEIAOHrR8wmDcjkfgUh2UtPwpHP
vVkPMEuIrUq9Gxx3uSojCZjlFJPuCQ2UafS1p8LuxcEQ+TRmUFbAu4AkKoO2RoZ5
7fCGoiXTwn4TzFf0pLh9SPBq9j12OJ3uT28EEqbILrT0sbKP02xK/qiJfCLR61Ev
vprAdggapbKg/ns1l1H3BBgZR2A4W/abQPIq6/Eu/r+7nYK6L2oOdqPDWTJjudMV
8D9sdOD9mYYryrdptU0GLh9Q/V5QEhipSkuA936iZ0Dfa2ZSr4gphJyaRAFWSMf3
q502lZy+ASkDa2vAbjALRBgn3VwYWl8KBQcypUKF4UXtaLtF0EIrLMun+p4QxUM=
=44aG
-----END PGP SIGNATURE-----
_______________________________________________
squid-users mailing list
http://lists.squid-cache.org/listinfo/squid-users
James Harper
2014-12-19 22:20:34 UTC
Permalink
The following "works" for me:

# intercept for transparent proxy of ssl connections
https_port 3130 name=transproxyssl intercept ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/usr/local/squid/etc/ca.pem

# just testing with my laptop
acl james_src arp 11:11:11:11:11:11

# name of port used for transparent ssl interception
acl transproxyssl myportname transproxyssl

ssl_bump stare transproxyssl james_src
ssl_bump bump james_src
ssl_bump splice all

But "works" is probably a bit of an exaggeration. I was seeing lots of this sort of thing in the logs:

Error negotiating SSL on FD 75: error:1409F07F:SSL routines:SSL3_WRITE_PENDING:bad write retry (1/-1/0)
hold write on SSL connection on FD 65
BUG 3556: FD 112 is not an open socket.
assertion failed: Read.cc:69: "fd_table[conn->fd].halfClosedReader != NULL"

And squid restarting a lot. This was with squid-3.5.0.2-20141121-r13666 and so hopefully I was seeing some bugs that are now fixed, and it's not that I am abusing the configuration or something...

I'm upgrading to the latest snapshot now for further testing.

James
-----Original Message-----
Behalf Of Vadim Rogoziansky
Sent: Friday, 19 December 2014 11:29 PM
Subject: Re: [squid-users] Transparent proxy with Peek and Splice feature.
Any ideas, any thoughts?
Thanks.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Vadim Rogoziansky
Hello Amos.
Thank you for answer.
There was made an investigation related to squid's peek and splice
issues in transparent mode. One-line explanation is as follows - in
intercept mode squid can't get a server host name from the request
header and uses clent IP address instead for both fake cert
generation and as a SNI record in server bump SSL handshaking. This
is the root of the problem. However this can be fixed if squid uses
SNI field taken from client TLS Hello message for that purposes.
Can you hack squid in this way? What do you think?
I think peek-n-splice is supposed to already be doing that.
However it does depend on whether you are bumping the connection at
step 1 (before ClientHello), step 2 (after ClientHello, before
ServerHello), or step 3 (after both ClientHello and ServerHello) of
the TLS handshake whether the SNI details are present.
Amos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBAgAGBQJUeUjPAAoJELJo5wb/XPRj6QEIAOHrR8wmDcjkfgUh2UtPw
pHP
vVkPMEuIrUq9Gxx3uSojCZjlFJPuCQ2UafS1p8LuxcEQ+TRmUFbAu4AkKoO2Ro
Z5
7fCGoiXTwn4TzFf0pLh9SPBq9j12OJ3uT28EEqbILrT0sbKP02xK/qiJfCLR61Ev
vprAdggapbKg/ns1l1H3BBgZR2A4W/abQPIq6/Eu/r+7nYK6L2oOdqPDWTJjud
MV
8D9sdOD9mYYryrdptU0GLh9Q/V5QEhipSkuA936iZ0Dfa2ZSr4gphJyaRAFWSMf
3
q502lZy+ASkDa2vAbjALRBgn3VwYWl8KBQcypUKF4UXtaLtF0EIrLMun+p4QxU
M=
=44aG
-----END PGP SIGNATURE-----
_______________________________________________
squid-users mailing list
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
http://lists.squid-cache.org/listinfo/squid-users
Loading...