Re: handling 1xx responses

On Wed, 2002-09-04 at 21:34, Henrik Nordstrom wrote:

> Looks like it. Should not be too hard to add to the SSL support. But I am not
> sure if there will be anyone requesting this feature as it is a feature that
> is very likely to have a hard time to get accepted and working on the
> Internet as it is today.
>
> Issues:
> * Man-in-the-middle attacks forcing downgrades by removing the Upgrade
> header.

Which is no different to today. 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.

> * 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.

> * 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.

Rob