Subject: Re: [websec] Some questions about HSTS

From: Devdatta Akhawe <[email-masked]>
Date: Wed, 1 Dec 2010 11:18:10 -0800

>
> There is also a proposal to solve the "hotel problem" on the HTTP level:
> http://tools.ietf.org/html/draft-nottingham-http-portal-01

I don't think that works for SSL. From the draft :
 " This memo does not address non-HTTP applications, such as IMAP, POP
or even TLS-encapsulated HTTP"

basically, no one can insert a 428 header if you are using SSL, and
the hotel won't let you use SSL until you click on 'I agree', but with
STS the browser will show a network error if the hotel tries to insert
the 'I agree' page into the SSL session, making the user think the
hotel Wireless isn't working.

cheers
devdatta

---

From: Marsh Ray <[email-masked]>
Date: Wed, 01 Dec 2010 14:22:43 -0600

> hotel Wireless isn't working.

Although it's obviously inappropriate for a user to accept a hotel's 
certificate for the actual site they requested, at the time the user is 
looking at the 'scary page' would it be entirely wrong to provide a 
mechanism for the hotel to provide a tiny bit of info:

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv

An intermediate network device is admitting to attempting to intercept 
your connection. No information about your original web request has been 
provided to this device other than the protocol and hostname 
(https://bank.example.com).

The intercepting device provides the following information:

Entity name: [Luddite Hotel, 123 Obnoxious St., Unwelcomeville, MD]
Reason codes: TOS_AGREEMENT_REQUIRED, POSSIBLE_PAYMENT_REQUIRED
More information: http://hotelwall-000036.internal.dns/

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Only minimal information is accepted over the untrusted connection. 
Perhaps just entity name, some codes from a predefined set, and perhaps 
a hostname (not a full link) for follow up.

The error page is considered to have come from an unique and untrusted 
origin. If there are any links allowed, no 'Referer' header should be sent.

If they were standardized, these fields could be communicated in the 
bogus cert the MitM box presents. Or a proper TLS extension could be 
made for it.

Just an idea, perhaps there have been similar proposals in the past?

- Marsh

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Wed, 1 Dec 2010 13:30:46 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Marsh Ray

> An intermediate network device is admitting to attempting to intercept your
> connection. No information about your original web request has been
> Entity name: [Luddite Hotel, 123 Obnoxious St., Unwelcomeville, MD] Reason
> codes: TOS_AGREEMENT_REQUIRED, POSSIBLE_PAYMENT_REQUIRED More
> information: http://hotelwall-000036.internal.dns/

It seems to me that a well-defined, completely standard, and handled at a different layer of the architecture approach is called for, unfortunately.  I'm sympathetic to the need/desire to do NAC (Network access control) of some sort, but I don't think arbitrary connection hijacking is the right way to do it, and supporting it long terms is a security-UI nightmare.

- Andy

---

From: Devdatta Akhawe <[email-masked]>
Date: Wed, 1 Dec 2010 12:53:33 -0800

> It seems to me that a well-defined, completely standard, and handled at a different layer of the architecture approach is called for, unfortunately.  I'm sympathetic to the need/desire to do NAC (N…

+1

I was just saying that the HTTP level solution in the RFC seems wrong
- the issue they are trying to solve is 'network access' which is
lower down than HTTP. Unfortunately, HTTP == network many a times (for
example in hotels, cafe  etc).

cheers
devdatta

---

From: Marsh Ray <[email-masked]>
Date: Wed, 01 Dec 2010 15:08:42 -0600

On 12/01/2010 02:53 PM, Devdatta Akhawe wrote:
>> It seems to me that a well-defined, completely standard, and
>> handled at a different layer of the architecture approach is called
>> for, unfortunately.  I'm sympathetic to the need/desire to do NAC
>> (Network access control) of some sort, but I don't think arbitrary
>> connection hijacking is the right way to do it, and supporting it
>> long terms is a security-UI nightmare.
>
> +1
>
> I was just saying that the HTTP level solution in the RFC seems
> wrong - the issue they are trying to solve is 'network access' which
> is lower down than HTTP. Unfortunately, HTTP == network many a times
> (for example in hotels, cafe  etc).

(+1)^2   I agree with both of you.

I don't like talking about a "good way" to do this because I think it's 
something that shouldn't need to be done (in general). I think it's 
already over-used and making a simple 'on' switch for this kind of 
feature is just going to cause people to turn it on unnecessarily even 
more often.

But we cannot ignore the counter argument:

     It's already being done. All the darn time. Badly.
     In ways that are breaking our stuff.
     And putting at risk new stuff (like HSTS).

- Marsh