]> git.ipfire.org Git - thirdparty/squid.git/commit
Fix SSL Bump bypass for intercepted traffic
authorAmos Jeffries <squid3@treenet.co.nz>
Thu, 14 Mar 2013 11:32:19 +0000 (05:32 -0600)
committerAmos Jeffries <squid3@treenet.co.nz>
Thu, 14 Mar 2013 11:32:19 +0000 (05:32 -0600)
commit7778eb1e7fd439f1a36bdcea28508ee6f3b36cbd
tree117a3a6617dfe3772239d1112cd386268a8898a3
parent3749964e79716534b3226d35e1f67072c5b11272
Fix SSL Bump bypass for intercepted traffic

The SSL-bump bypass code on intercepted HTTPS traffic generates a fake
CONNECT request from the original destination IP:port in an attempt to
trigger a TCP tunnel being opened for the un-bumped data to be
transferred over.

The current implementation breaks in two situations:

1) when IPv6 traffic is intercepted

The URL field generated does not account for the additional []
requirements involved when IPv6+port are combined.

The resulting fake requests look like:

 CONNECT ::1:443 HTTP/1.1
 Host: ::1

... which are both invalid, and will fail to parse. Breaking IPv6 HTTPS
interception bypass.

Resolve this by using Ip::Address::ToURL() function which was created
for the purpose of generating URL hostnames from raw-IP + port with
the bracketing inserted when required.

2) when a non-443 port is being intercepted

The Host: header generated is missing the port and Squid Host: header
validity will reject the outbound

 CONNECT 127.0.0.1:8443 HTTP/1.1
 Host: 127.0.0.1

... this is an invalid request. Squid is currently ignoring the Host
header. However Squid tunnel.cc does make use of peering and may relay
the fake request Host: to upstream peers where we cannot be so sure what
will happen.

Resolve this issue by re-using the generated IP:port string for both URL
and Host: fields, which preserves teh port in Host: regardless of value.
This also means there is an unnecessary :443 tagged on for most HTTPS
traffic, however the omission of port from the Host: header is only a MAY
and this should not cause any issues.
src/client_side.cc