Re: [squid-users] unable to connect to ssl site: google+

From: Amos Jeffries <>
Date: Wed, 28 Dec 2011 15:35:02 +1300

On 28/12/2011 10:56 a.m., ftiaronsem wrote:
> Dear list
> Today I ran into a problem, which I am unable to solve myself. Almost
> all ssl sites work well. For instance I can browse to
> or
> without problems. However I am unable to connect to google+
>, getting: "The connection has timed out".
> While browsing to i.e I get in my access_log:
> 1325006076.306 0 TCP_DENIED/407 1733 CONNECT
> - NONE/- text/html
> 1325006076.311 0 TCP_DENIED/407 1903 CONNECT
> - NONE/- text/html
> 1325006076.633 0 TCP_DENIED/407 1709 CONNECT
> - NONE/- text/html
> 1325006076.699 2 TCP_DENIED/407 1879 CONNECT
> - NONE/- text/html
> 1325006076.817 112 TCP_MISS/200 1446 CONNECT
> schueler2 DIRECT/ -
> While browsing I get:
> 1325006240.062 52 TCP_DENIED/407 1706 CONNECT
> - NONE/- text/html
> 1325006240.066 1 TCP_DENIED/407 1876 CONNECT
> - NONE/- text/html
> 1325006240.119 49 TCP_MISS/404 0 CONNECT
> schueler2 DIRECT/- -
> I am running Squid Version 2.7 on an ubuntu 10.04 LTS machine. User
> authentication is done via NTLM against an AD, using the
> script. I have attached my squid.conf to this mail.
> My first questions is if course: Whats the reason for the google+
> request failing?

Unknown. Ask google, or trace the TCP packets between squid and to see what they are doing. The log is not recording any
server for the domain as having responded to TCP
connection attempts (probably just a display bug in that aging squid

> My second question is why I see three log file entries for each ssl
> request. Two unauthenticated ones and the third one authenticated?

This is a normal part of how Windows NT LAN Manager (aka NTLM) works.
  It requires two HTTP request/response pairs in order to perfom a
stateful auth handshake (violating the HTTP requirement that each
request is independent and stateless).
  It requires that HTTP chains of proxies offer end-to-end connectivity
(violating the HTTP requirements that connections are hop-by-hop and
  It requires everything over a TCP connection comes from the same
client software (breaking the HTTP pipeline features that multiplex many
client requests over fewer TCP connections, relying on the violated HTTP
requirements above).

I recommend taking a look at Kerberos authentication which offers newer
security algorithms and less bandwidth waste (ie imagine uploading a
whole video 3 times in a row as the POST body during that handshake). It
still suffers from the last two requirements though.

Received on Wed Dec 28 2011 - 02:35:08 MST

This archive was generated by hypermail 2.2.0 : Wed Dec 28 2011 - 12:00:03 MST