Cryptography Reference
In-Depth Information
Supporting SSL When Proxies Are Involved
If you tried to use the HTTPS example client from Chapter 6 from behind a web
proxy, you were probably disappointed in the results. The TLS model doesn't
work at all with the proxy model. When proxies are involved, the client connects
to the proxy, tells the proxy which document it would like to view, and the proxy
retrieves that document and returns it on behalf of the client. This works fi ne
in the HTTP model; the client barely even needs to modify its behavior based
on the proxy. Rather than establishing a socket connection to the target site, the
client just establishes a socket connection to the proxy, submits essentially
the same request it would normally submit, and the proxy forwards that request
on to the target.
This breaks down completely when you want to use HTTPS. Remember that
when using HTTPS, before you transmit a byte of HTTP data, the fi rst thing
you must do is complete a TLS handshake. This is important because the TLS
handshake establishes that you're talking to the server you think you're talking
to (or, more pedantically, an entity that has convinced a certifi cate authority
that it legitimately owns a specifi c domain name). This is necessary to guard
against man-in-the-middle attacks. Unfortunately, a proxy is, by defi nition, a
man-in-the-middle. You may be inclined to trust it — most likely you don't have
a choice in the matter — but TLS doesn't.
Possible Solutions to the Proxy Problem
Other than just disallowing secure connections through proxies, the most
obvious solution to this problem might be to establish an HTTPS connection to
the proxy, forward the request, and allow it to establish an HTTPS connection
to the target and continue as usual. This means that the proxy must be able to
present a certifi cate signed by a certifi cate authority trusted by the browser, or
the user needs to prepare to ignore untrusted certifi cate warnings. If the proxy
presents a signed certifi cate, it needs to either purchase a top-level signed certifi -
cate, which is expensive, or it needs to distribute its own certifi cate authority to
every browser that is confi gured to use it — which is administratively diffi cult.
Of course, you can always mandate that the browser never establish an HTTPS
connection to the proxy; if it wants a secure document, it should establish a
plain-old socket connection to the proxy and let the proxy deal with the secure
negotiation. This presupposes, of course, that every node between the browser
and the proxy is trusted because everything that passes to the proxy is passed
in plaintext. This may or may not actually be the case.
A more serious problem with both of these approaches, however, is that the
client itself can't see any certifi cate warnings. If the certifi cate is out of date,
untrusted, or for a different domain than the one requested, only the proxy is
aware of this. In addition, the proxy needs to know which CAs the client trusts,
Search WWH ::
Custom Search