ssl_bump - peek & splice logging IP rather than server name

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

ssl_bump - peek & splice logging IP rather than server name

Mark Hoare
Hi,

I’m trying to setup policy based routing on a gateway device pointing at a remote squid server to do transparent HTTP & HTTPS proxying with ssl_bump (peek & splice)

After quite a bit of pain getting policy based routing working on the gateway and local port redirection on the squid server, everything appears to be working except the access log still refers to the destination IP address in the TCP_TUNNEL rather than the SNI/TLS server name.

By increasing the debug level I can see that the SNI/TLS details are definitely being obtained during the request processing but for some reason they are not ending up in the access log.

Extract from cache log:
> 2016/12/31 14:18:01.966 kid1| 83,7| bio.cc(1110) parseV3Hello: Found server name: www.ssllabs.com
> 2016/12/31 14:18:02.351 kid1| 83,5| support.cc(259) ssl_verify_cb: SSL Certificate signature OK: /C=US/ST=California/L=Redwood City/O=Qualys, Inc./CN=ssllabs.com
> 2016/12/31 14:18:02.351 kid1| 83,4| support.cc(213) check_domain: Verifying server domain www.ssllabs.com to certificate name/subjectAltName ssllabs.com
> 2016/12/31 14:18:02.351 kid1| 83,4| support.cc(213) check_domain: Verifying server domain www.ssllabs.com to certificate name/subjectAltName *.ssllabs.com
> 2016/12/31 14:18:02.383 kid1| 83,5| PeerConnector.cc(307) serverCertificateVerified: HTTPS server CN: ssllabs.com bumped: local=<squid IP removed>:57790 remote=64.41.200.100:443 FD 14 flags=1

Extract from access log:
> 1483193882.790    870 <local ip removed> TCP_TUNNEL/200 5620 CONNECT 64.41.200.100:443 - ORIGINAL_DST/64.41.200.100 -

From the output above I would have expected some of the server name info to get into the access log.

Squid config below:

> debug_options ALL,7
>
> http_port 3128
>
> https_port 3130 intercept ssl-bump cert=/etc/squid/ssl_cert/squidCA.pem generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
>
> http_port 3131 intercept ssl-bump cert=/etc/squid/ssl_cert/squidCA.pem generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
>
> cache_dir ufs /var/spool/squid 200 16 256
> coredump_dir /var/spool/squid
>
> acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
> acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
> acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
> acl localnet src fc00::/7       # RFC 4193 local private network range
> acl localnet src fe80::/10      # RFC 4291 link-local (directly plugged) machines
>
> acl Safe_ports port 80 # http
> acl Safe_ports port 21 # ftp
> acl Safe_ports port 443 # https
> acl Safe_ports port 70 # gopher
> acl Safe_ports port 210 # wais
> acl Safe_ports port 1025-65535 # unregistered ports
> acl Safe_ports port 280 # http-mgmt
> acl Safe_ports port 488 # gss-http
> acl Safe_ports port 591 # filemaker
> acl Safe_ports port 777 # multiling http
>
> acl SSL_ports port 443
> acl CONNECT method CONNECT
>
> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports
>
> http_access allow localhost manager
> http_access deny manager
>
> refresh_pattern ^ftp: 1440 20% 10080
> refresh_pattern ^gopher: 1440 0% 1440
> refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
> refresh_pattern . 0 20% 4320
>
> ssl_bump peek all
> ssl_bump splice all
>
> always_direct allow all
>
> http_access allow localnet
> http_access allow localhost
>
> http_access deny all


Any suggestions gratefully received.

Thanks

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

Re: ssl_bump - peek & splice logging IP rather than server name

Mark Hoare
Sorry, should have included squid version details in original post:

Squid Cache: Version 3.5.20
Service Name: squid
configure options:  '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--disable-strict-error-checking' '--exec_prefix=/usr' '--libexecdir=/usr/lib64/squid' '--localstatedir=/var' '--datadir=/usr/share/squid' '--sysconfdir=/etc/squid' '--with-logdir=$(localstatedir)/log/squid' '--with-pidfile=$(localstatedir)/run/squid.pid' '--disable-dependency-tracking' '--enable-eui' '--enable-follow-x-forwarded-for' '--enable-auth' '--enable-auth-basic=DB,LDAP,MSNT-multi-domain,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB,SMB_LM,getpwnam' '--enable-auth-ntlm=smb_lm,fake' '--enable-auth-digest=file,LDAP,eDirectory' '--enable-auth-negotiate=kerberos' '--enable-external-acl-helpers=file_userip,LDAP_group,time_quota,session,unix_group,wbinfo_group' '--enable-cache-digests' '--enable-cachemgr-hostname=localhost' '--enable-delay-pools' '--enable-epoll' '--enable-ident-lookups' '--enable-linux-netfilter' '--enable-removal-policies=heap,lru' '--enable-snmp' '--enable-ssl-crtd' '--enable-storeio=aufs,diskd,ufs' '--enable-wccpv2' '--enable-esi' '--enable-ecap' '--with-aio' '--with-default-user=squid' '--with-dl' '--with-openssl' '--with-pthreads' '--disable-arch-native' '--disable-icap-client' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -fpie' 'LDFLAGS=-Wl,-z,relro  -pie -Wl,-z,relro -Wl,-z,now' 'CXXFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -fpie' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig’

Cheers

Mark

