[squid-users] ssl_bump with cache_peer problem: Handshake fail after Client Hello.

[Amos Jeffries]

On 9/11/2015 10:43 p.m., maple wrote:
> Hi Amos,
> 
> thanks for confirmation, but I'm not sure if my upstream proxy support
> TLS/SSL in that way as you said, but we can use it to proxy both http and
> https request, does it mean it support TLS/SSL?
> 
> To be honest, I'm not familiar with principle of http/https proxy at all,
> for solving this problem, I read some  post about them, http proxy is pretty
> straight-forward, but for https proxy, I'm really confused with its
> explanation from various posts. if possible, could you help to answer my
> some basic questions about it? thanks in advance.

The principles are outlined in
<http://tools.ietf.org/html/rfc7230#section-2.3>

Proxying is very simple. The proxy receives the connection interprets
the message, and relays it to an upstream server believed to be able to
handle it.

The 'S' in HTTPS adds only one extra requirement to that. Which is that
the message only be sent over secure connections ("S" / "Secured"). So
an upstream server which is receiving messages over TLS or SSL is able
to handle those messages, but one receiving over TCP cannot since TCP is
not a secure protocol.


> 
> 1 let's talk scenario about explicitly using https proxy on client side in
> first: it's said that client connects to the proxy and makes a CONNECT
> request to setup TCP tunnel between client and server, the https proxy
> blindly forwards data in both directions without knowing anything about the
> contents.

No. CONNECT is just a HTTP message.

The purpose of CONNECT is to setup a blind tunnel through a proxy. It is
frequently used to tunnel TLS protocol connections over a proxy.

Notice how I avoid "HTTPS" when describing that. TLS can transfer other
protocols than HTTP (aka HTTPS), and CONNECT can setup a tunnel for
other protocols than TLS.

What you are describing above is a just a regular HTTP proxy, relaying
data in a tunnel. It has zero interaction with the security, HTTPS or
anything involved with them beyond the plain-text CONNECT message itself.


> The negotiation of the SSL connection happens over this tunnel,
> and the subsequent flow of requests and responses are completely opaque to
> the proxy.

Yes. TLS and TCP are just types of connection.

> 
> it's easy to understand, but it seems there is no need for proxy to hack
> https, so why some Man-In-The-Middle proxy like squid make great effort to
> intercept these https traffic? what kind of user case will use this
> intercept function?

Good question. The answer is that not all software supports HTTP
proxies, and some network admin are too lazy to setup auto-configuration
properly on their networks.

When the client both supports and is configured to use an HTTP proxy,
the above is pretty much exactly how it goes for HTTPS.
The best practice guideline for designing the network setup is
<http://wiki.squid-cache.org/SquidFaq/ConfiguringBrowsers#Recommended_network_configuration>.
Note how interception is almost a last-resort measure.

But when the client is trying to use port 443 the traffic there is not
going to or through the proxy (or not supposed to be). So there is no
CONNECT request wrapper around it for a proxy to handle...


> 
> 2 for transparent mode, as I understand(please correct me if I'm not right),
> it's because that destination hostname/IP is omitted in the CONNECT request,

There is *no* CONNECT request from the client. What you can see logged
in current Squid is a fake/synthetic one created by Squid based on the
plain-text TCP layer packet details _underneath_ the TLS protocol layer.

We do this so that we only need one set of processing logics inside
Squid and can treat the intercepted connection as if the client had sent
a CONNECT. Either decrypting the TLS inside the tunnel, or relaying it
to to an upstream peer if it is not decrypted.

> so the routing mechanism that has performed the redirection keeps track of
> the original destination, transparent proxy will fetch the original
> destination from routing mechanism,  then perform the same process as
> explicitly using proxy above. 

Part of that process is determining if the client is atually sending TLS
and decrypting it...

> 
> so for case in my scenario, it seems there is also no reason to use
> intercept way for hack https with transparent mode. why not squid just act
> as forwarder to setup tunnel for https communication between server and
> client? what's it for to make big effort to intercept and create fake
> certificate?

The process of decrypting the TLS layer inside the CONNECT involves
stripping away the CONNECT (fake or not). Then performing TLS operations
with one or other end of the connection.


If you want just a forwarder that takes port 443 traffic and relays it
as-is through an upstream proxy you can do so by opting *not* to do the
decrypt stages of SSL-Bump. Like so:
 ssl_bump splice all

(You still need the interception part to actually receive the TCP
packets though).


It is only when you want to do things like filter the https:// URL the
client is requesting, detailed logging, caching or content adaptation
that you need to to decrypt and loose the ability to relay to insecure
servers.

Also, that ability is only lost because the code doing server
connections lacks ability to generate CONNECT messages yet (only the
code doing TCP intercept can do that right now). It is a missing feature
that gets a lot of complaints, but so far nobody has been willing to do
the work or sponsor it. The hobbyists amoung us are inching slowly
towards it, but not fast.
 (personally I'm working on getting GnuTLS support added so the OS
people can legally distribute Squid with TLS enabled by default and the
need for re-CONNECT disappears. "two birds with one stone" as the saying
goes.)

Amos