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