> On 31 Dec 2016, at 14:37, Mark Hoare <[hidden email]> wrote:
>
> Hi,
>
> I’m trying to setup policy based routing on a gateway device pointing at a remote squid server to do transparent HTTP & HTTPS proxying with ssl_bump (peek & splice)
>
> After quite a bit of pain getting policy based routing working on the gateway and local port redirection on the squid server, everything appears to be working except the access log still refers to the destination IP address in the TCP_TUNNEL rather than the SNI/TLS server name.
>
> By increasing the debug level I can see that the SNI/TLS details are definitely being obtained during the request processing but for some reason they are not ending up in the access log.
>
> Extract from cache log:
>> 2016/12/31 14:18:01.966 kid1| 83,7| bio.cc(1110) parseV3Hello: Found server name: www.ssllabs.com
>> 2016/12/31 14:18:02.351 kid1| 83,5| support.cc(259) ssl_verify_cb: SSL Certificate signature OK: /C=US/ST=California/L=Redwood City/O=Qualys, Inc./CN=ssllabs.com
>> 2016/12/31 14:18:02.351 kid1| 83,4| support.cc(213) check_domain: Verifying server domain www.ssllabs.com to certificate name/subjectAltName ssllabs.com
>> 2016/12/31 14:18:02.351 kid1| 83,4| support.cc(213) check_domain: Verifying server domain www.ssllabs.com to certificate name/subjectAltName *.ssllabs.com
>> 2016/12/31 14:18:02.383 kid1| 83,5| PeerConnector.cc(307) serverCertificateVerified: HTTPS server CN: ssllabs.com bumped: local=<squid IP removed>:57790 remote=64.41.200.100:443 FD 14 flags=1
>
> Extract from access log:
>> 1483193882.790    870 <local ip removed> TCP_TUNNEL/200 5620 CONNECT 64.41.200.100:443 - ORIGINAL_DST/64.41.200.100 -
>
> From the output above I would have expected some of the server name info to get into the access log.
>
> Squid config below:
>> debug_options ALL,7
>>
>> http_port 3128
>>
>> https_port 3130 intercept ssl-bump cert=/etc/squid/ssl_cert/squidCA.pem generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
>>
>> http_port 3131 intercept ssl-bump cert=/etc/squid/ssl_cert/squidCA.pem generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
>>
>> cache_dir ufs /var/spool/squid 200 16 256
>> coredump_dir /var/spool/squid
>>
>> acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
>> acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
>> acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
>> acl localnet src fc00::/7       # RFC 4193 local private network range
>> acl localnet src fe80::/10      # RFC 4291 link-local (directly plugged) machines
>>
>> acl Safe_ports port 80 # http
>> acl Safe_ports port 21 # ftp
>> acl Safe_ports port 443 # https
>> acl Safe_ports port 70 # gopher
>> acl Safe_ports port 210 # wais
>> acl Safe_ports port 1025-65535 # unregistered ports
>> acl Safe_ports port 280 # http-mgmt
>> acl Safe_ports port 488 # gss-http
>> acl Safe_ports port 591 # filemaker
>> acl Safe_ports port 777 # multiling http
>>
>> acl SSL_ports port 443
>> acl CONNECT method CONNECT
>>
>> http_access deny !Safe_ports
>> http_access deny CONNECT !SSL_ports
>>
>> http_access allow localhost manager
>> http_access deny manager
>>
>> refresh_pattern ^ftp: 1440 20% 10080
>> refresh_pattern ^gopher: 1440 0% 1440
>> refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
>> refresh_pattern . 0 20% 4320
>>
>> ssl_bump peek all
>> ssl_bump splice all
>>
>> always_direct allow all
>>
>> http_access allow localnet
>> http_access allow localhost
>>
>> http_access deny all
>
>
> Any suggestions gratefully received.
>
> Thanks
>
> Mark

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

Re: ssl_bump - peek & splice logging IP rather than server name

Eliezer Croitoru
In reply to this post by Mark Hoare
Hey Mark,

Squid in intercept or tproxy mode will know one thing about the tunnel\connection: IP+port.
Since you are using:
> ssl_bump peek all
> ssl_bump splice all

The connections will always be spliced and you will never see any url.(are you expecting only the SNI or also the url?)
I do not know but there might be a code that can report the SNI if exists in the logs.
Alex is better then me in this but I believe it should be possible as an addition to the IP+PORT and not replacing them.

Eliezer

----
Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: [hidden email]


-----Original Message-----
From: squid-users [mailto:[hidden email]] On Behalf Of Mark Hoare
Sent: Saturday, December 31, 2016 4:38 PM
To: [hidden email]
Subject: [squid-users] ssl_bump - peek & splice logging IP rather than server name

Hi,

I’m trying to setup policy based routing on a gateway device pointing at a remote squid server to do transparent HTTP & HTTPS proxying with ssl_bump (peek & splice)

After quite a bit of pain getting policy based routing working on the gateway and local port redirection on the squid server, everything appears to be working except the access log still refers to the destination IP address in the TCP_TUNNEL rather than the SNI/TLS server name.

By increasing the debug level I can see that the SNI/TLS details are definitely being obtained during the request processing but for some reason they are not ending up in the access log.

Extract from cache log:
> 2016/12/31 14:18:01.966 kid1| 83,7| bio.cc(1110) parseV3Hello: Found server name: www.ssllabs.com
> 2016/12/31 14:18:02.351 kid1| 83,5| support.cc(259) ssl_verify_cb: SSL Certificate signature OK: /C=US/ST=California/L=Redwood City/O=Qualys, Inc./CN=ssllabs.com
> 2016/12/31 14:18:02.351 kid1| 83,4| support.cc(213) check_domain: Verifying server domain www.ssllabs.com to certificate name/subjectAltName ssllabs.com
> 2016/12/31 14:18:02.351 kid1| 83,4| support.cc(213) check_domain: Verifying server domain www.ssllabs.com to certificate name/subjectAltName *.ssllabs.com
> 2016/12/31 14:18:02.383 kid1| 83,5| PeerConnector.cc(307) serverCertificateVerified: HTTPS server CN: ssllabs.com bumped: local=<squid IP removed>:57790 remote=64.41.200.100:443 FD 14 flags=1

Extract from access log:
> 1483193882.790    870 <local ip removed> TCP_TUNNEL/200 5620 CONNECT 64.41.200.100:443 - ORIGINAL_DST/64.41.200.100 -

From the output above I would have expected some of the server name info to get into the access log.

Squid config below:

