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

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
> https://banking.postbank.de or https://epetitionen.bundestag.de/
> without problems. However I am unable to connect to google+
> https://plus.google.com, getting: "The connection has timed out".
>
> While browsing to i.e https://epetitionen.bundestag.de/ I get in my access_log:
> 1325006076.306 0 192.168.2.104 TCP_DENIED/407 1733 CONNECT
> epetitionen.bundestag.de:443 - NONE/- text/html
> 1325006076.311 0 192.168.2.104 TCP_DENIED/407 1903 CONNECT
> epetitionen.bundestag.de:443 - NONE/- text/html
> 1325006076.633 0 192.168.2.104 TCP_DENIED/407 1709 CONNECT
> sdc.bundestag.de:443 - NONE/- text/html
> 1325006076.699 2 192.168.2.104 TCP_DENIED/407 1879 CONNECT
> sdc.bundestag.de:443 - NONE/- text/html
> 1325006076.817 112 192.168.2.104 TCP_MISS/200 1446 CONNECT
> sdc.bundestag.de:443 schueler2 DIRECT/217.79.215.173 -
>
> While browsing https://plus.google.com I get:
> 1325006240.062 52 192.168.2.104 TCP_DENIED/407 1706 CONNECT
> plus.google.com:443 - NONE/- text/html
> 1325006240.066 1 192.168.2.104 TCP_DENIED/407 1876 CONNECT
> plus.google.com:443 - NONE/- text/html
> 1325006240.119 49 192.168.2.104 TCP_MISS/404 0 CONNECT
> plus.google.com:443 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
> wbinfo_group.pl 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
plus.google.com to see what they are doing. The log is not recording any
server for the domain plus.google.com as having responded to TCP
connection attempts (probably just a display bug in that aging squid
version).

> 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
independent).
  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.

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