Re: handling 1xx responses

Robert Collins wrote:

> Which is no different to today.

It sure is. Direct TLS (port 443) ensures that the protocol will be TLS (or
SSL). A man-in-the-middle cannot downgrade this to plaintext HTTP. Same thing
when using the CONNECT method as this is only a wrapper around direct TLS.

The most similar option in RFC2817 (but not equivalent) is mandatory use of
TLS, i.e. the use of a no-op request to negotiate the use of TLS before
proceeding, but this requires the browser do not rely on any Upgrade response
from the server to switch to TLS. As it is a negotiation man-in-the-middle
attacks is a reality and it is expected several such attacks will be possible
before all implementations gets it correct.

> If squid supported TLS on port 80, then
> at least the squid->origin & squid->client connections could be
> encrypted. (Section 8). I think there is one mistake there though: the
> client CAN NOT insist on the server upgrading when there is a proxy,
> BECAUSE the proxy MUST NOT forward the Upgrade: header (and so the
> OPTIONS method will have no impact). The only thing the client can do is
> insist on a connect. Hmm, I wonder where to send feedback.

The RFC is pretty clear from what I can tell.

Upgrade: TLS/1.0

is hop-by-hop, negotiating TLS for this hop, not end-to-end.

As the application of TLS is almost end-to-end the CONNECT method is needed
when using proxies.

Applying TLS hop-by-hop also has it's value, but does not give any of
end-to-end security features usually connected with the use of TLS.

> > * User interface and trust. Users are used to https:// URLs meaning
> > something is supposedly secure. Using the Upgrade option does not provide
> > any such indication and other means must be used to indicate the URL is
> > secure or that requests must/will be sent encrypted.
>
> There is also the key symbol in the browser.

Which only gives an indication after-the-fact, which is too late from a
security point of view.

How do you know that the information you have entered in a form will be sent
TLS encrypted to the server?

> > * All existing proxies (including all Squid installations) will need to
> > be reconfigured to allow CONNECT to port 80. The previous Netscape
> > document strongly recommends CONNECT to only be allowed for known SSL
> > services.
>
> IFF the intermediate proxies don't support the Upgrade: TLS/1.0 token.
> But yes, I agree wholeheartedly that this will slow adoption.

From what I understand you cannot request a tunnel by sending Upgrade: TLS/1.0
to a proxy. This will make the protocol between the client and the proxy
TLS/1.0, but says nothing about the protocol between the proxy and the next
hop.

If the proxy chooses to implement this by switching to tunnel mode then it is
the choice of the proxy, not an aspect of the protocol. (proxies are always
allowed to switch to tunnel mode when seeing protocol features they cannot
handle, or pretty much any other reason)

The only exception in terms of Squid is when Squid is used as a transparent
proxy. It should then detect the precense of Upgrade: TLS/1.0 in the request
and switch to tunnel mode (and use CONNECT to any peer proxies when
forwarding, internally swallowing the 200 reply).

Regards
Henrik
Received on Wed Sep 04 2002 - 06:38:11 MDT