> debug_options ALL,7
>
> http_port 3128
>
> https_port 3130 intercept ssl-bump cert=/etc/squid/ssl_cert/squidCA.pem generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
>
> http_port 3131 intercept ssl-bump cert=/etc/squid/ssl_cert/squidCA.pem generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
>
> cache_dir ufs /var/spool/squid 200 16 256
> coredump_dir /var/spool/squid
>
> acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
> acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
> acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
> acl localnet src fc00::/7       # RFC 4193 local private network range
> acl localnet src fe80::/10      # RFC 4291 link-local (directly plugged) machines
>
> acl Safe_ports port 80 # http
> acl Safe_ports port 21 # ftp
> acl Safe_ports port 443 # https
> acl Safe_ports port 70 # gopher
> acl Safe_ports port 210 # wais
> acl Safe_ports port 1025-65535 # unregistered ports
> acl Safe_ports port 280 # http-mgmt
> acl Safe_ports port 488 # gss-http
> acl Safe_ports port 591 # filemaker
> acl Safe_ports port 777 # multiling http
>
> acl SSL_ports port 443
> acl CONNECT method CONNECT
>
> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports
>
> http_access allow localhost manager
> http_access deny manager
>
> refresh_pattern ^ftp: 1440 20% 10080
> refresh_pattern ^gopher: 1440 0% 1440
> refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
> refresh_pattern . 0 20% 4320
>
> ssl_bump peek all
> ssl_bump splice all
>
> always_direct allow all
>
> http_access allow localnet
> http_access allow localhost
>
> http_access deny all


Any suggestions gratefully received.

Thanks

Mark
_______________________________________________
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
|  
Report Content as Inappropriate

Re: ssl_bump - peek & splice logging IP rather than server name

Alex Rousskov
On 01/03/2017 03:41 PM, Eliezer  Croitoru wrote:

> Squid in intercept or tproxy mode will know one thing about the tunnel\connection: IP+port.

... and SSL handshake information when peeking or staring at client/server.


> Since you are using:
>> ssl_bump peek all
>> ssl_bump splice all

> The connections will always be spliced and you will never see any
> url.(are you expecting only the SNI or also the url?)

AFAICT, Mark is expecting Squid to log one of the server names, not the
HTTP request URL.


> I do not know but there might be a code that can report the SNI if exists in the logs.

According to squid.conf.documented, the following logformat %code is
supported in modern Squids:

> ssl::>sni       SSL client SNI sent to Squid. Available only
>                 after the peek, stare, or splice SSL bumping
>                 actions.

This %code is not in the default access.log line format, naturally.

Squid can also analyze CN and other server certificate fields, but there
is no code to log them IIRC.


Please note that the intercepted server IP address, the client-supplied
SNI name, the server-supplied common name (CN), the server-supplied
alternative names, and the host info in the encrypted client HTTP
request, may all be different.

Given the variety of information sources that might supply different
information, it is not clear to me whether %ru should be based on SNI
information when both TCP-level and SNI information is available. Or
should it be based on CN? Or perhaps on CN _unless_ SNI matches one of
the alternative names?? This is a complicated issue; even the smart
server_name ACL needs parameters to clarify what "server name(s)" the
admin really wants to use/trust...

According to Mark's email, %ru uses TCP-level info. We could either
change %ru to use the "latest" info (like the server_name ACL does) or
add a new logformat code that does that while leaving the old %ru and
friends alone. Given the complexity of the issue, the latter may be a
better approach.


HTH,

Alex.

> -----Original Message-----
> From: squid-users [mailto:[hidden email]] On Behalf Of Mark Hoare
> Sent: Saturday, December 31, 2016 4:38 PM
> To: [hidden email]
> Subject: [squid-users] ssl_bump - peek & splice logging IP rather than server name

> Extract from access log:
>> 1483193882.790    870 <local ip removed> TCP_TUNNEL/200 5620 CONNECT 64.41.200.100:443 - ORIGINAL_DST/64.41.200.100 -

> From the output above I would have expected some of the server name info to get into the access log.

>> http_port 3128
>>
>> https_port 3130 intercept ssl-bump cert=/etc/squid/ssl_cert/squidCA.pem generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
>>
>> http_port 3131 intercept ssl-bump cert=/etc/squid/ssl_cert/squidCA.pem generate-host-certificates=on dynamic_cert_mem_cache_size=4MB

>> ssl_bump peek all
>> ssl_bump splice all

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

Re: ssl_bump - peek & splice logging IP rather than server name

Mark Hoare
In reply to this post by Eliezer Croitoru
Thanks Eliezer,

I'm aiming for a configuration which logs all HTTP and HTTPS connections without performing any full ssl_bumping, which would need me to get devices to trust my CA cert.

I have something similar with pfsense (which does log SNI/server name rather than IP & port) but I'm getting some strange behaviour so wanted to build an equivalent standalone squid server, with a more up to date version of squid.

Will have another look at my pfsense ssl_bump config as there are some slight differences, but I think these are hangovers from earlier syntax (ssl_bump server-first all) which shouldn't be required under 3.5.

Cheers

Mark

