On 08.10.2012 01:16, Oguz Yilmaz wrote:
I am trying with ssl-bump. I am using squid 3.1.21.
First of all I got the CANNOT FORWARD error page. When I debug I
found:
2012/10/07 14:27:49.380| fwdConnectStart: Ssl bumped connections
through parrent proxy are not allowed
2012/10/07 14:27:49.380| forward.cc(286) fail: ERR_CANNOT_FORWARD
"Service Unavailable"
Then, I added always_direct rule and reached to https site.
acl HTTPS proto HTTPS
always_direct allow HTTPS
According to message above and a reply from Amos in another thread,
squid stopped getting https over peers, because "it does not again
encrypt ssl connection for the peer". Capability of getting https
pages over peers was previous behaviour and I did not understand why
squid does not get pages from peers instead of direct? I assume it is
about software architecture.
Without SSL-bump the HTTPS us seen by Squid as a CONNECT request with
encrypted binary data. The CONNECT request and data can be safely sent
to a peer and the reply shunted straight back to the client. This is
otherwise known as a blind tunnel / binary tunnel through the HTTP
proxy.
This can be done safely whether the peer supports SSL or not. Or even
whether your proxy supports SSL or not.
With SSL-bump the CONNECT wrapper request is removed, the encrypted
data decrypted. THEN Squid handles the decrypted request almost as if it
was sent in to a https_port. Squid does not support adding the CONNECT
request wrapper back when passing the request to non-SSL peers. If the
request were relayed out to peer this would result in HTTPS be decrypted
then sent "in the clear" to any peers - seriously breaking the security
on HTTPS. (you say earlier Squid did that, we know, that got fixed
pretty soon after it was found but there are still a few releases which
do it).
In reverse-proxy we can safely assume that peers are part of a trusted
backend system for the reverse-proxy. For the corporate situations where
SSL-Bump is used we CANNOT make that assumption safely even if the peer
has the SSL connection options configured and must, for now, block
relaying to peers.
Is this the current situation(3.HEAD). Are there any project to
implement getting SSL pages over peers?
All current Squid releases share the above behaviour. SSL-Bump in 3.1
was experimental and rather limited in what it can do. I recommend using
at least 3.2 for less client annoyance, preferably use 3.3 for the best
SSL-Bump behaviour (server-first bumping fixes a few other security
problems).
As to work underway; I made some effort to work towards re-wrapping
CONNECT on outbound requests for another project unrelated to SSL-Bump
but sharing the same requirement. It is still in the planning stages
with no timeline for any code. Any contributions toward that would be
welcome.
Because this mode obligate me
to choose between:
a- do https filtering in squid and does not forward https to
dansguardian (I use https domain name filtering on dg)
b- dont do https filtering and continue with https domain name
filtering on dansguardian.
So far as I'm aware anything you can do in DG can also be done in
Squid. So (a) is your best option.
2012/10/07 14:35:50.142| peerSelectCallback:
https://www.haberturk.com/
2012/10/07 14:35:50.142| Failed to select source for
'https://www.haberturk.com/'
2012/10/07 14:35:50.142| always_direct = -1
Hmm. -1 here is strange. It means some lookup (authentication, or IDENT
or external ACL) is being waited for. Scan your whole config for
always_direct lines and check their order carefully.
The "always_direct allow HTTPS" should have produced "1" there and made
your Squid use DNS results for www.haberturk.com instead of
ERR_CANNOT_FORWARD.
Amos
2012/10/07 14:35:50.142| never_direct = 0
2012/10/07 14:35:50.142| timedout = 0
2012/10/07 14:35:50.142| fwdStartComplete: https://www.haberturk.com/
2012/10/07 14:35:50.142| fwdStartFail: https://www.haberturk.com/
2012/10/07 14:35:50.142| forward.cc(286) fail: ERR_CANNOT_FORWARD
"Service Unavailable"
https://www.haberturk.com/
2012/10/07 14:35:50.142| StoreEntry::unlock: key
'31F6E0CCC4924D82F5F0070DE9555597' count=2
2012/10/07 14:35:50.142| FilledChecklist.cc(168) ~ACLFilledChecklist:
ACLFilledChecklist destroyed 0x91502d0
2012/10/07 14:35:50.142| ACLChecklist::~ACLChecklist: destroyed
0x91502d0
2012/10/07 14:35:50.142| forward.cc(164) ~FwdState: FwdState
destructor starting
2012/10/07 14:35:50.142| Creating an error page for entry 0x9152990
with errorstate 0x91504a0 page id 13
2012/10/07 14:35:50.142| StoreEntry::lock: key
'31F6E0CCC4924D82F5F0070DE9555597' count=3
2012/10/07 14:35:50.142| errorpage.cc(1075) BuildContent: No existing
error page language negotiated for ERR_CANNOT_FORWARD. Using default
error file.
Best Regards,
--
Oguz YILMAZ
