Re: The 's' in https: more trouble than it's worth? [metadataInURI-31]

On Mar 17, 2006, at 3:32 PM, Dan Connolly wrote:

> I think that one of the main arguments for the separate port number  
> and
> URI scheme for https was that the client software needed to know to  
> make
> a secure connection; upgrading from a clear connection to a secure  
> connection is subject to man-in-the-middle attacks.

No, there are two issues.  https is needed to let the client know that
it must make a private connection prior to sending the first request,
since the other two options are worse:

   1) prefixing all requests with a round of secure negotiation just
      to find out if the resource is supposed to be private is  
prohibitively
      expensive when we consider the normal case is no encryption;

   2) making the request in the clear first, and then finding out later
      that it was supposed to be secret, is counterproductive.

The separate port, OTOH, dates back to the IETF's original notion of
reserved services. It makes routing to the right protocol processing
modules a lot cleaner, as opposed to forcing the routers to
understand each application protocol's upgrade formula.  However,
tunnels are now so common that the only thing reserved ports gives
us is a list of old services that must be blocked at firewalls.

> At the workshop this week, the focus was on the "last two feet",  
> i.e. between
> the client software and the human operator, and from this  
> perspective, it
> seemed that the 's' is more trouble than it's worth. There's a  
> failure mode
> where
>   User follows a link to https://example.com/pg
>    - example.com is under attack; doesn't respond
>  User tries http://example.com/ instead.
>   - bad guy has gotten in the middle, and fleeces user
>
> The argument might have been more subtle than that. I hope somebody  
> can help
> me re-create it.

I hope it was more subtle than that, since example.com:80 and
example.com:443 are different authorities and there is no guarantee
that they have anything in common.  I suspect it was some complaint
about broken cookie authentication leaking between hosts on different
protocols, which of course it may do given that cookie auth is broken.

> There are, of course, problems of aliasing and such.
>
> There was some argument that http: is enough, combined with...
>
>   Upgrading to TLS Within HTTP/1.1 Khare and Lawrence May 2000
>   http://www.ietf.org/rfc/rfc2817.txt

Well, whoever argued that is flat out wrong and should read the HTTP
archives.  https is still needed to inform the client that privacy
is needed.  Upgrade only removes the need for a separate port.  I
explained it in detail when BEEP had the same issue, but I don't know
where the archives of that list went.

....Roy

Received on Monday, 20 March 2006 04:57:19 UTC