> On 3 Jan 2017, at 22:41, Eliezer Croitoru <[hidden email]> wrote:
>
> Hey Mark,
>
> Squid in intercept or tproxy mode will know one thing about the tunnel\connection: IP+port.
> Since you are using:
>> ssl_bump peek all
>> ssl_bump splice all
>
> The connections will always be spliced and you will never see any url.(are you expecting only the SNI or also the url?)
> I do not know but there might be a code that can report the SNI if exists in the logs.
> Alex is better then me in this but I believe it should be possible as an addition to the IP+PORT and not replacing them.
>
> Eliezer
>
> ----
> Eliezer Croitoru
> Linux System Administrator
> Mobile: +972-5-28704261
> Email: [hidden email]
>
>
> -----Original Message-----
> From: squid-users [mailto:[hidden email]] On Behalf Of Mark Hoare
> Sent: Saturday, December 31, 2016 4:38 PM
> To: [hidden email]
> Subject: [squid-users] ssl_bump - peek & splice logging IP rather than server name
>
> Hi,
>
> I’m trying to setup policy based routing on a gateway device pointing at a remote squid server to do transparent HTTP & HTTPS proxying with ssl_bump (peek & splice)
>
> After quite a bit of pain getting policy based routing working on the gateway and local port redirection on the squid server, everything appears to be working except the access log still refers to the destination IP address in the TCP_TUNNEL rather than the SNI/TLS server name.
>
> By increasing the debug level I can see that the SNI/TLS details are definitely being obtained during the request processing but for some reason they are not ending up in the access log.
>
> Extract from cache log:
>> 2016/12/31 14:18:01.966 kid1| 83,7| bio.cc(1110) parseV3Hello: Found server name: www.ssllabs.com
>> 2016/12/31 14:18:02.351 kid1| 83,5| support.cc(259) ssl_verify_cb: SSL Certificate signature OK: /C=US/ST=California/L=Redwood City/O=Qualys, Inc./CN=ssllabs.com
>> 2016/12/31 14:18:02.351 kid1| 83,4| support.cc(213) check_domain: Verifying server domain www.ssllabs.com to certificate name/subjectAltName ssllabs.com
>> 2016/12/31 14:18:02.351 kid1| 83,4| support.cc(213) check_domain: Verifying server domain www.ssllabs.com to certificate name/subjectAltName *.ssllabs.com
>> 2016/12/31 14:18:02.383 kid1| 83,5| PeerConnector.cc(307) serverCertificateVerified: HTTPS server CN: ssllabs.com bumped: local=<squid IP removed>:57790 remote=64.41.200.100:443 FD 14 flags=1
>
> Extract from access log:
>> 1483193882.790    870 <local ip removed> TCP_TUNNEL/200 5620 CONNECT 64.41.200.100:443 - ORIGINAL_DST/64.41.200.100 -
>
> From the output above I would have expected some of the server name info to get into the access log.
>
> Squid config below:
>> debug_options ALL,7
>>
>> http_port 3128
>>
>> https_port 3130 intercept ssl-bump cert=/etc/squid/ssl_cert/squidCA.pem generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
>>
>> http_port 3131 intercept ssl-bump cert=/etc/squid/ssl_cert/squidCA.pem generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
>>
>> cache_dir ufs /var/spool/squid 200 16 256
>> coredump_dir /var/spool/squid
>>
>> acl localnet src 10.0.0.0/8    # RFC1918 possible internal network
>> acl localnet src 172.16.0.0/12    # RFC1918 possible internal network
>> acl localnet src 192.168.0.0/16    # RFC1918 possible internal network
>> acl localnet src fc00::/7       # RFC 4193 local private network range
>> acl localnet src fe80::/10      # RFC 4291 link-local (directly plugged) machines
>>
>> acl Safe_ports port 80        # http
>> acl Safe_ports port 21        # ftp
>> acl Safe_ports port 443        # https
>> acl Safe_ports port 70        # gopher
>> acl Safe_ports port 210        # wais
>> acl Safe_ports port 1025-65535    # unregistered ports
>> acl Safe_ports port 280        # http-mgmt
>> acl Safe_ports port 488        # gss-http
>> acl Safe_ports port 591        # filemaker
>> acl Safe_ports port 777        # multiling http
>>
>> acl SSL_ports port 443
>> acl CONNECT method CONNECT
>>
>> http_access deny !Safe_ports
>> http_access deny CONNECT !SSL_ports
>>
>> http_access allow localhost manager
>> http_access deny manager
>>
>> refresh_pattern ^ftp:        1440    20%    10080
>> refresh_pattern ^gopher:    1440    0%    1440
>> refresh_pattern -i (/cgi-bin/|\?) 0    0%    0
>> refresh_pattern .        0    20%    4320
>>
>> ssl_bump peek all
>> ssl_bump splice all
>>
>> always_direct allow all
>>
>> http_access allow localnet
>> http_access allow localhost
>>
>> http_access deny all
>
>
> Any suggestions gratefully received.
>
> Thanks
>
> Mark
> _______________________________________________
> 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
|  
Report Content as Inappropriate

Re: ssl_bump - peek & splice logging IP rather than server name

Alex Rousskov
On 01/03/2017 04:11 PM, Mark Hoare wrote:

> I think these are hangovers from earlier syntax (ssl_bump
> server-first all) which shouldn't be required under 3.5.

Please note that the depricated server-first is a "bumping" (not
splicing!) action, and you may see a lot more information in the
bumping-Squid logs, naturally.

Alex.

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

Re: ssl_bump - peek & splice logging IP rather than server name

Mark Hoare
In reply to this post by Alex Rousskov
Alex/Eliezer,

Thanks for you earlier comments and apologies for not responding (and saying thank you previously, squid got back-burnered unfortunately)

Getting logging working with transparent proxying was my initial step prior to looking at restricting specific sites via either ACLs or a URL rewriter (ufdbGuard, SquidGuard etc - although I don’t think SquidGuard works with SNI) 

To reiterate, my desire is to have Squid running and capable of blocking access to http and https sites primarily based on the server name requested by the client (so no need to go beyond a peek)
For HTTP requests this is obviously out of the box stuff but for HTTPS it seems more complicated.

From everything I’ve read, it looks like the following ssl_bump lines should provide access to the SNI server name requested by the client. 
ssl_bump peek all
ssl_bump splice all

I can’t help thinking that I must have something wrong with my config:
- Log output correctly shows 
- SNI server name via ssl::>sni 
- Bump mode via ssl::bump_mode 
- Implies my ssl_bump config is working
- Restricting access via a squid ACL doesn’t use the SNI server name for an HTTPS request 
- Works fine for HTTP

Example ACL:
    acl blocked_sites ssl::server_name .apple.com
    http_access deny blocked_sites

