On 26/05/2014 1:42 p.m., jeffrey j donovan wrote:
> Greetings,
>
> squid 3.3.8 intercept ssl bump connecting to Facebook is returning an ipv6 address . chrome refuses , safari ssl bump happens the "cert" can be saved.
> the page is text only, and ugly.
>
> logs are showing only IPv6 activity. How can I force ipv4 in this case ?
Your logs shows IPv6 is working fine. Nothing to do there.
>
> 18 10.1.1.130 TCP_MISS/301 337 GET https://facebook.com/ - PINNED/2a03:2880:2110:df07:face:b00c:0:1 text/html
> 1401067623.504 190 10.1.1.130 TCP_MISS/200 13708 GET https://www.facebook.com/ - PINNED/2a03:2880:f000:601:face:b00c:0:1 text/html
> 1401067644.751 109 10.1.1.130 TCP_MISS/200 13415 GET https://www.facebook.com/ - PINNED/2a03:2880:f000:601:face:b00c:0:1 text/html
> 1401067649.585 79 10.1.1.130 TCP_MISS/200 13426 GET https://www.facebook.com/ - PINNED/2a03:2880:f000:601:face:b00c:0:1 text/html
> 1401067668.503 33 10.1.1.133 TCP_MISS/200 338 GET http://ping.chartbeat.net/ping? - HIER_DIRECT/54.225.169.62 image/gif
> 1401067699.486 96 10.1.1.130 TCP_MISS/301 337 GET https://facebook.com/ - PINNED/2a03:2880:2110:df07:face:b00c:0:1 text/html
>
* The log trace does not show any CSS or JS content is even attempted
being fetched by the client. This matches the visible display problem
you describe.
* If the failures were from Squid you would see 400/500 status error
codes. Probably with hierarchy information saying "NONE/-".
* there are at least 4 protocols involved here. IPv6 is only one, and
appears to be fine.
* the sites you are mentioning are all known to be pushing for SPDY
and/or QUIC protocol to be adopted over TLS (port 443).
* the browsers you are having worst problems with are ones known to be
implementing the HSTS protocol extensions to TLS/SSL. The so called
"certificate pinning" or "ertificate whitelisting". Where the browser
locates the CA certificate via methods such that a forged cert (ie
ssl-bump) cannot be used.
* Squid 3.3 ssl-bumping uses the "client-first" method which is a very
nasty way to do it and does not work if the website has a small amount
of SSL security extensions actually being used.
* If IPv6 has anything at all to do with this it would take the form of
the client attempting IPv6 port 80 /443 connections and not being
intercepted at all.
I think it is very likey that the client browser is attempting to use
SPDY protocol over port 443 to fetch the supporting page pieces and
using HSTS to break the connectivity to Squid. Half connections like
that are not yet logged.
The last point about client using IPv6 and not being intercepted is
second most likely.
> i just checked twitter, and it doesn't even connect. all ipv6.
> 068202.932 4 10.1.1.130 TCP_MEM_HIT/200 107371 GEThttps://www.google.com/xjs/_/js/k=xjs.s.en_US.u4s5c7_Kv3Q.O/m=sy69,abd,sy64,sy90,sy110,sy63,sy50,sy85,sy87,sy91,sy111,sy65,sy51,sy53,sy55,sy115,sy112,sy77,sy140,sy66,sy125,sy52,sy56,sy83,sy116,sy114,sy113,sy141,sy142,sy119,sy122,sy54,sy88,sy117,sy139,sy143,sy144,sy145,sy146,actn,sy147,adp,aspn,sy46,sy45,async,sy21,cdos,crd,erh,foot,sy81,gf,sy133,hv,idck,sy82,sy101,imap,sy23,jsaleg,lc,sy70,sy71,sy243,lu,sy246,m,me,sf,tbui,sy47,sy61,sy48,em4,em5,em6,sy49,tnv,vm,sy102,vs,sy176,wta,sy67,sy68,sy193,sy192,sy214,ilrp,iur,sy93,sy134,kpfc,sy204,sy237,kptm,rmr/am=Gfw_FQY9ogCEwAo/rt=j/d=0/sv=1/t=zcms/rs=AItRSTPVXuEeQnAb7f5bz9d2nWCC_p2Fcw - HIER_NONE/- text/javascript
> 1401068203.011 23 10.135.1.130 TCP_MISS/204 340 GET https://www.google.com/client_204? - PINNED/2607:f8b0:4004:808::1012 text/html
> 1401068203.019 21 10.135.1.130 TCP_MISS/204 340 GET https://www.google.com/gen_204? - PINNED/2607:f8b0:4004:808::1012 text/html
> 1401068244.254 23 10.135.1.130 TCP_MISS/200 724 GET https://www.google.com/url? - PINNED/2607:f8b0:4004:808::1012 text/html
>
There is no information about twitter in that log. It might as well say
"jims-amateur-porn.com" for all the relevance the trace has to Twitter.
FYI: Twitter is another big player pushing SPDY aggressively. So it also
fits in with *all* of the above points.
I suggest you:
1) upgrade your Squid to the latest release. Today that is 3.4.5
2) change your configuration to server-first bumping (will require cert
DB erase and rebuild).
3) check the IPv6 NAT intercept you have setup. It may need configuring
separately to the IPv4 intercept (depending on your kernel).
Amos
Received on Mon May 26 2014 - 06:34:38 MDT
This archive was generated by hypermail 2.2.0 : Tue May 27 2014 - 12:00:13 MDT