Re: [apps-discuss] I-D Action: draft-nottingham-http-browser-hints-02.txt

[Barry Leiba <[e-mail]>]

>> A client that wants to use HTTPS, but isn't sure whether this part of
>> the site supports it, can do it one of two ways:
>>
>> 1. Try HTTPS.  If it doesn't work, fall back to HTTP.
>>
>> 2. Use HTTP.  If a "hint" is included in the HTTP response that says
>> HTTPS is OK, then switch to HTTP.
>>
>> You're proposing 2.  Is that right?
>>
>> Assuming that's right, I'm saying that 1 is better.
>
> You're right.  But: a client needs to do 1 for each time it tries to access
> something whereas 2 would only be required once.  2 is more practical; are
> there any other considerations which led you to the conclusion that 1 is
> better?

2 is not more practical.  Very few (probably no) web sites will have
HTTPS enabled or disabled item by item.  In reality, clients will try
HTTPS, it will work, and it will continue to work for most or all of
what they're doing at that site.  When it fails, they'll fall back to
HTTP and continue using it for the section of the site for which HTTPS
failed.

On the other hand, method 2 requires that they try to figure out when
they can safely use the hint they were given before.  When, exactly,
is it that they cross over into another part of the site, which might
not support HTTPS?  If they get it wrong, they wind up with method 1
anyway.

Apart from that, method 1 ensures that if they can use HTTPS, the
entire client session (that is, all interactions between the client
and the site in question) is protected by TLS.  With method 2, the
initial communication is in the open, unprotected, and the client has
to switch to protection after getting the hint.  That creates a window
for snooping.  Also, a MitM attacker can remove the HTTPS hints,
preventing the client from ever even trying SSL.

This looks like a bad solution in search of a problem.

Barry