Example access log output:
%ts.%03tu   %6tr  %>a        %Ss/%03>Hs    %<st  %rm      %ru                         %ssl::>sni        %ssl::bump_mode %[un  %Sh/%<a                     %mt
1485468402.401  575   10.1.0.1  TCP_TUNNEL/200 592  CONNECT  23.63.86.92:443          store.apple.com  peek           -    ORIGINAL_DST/23.63.86.92  -
1485469054.633  51    10.1.0.1  TCP_DENIED/403 3962 GET      http://store.apple.com/  -                -              -    HIER_NONE/-               text/html

Example cache log output:
2017/01/26 21:54:21.745 kid1| 28,5| Acl.cc(138) matches: checking blocked_sites
2017/01/26 21:54:21.745 kid1| 28,3| ServerName.cc(42) match: checking '23.63.86.92'
2017/01/26 21:54:21.745 kid1| 28,7| ServerName.cc(32) aclHostDomainCompare: Match:23.63.86.92 <>  .apple.com
2017/01/26 21:54:21.745 kid1| 28,3| ServerName.cc(47) match: '23.63.86.92' NOT found
2017/01/26 21:54:21.745 kid1| 28,3| ServerName.cc(42) match: checking 'none'
2017/01/26 21:54:21.745 kid1| 28,7| ServerName.cc(32) aclHostDomainCompare: Match:none <>  .apple.com
2017/01/26 21:54:21.745 kid1| 28,3| ServerName.cc(47) match: 'none' NOT found
2017/01/26 21:54:21.745 kid1| 28,3| Acl.cc(158) matches: checked: blocked_sites = 0
2017/01/26 21:54:21.745 kid1| 28,3| Acl.cc(158) matches: checked: http_access#5 = 0
2017/01/26 21:54:21.745 kid1| 28,5| Checklist.cc(400) bannedAction: Action 'ALLOWED/0is not banned

squid -v output:
Squid Cache: Version 3.5.20
Service Name: squid
configure options:  '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--disable-strict-error-checking' '--exec_prefix=/usr' '--libexecdir=/usr/lib64/squid' '--localstatedir=/var' '--datadir=/usr/share/squid' '--sysconfdir=/etc/squid' '--with-logdir=$(localstatedir)/log/squid' '--with-pidfile=$(localstatedir)/run/squid.pid' '--disable-dependency-tracking' '--enable-eui' '--enable-follow-x-forwarded-for' '--enable-auth' '--enable-auth-basic=DB,LDAP,MSNT-multi-domain,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB,SMB_LM,getpwnam' '--enable-auth-ntlm=smb_lm,fake' '--enable-auth-digest=file,LDAP,eDirectory' '--enable-auth-negotiate=kerberos' '--enable-external-acl-helpers=file_userip,LDAP_group,time_quota,session,unix_group,wbinfo_group' '--enable-cache-digests' '--enable-cachemgr-hostname=localhost' '--enable-delay-pools' '--enable-epoll' '--enable-ident-lookups' '--enable-linux-netfilter' '--enable-removal-policies=heap,lru' '--enable-snmp' '--enable-ssl-crtd' '--enable-storeio=aufs,diskd,ufs' '--enable-wccpv2' '--enable-esi' '--enable-ecap' '--with-aio' '--with-default-user=squid' '--with-dl' '--with-openssl' '--with-pthreads' '--disable-arch-native' '--disable-icap-client' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -fpie' 'LDFLAGS=-Wl,-z,relro  -pie -Wl,-z,relro -Wl,-z,now' 'CXXFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -fpie' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'

Is there anything obvious that I am missing as I’m a bit stumped now.

Thanks again

Mark

On 3 Jan 2017, at 23:35, Alex Rousskov <[hidden email]> wrote:

On 01/03/2017 04:11 PM, Mark Hoare wrote:

I think these are hangovers from earlier syntax (ssl_bump
server-first all) which shouldn't be required under 3.5.

Please note that the depricated server-first is a "bumping" (not
splicing!) action, and you may see a lot more information in the
bumping-Squid logs, naturally.

Alex.


On 3 Jan 2017, at 23:10, Alex Rousskov <[hidden email]> wrote:

On 01/03/2017 03:41 PM, Eliezer  Croitoru wrote:

Squid in intercept or tproxy mode will know one thing about the tunnel\connection: IP+port.

... and SSL handshake information when peeking or staring at client/server.


Since you are using:
ssl_bump peek all
ssl_bump splice all

The connections will always be spliced and you will never see any
url.(are you expecting only the SNI or also the url?)

AFAICT, Mark is expecting Squid to log one of the server names, not the
HTTP request URL.


I do not know but there might be a code that can report the SNI if exists in the logs.

According to squid.conf.documented, the following logformat %code is
supported in modern Squids:

ssl::>sni       SSL client SNI sent to Squid. Available only
               after the peek, stare, or splice SSL bumping
               actions.

This %code is not in the default access.log line format, naturally.

Squid can also analyze CN and other server certificate fields, but there
is no code to log them IIRC.


Please note that the intercepted server IP address, the client-supplied
SNI name, the server-supplied common name (CN), the server-supplied
alternative names, and the host info in the encrypted client HTTP
request, may all be different.

Given the variety of information sources that might supply different
information, it is not clear to me whether %ru should be based on SNI
information when both TCP-level and SNI information is available. Or
should it be based on CN? Or perhaps on CN _unless_ SNI matches one of
the alternative names?? This is a complicated issue; even the smart
server_name ACL needs parameters to clarify what "server name(s)" the
admin really wants to use/trust...

According to Mark's email, %ru uses TCP-level info. We could either
change %ru to use the "latest" info (like the server_name ACL does) or
add a new logformat code that does that while leaving the old %ru and
friends alone. Given the complexity of the issue, the latter may be a
better approach.


HTH,

Alex.

-----Original Message-----
From: squid-users [[hidden email]] On Behalf Of Mark Hoare
Sent: Saturday, December 31, 2016 4:38 PM
To: [hidden email]
Subject: [squid-users] ssl_bump - peek & splice logging IP rather than server name

Extract from access log:
1483193882.790    870 <local ip removed> TCP_TUNNEL/200 5620 CONNECT 64.41.200.100:443 - ORIGINAL_DST/64.41.200.100 -

From the output above I would have expected some of the server name info to get into the access log.

http_port 3128

https_port 3130 intercept ssl-bump cert=/etc/squid/ssl_cert/squidCA.pem generate-host-certificates=on dynamic_cert_mem_cache_size=4MB

http_port 3131 intercept ssl-bump cert=/etc/squid/ssl_cert/squidCA.pem generate-host-certificates=on dynamic_cert_mem_cache_size=4MB

ssl_bump peek all
ssl_bump splice all



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

Re: ssl_bump - peek & splice logging IP rather than server name

Alex Rousskov
On 01/26/2017 03:38 PM, Mark Hoare wrote:

> To reiterate, my desire is to have Squid running and capable of blocking
> access to http and https sites primarily based on the server name
> requested by the client (so no need to go beyond a peek)

... or even beyond a peek at the client.


> From everything I’ve read, it looks like the following ssl_bump lines
> should provide access to the SNI server name requested by the client.
> ssl_bump peek all
> ssl_bump splice all

Yes, but you are also telling Squid to peek at the server certificate.
If you want to avoid doing that, then replace "peek all" with "peek
step1" while providing the right step1 ACL. The SNI-based denial you
want should happen earlier anyway, but if you do peek at the server
certificate, then you may also deny later, based on server-supplied
information (e.g., when SNI was missing or was not matching). Whether
more denials based on server info is a good thing is your decision.


> I can’t help thinking that I must have something wrong with my config:
> - Log output correctly shows
> - SNI server name via ssl::>sni
> - Bump mode via ssl::bump_mode
> - Implies my ssl_bump config is working
> - Works fine for HTTP

Great!


> - Restricting access via a squid ACL doesn’t use the SNI server name for
> an HTTPS request

You may be right, but not for the reasons you think. The output you have
shown does not necessarily confirm any problems.


> Example ACL:
>     acl blocked_sites ssl::server_name .apple.com
>     http_access deny blocked_sites

Please note that your Squid version is missing a critical
ssl::server_name fix detailed below.


> Example access log output:
> %ts.%03tu   %6tr  %>a        %Ss/%03>Hs    %<st  %rm      %ru
>     %ssl::>sni       %ssl::bump_mode %[un  %Sh/%<a %mt

> 1485468402.401  575   10.1.0.1  TCP_TUNNEL/200 592  CONNECT 23.63.86.92:443
>     store.apple.com  peek -   ORIGINAL_DST/23.63.86.92  -

> 1485469054.633  51    10.1.0.1  TCP_DENIED/403 3962 GET http://store.apple.com/
>     -                -    -   HIER_NONE/-               text/html

The above shows that Squid peeked and denied access. To serve the error
page to the client, Squid bumped the client connection first and then
denied the first encrypted HTTP request. This is normal/expected.


> Example cache log output:
> 2017/01/26 21:54:21.745 kid1| 28,5| Acl.cc(138) matches: checking blocked_sites
> 2017/01/26 21:54:21.745 kid1| 28,3| ServerName.cc(42) match: checking '23.63.86.92'
> 2017/01/26 21:54:21.745 kid1| 28,7| ServerName.cc(32) aclHostDomainCompare: Match:23.63.86.92 <> .apple.com
> 2017/01/26 21:54:21.745 kid1| 28,3| ServerName.cc(47) match: '23.63.86.92' NOT found
> 2017/01/26 21:54:21.745 kid1| 28,3| ServerName.cc(42) match: checking 'none'
> 2017/01/26 21:54:21.745 kid1| 28,7| ServerName.cc(32) aclHostDomainCompare: Match:none <> .apple.com
> 2017/01/26 21:54:21.745 kid1| 28,3| ServerName.cc(47) match: 'none' NOT found
> 2017/01/26 21:54:21.745 kid1| 28,5| Checklist.cc(400) bannedAction: Action 'ALLOWED/0is not banned

If the above was for step1 checks, then it makes sense: The access was
not banned based on TCP level information. Proceed to step2 (extract SNI
and test again). There should be more checks like the above, and then
Squid decided to deny access. However, the timing of that decision and
the sources of information used for that decision may change after the
ssl::server_name fix mentioned below.


> Squid Cache: Version 3.5.20

You are missing the following server_name fix (among other things):

> revno: 14110
> branch nick: 3.5
> timestamp: Mon 2016-11-14 23:51:24 +1300
> message:
>   Fix ssl::server_name ACL badly broken since inception.
>  
>   The original server_name code mishandled all SNI checks and some rare
>   host checks:
>  
>   * The SNI-derived value was pointing to an already freed memory storage.
>   * Missing host-derived values were not detected (host() is never nil).
>   * Mismatches were re-checked with an undocumented "none" value
>     instead of being treated as mismatches.
>  
>   Same for ssl::server_name_regex.
>  
>   Also set SNI for more server-first and client-first transactions.
>  
>   This is a Measurement Factory project.

The first rule of SslBumping: Use the latest code.


HTH,

Alex.
P.S. Please avoid HTMLifying your emails, especially when quoting logs.



>> On 3 Jan 2017, at 23:35, Alex Rousskov wrote:
>>
>> On 01/03/2017 04:11 PM, Mark Hoare wrote:
>>
>>> I think these are hangovers from earlier syntax (ssl_bump
>>> server-first all) which shouldn't be required under 3.5.
>>
>> Please note that the depricated server-first is a "bumping" (not
>> splicing!) action, and you may see a lot more information in the
>> bumping-Squid logs, naturally.
>>
>> Alex.
>>
>
>> On 3 Jan 2017, at 23:10, Alex Rousskov
>> <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>> On 01/03/2017 03:41 PM, Eliezer  Croitoru wrote:
>>
>>> Squid in intercept or tproxy mode will know one thing about the
>>> tunnel\connection: IP+port.
>>
>> ... and SSL handshake information when peeking or staring at
>> client/server.
>>
>>
>>> Since you are using:
>>>> ssl_bump peek all
>>>> ssl_bump splice all
>>
>>> The connections will always be spliced and you will never see any
>>> url.(are you expecting only the SNI or also the url?)
>>
>> AFAICT, Mark is expecting Squid to log one of the server names, not the
>> HTTP request URL.
>>
>>
>>> I do not know but there might be a code that can report the SNI if
>>> exists in the logs.
>>
>> According to squid.conf.documented, the following logformat %code is
>> supported in modern Squids:
>>
>>> ssl::>sni       SSL client SNI sent to Squid. Available only
>>>                after the peek, stare, or splice SSL bumping
>>>                actions.
>>
>> This %code is not in the default access.log line format, naturally.
>>
>> Squid can also analyze CN and other server certificate fields, but there
>> is no code to log them IIRC.
>>
>>
>> Please note that the intercepted server IP address, the client-supplied
>> SNI name, the server-supplied common name (CN), the server-supplied
>> alternative names, and the host info in the encrypted client HTTP
>> request, may all be different.
>>
>> Given the variety of information sources that might supply different
>> information, it is not clear to me whether %ru should be based on SNI
>> information when both TCP-level and SNI information is available. Or
>> should it be based on CN? Or perhaps on CN _unless_ SNI matches one of
>> the alternative names?? This is a complicated issue; even the smart
>> server_name ACL needs parameters to clarify what "server name(s)" the
>> admin really wants to use/trust...
>>
>> According to Mark's email, %ru uses TCP-level info. We could either
>> change %ru to use the "latest" info (like the server_name ACL does) or
>> add a new logformat code that does that while leaving the old %ru and
>> friends alone. Given the complexity of the issue, the latter may be a
>> better approach.
>>
>>
>> HTH,
>>
>> Alex.
>>
>>> -----Original Message-----
>>> From: squid-users [mailto:[hidden email]]
>>> On Behalf Of Mark Hoare
>>> Sent: Saturday, December 31, 2016 4:38 PM
>>> To: [hidden email]
>>> <mailto:[hidden email]>
>>> Subject: [squid-users] ssl_bump - peek & splice logging IP rather
>>> than server name
>>
>>> Extract from access log:
>>>> 1483193882.790    870 <local ip removed> TCP_TUNNEL/200 5620 CONNECT
>>>> 64.41.200.100:443 - ORIGINAL_DST/64.41.200.100 -
>>
>>> From the output above I would have expected some of the server name
>>> info to get into the access log.
>>
>>>> http_port 3128
>>>>
>>>> https_port 3130 intercept ssl-bump
>>>> cert=/etc/squid/ssl_cert/squidCA.pem generate-host-certificates=on
>>>> dynamic_cert_mem_cache_size=4MB
>>>>
>>>> http_port 3131 intercept ssl-bump
>>>> cert=/etc/squid/ssl_cert/squidCA.pem generate-host-certificates=on
>>>> dynamic_cert_mem_cache_size=4MB
>>
>>>> ssl_bump peek all
>>>> ssl_bump splice all
>>
>

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

Re: ssl_bump - peek & splice logging IP rather than server name

Eliezer Croitoru
Is it stock REDHAT or CentOS or Other?
You can use the RPM's of squid I am building which are quite generic and works very well.
I have just released 3.5.23 and 4.0.17.
I have built it both for RH and CentOS:
http://wiki.squid-cache.org/KnowledgeBase/CentOS#Squid-3.5
And you can take a peek and browse at:
http://www1.ngtech.co.il/repo/
If what you are running is not there let me know and I will try to build a binary for it.

Eliezer

----
Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: [hidden email]


-----Original Message-----
From: squid-users [mailto:[hidden email]] On Behalf Of Alex Rousskov
Sent: Friday, January 27, 2017 1:57 AM
To: [hidden email]
Subject: Re: [squid-users] ssl_bump - peek & splice logging IP rather than server name

On 01/26/2017 03:38 PM, Mark Hoare wrote:

> To reiterate, my desire is to have Squid running and capable of
> blocking access to http and https sites primarily based on the server
> name requested by the client (so no need to go beyond a peek)

... or even beyond a peek at the client.


> From everything I’ve read, it looks like the following ssl_bump lines
> should provide access to the SNI server name requested by the client.
> ssl_bump peek all
> ssl_bump splice all

Yes, but you are also telling Squid to peek at the server certificate.
If you want to avoid doing that, then replace "peek all" with "peek step1" while providing the right step1 ACL. The SNI-based denial you want should happen earlier anyway, but if you do peek at the server certificate, then you may also deny later, based on server-supplied information (e.g., when SNI was missing or was not matching). Whether more denials based on server info is a good thing is your decision.


> I can’t help thinking that I must have something wrong with my config:
> - Log output correctly shows
> - SNI server name via ssl::>sni
> - Bump mode via ssl::bump_mode
> - Implies my ssl_bump config is working
> - Works fine for HTTP

Great!


> - Restricting access via a squid ACL doesn’t use the SNI server name
> for an HTTPS request

You may be right, but not for the reasons you think. The output you have shown does not necessarily confirm any problems.


> Example ACL:
>     acl blocked_sites ssl::server_name .apple.com
>     http_access deny blocked_sites

Please note that your Squid version is missing a critical ssl::server_name fix detailed below.


> Example access log output:
> %ts.%03tu   %6tr  %>a        %Ss/%03>Hs    %<st  %rm      %ru
>     %ssl::>sni       %ssl::bump_mode %[un  %Sh/%<a %mt

> 1485468402.401  575   10.1.0.1  TCP_TUNNEL/200 592  CONNECT 23.63.86.92:443
>     store.apple.com  peek -   ORIGINAL_DST/23.63.86.92  -

> 1485469054.633  51    10.1.0.1  TCP_DENIED/403 3962 GET http://store.apple.com/
>     -                -    -   HIER_NONE/-               text/html

The above shows that Squid peeked and denied access. To serve the error page to the client, Squid bumped the client connection first and then denied the first encrypted HTTP request. This is normal/expected.


> Example cache log output:
> 2017/01/26 21:54:21.745 kid1| 28,5| Acl.cc(138) matches: checking
> blocked_sites
> 2017/01/26 21:54:21.745 kid1| 28,3| ServerName.cc(42) match: checking '23.63.86.92'
> 2017/01/26 21:54:21.745 kid1| 28,7| ServerName.cc(32)
> aclHostDomainCompare: Match:23.63.86.92 <> .apple.com
> 2017/01/26 21:54:21.745 kid1| 28,3| ServerName.cc(47) match:
> '23.63.86.92' NOT found
> 2017/01/26 21:54:21.745 kid1| 28,3| ServerName.cc(42) match: checking 'none'
> 2017/01/26 21:54:21.745 kid1| 28,7| ServerName.cc(32)
> aclHostDomainCompare: Match:none <> .apple.com
> 2017/01/26 21:54:21.745 kid1| 28,3| ServerName.cc(47) match: 'none'
> NOT found
> 2017/01/26 21:54:21.745 kid1| 28,5| Checklist.cc(400) bannedAction:
> Action 'ALLOWED/0is not banned

If the above was for step1 checks, then it makes sense: The access was not banned based on TCP level information. Proceed to step2 (extract SNI and test again). There should be more checks like the above, and then Squid decided to deny access. However, the timing of that decision and the sources of information used for that decision may change after the ssl::server_name fix mentioned below.


> Squid Cache: Version 3.5.20

You are missing the following server_name fix (among other things):

> revno: 14110
> branch nick: 3.5
> timestamp: Mon 2016-11-14 23:51:24 +1300
> message:
>   Fix ssl::server_name ACL badly broken since inception.
>  
>   The original server_name code mishandled all SNI checks and some rare
>   host checks:
>  
>   * The SNI-derived value was pointing to an already freed memory storage.
>   * Missing host-derived values were not detected (host() is never nil).
>   * Mismatches were re-checked with an undocumented "none" value
>     instead of being treated as mismatches.
>  
>   Same for ssl::server_name_regex.
>  
>   Also set SNI for more server-first and client-first transactions.
>  
>   This is a Measurement Factory project.

The first rule of SslBumping: Use the latest code.


HTH,

Alex.
P.S. Please avoid HTMLifying your emails, especially when quoting logs.



>> On 3 Jan 2017, at 23:35, Alex Rousskov wrote:
>>
>> On 01/03/2017 04:11 PM, Mark Hoare wrote:
>>
>>> I think these are hangovers from earlier syntax (ssl_bump
>>> server-first all) which shouldn't be required under 3.5.
>>
>> Please note that the depricated server-first is a "bumping" (not
>> splicing!) action, and you may see a lot more information in the
>> bumping-Squid logs, naturally.
>>
>> Alex.
>>
>
>> On 3 Jan 2017, at 23:10, Alex Rousskov
>> <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>> On 01/03/2017 03:41 PM, Eliezer  Croitoru wrote:
>>
>>> Squid in intercept or tproxy mode will know one thing about the
>>> tunnel\connection: IP+port.
>>
>> ... and SSL handshake information when peeking or staring at
>> client/server.
>>
>>
>>> Since you are using:
>>>> ssl_bump peek all
>>>> ssl_bump splice all
>>
>>> The connections will always be spliced and you will never see any
>>> url.(are you expecting only the SNI or also the url?)
>>
>> AFAICT, Mark is expecting Squid to log one of the server names, not
>> the HTTP request URL.
>>
>>
>>> I do not know but there might be a code that can report the SNI if
>>> exists in the logs.
>>
>> According to squid.conf.documented, the following logformat %code is
>> supported in modern Squids:
>>
>>> ssl::>sni       SSL client SNI sent to Squid. Available only
>>>                after the peek, stare, or splice SSL bumping
>>>                actions.
>>
>> This %code is not in the default access.log line format, naturally.
>>
>> Squid can also analyze CN and other server certificate fields, but
>> there is no code to log them IIRC.
>>
>>
>> Please note that the intercepted server IP address, the
>> client-supplied SNI name, the server-supplied common name (CN), the
>> server-supplied alternative names, and the host info in the encrypted
>> client HTTP request, may all be different.
>>
>> Given the variety of information sources that might supply different
>> information, it is not clear to me whether %ru should be based on SNI
>> information when both TCP-level and SNI information is available. Or
>> should it be based on CN? Or perhaps on CN _unless_ SNI matches one
>> of the alternative names?? This is a complicated issue; even the
>> smart server_name ACL needs parameters to clarify what "server
>> name(s)" the admin really wants to use/trust...
>>
>> According to Mark's email, %ru uses TCP-level info. We could either
>> change %ru to use the "latest" info (like the server_name ACL does)
>> or add a new logformat code that does that while leaving the old %ru
>> and friends alone. Given the complexity of the issue, the latter may
>> be a better approach.
>>
>>
>> HTH,
>>
>> Alex.
>>
>>> -----Original Message-----
>>> From: squid-users [mailto:[hidden email]]
>>> On Behalf Of Mark Hoare
>>> Sent: Saturday, December 31, 2016 4:38 PM
>>> To: [hidden email]
>>> <mailto:[hidden email]>
>>> Subject: [squid-users] ssl_bump - peek & splice logging IP rather
>>> than server name
>>
>>> Extract from access log:
>>>> 1483193882.790    870 <local ip removed> TCP_TUNNEL/200 5620 CONNECT
>>>> 64.41.200.100:443 - ORIGINAL_DST/64.41.200.100 -
>>
>>> From the output above I would have expected some of the server name
>>> info to get into the access log.
>>
>>>> http_port 3128
>>>>
>>>> https_port 3130 intercept ssl-bump
>>>> cert=/etc/squid/ssl_cert/squidCA.pem generate-host-certificates=on
>>>> dynamic_cert_mem_cache_size=4MB
>>>>
>>>> http_port 3131 intercept ssl-bump
>>>> cert=/etc/squid/ssl_cert/squidCA.pem generate-host-certificates=on
>>>> dynamic_cert_mem_cache_size=4MB
>>
>>>> ssl_bump peek all
>>>> ssl_bump splice all
>>
>

_______________________________________________
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
Loading...