Subject: [websec] Some questions about HSTS

From: Yoav Nir <[email-masked]>
Date: Mon, 22 Nov 2010 12:29:41 +0200

Hi all

I have just finished reading draft -02, and I have some questions.

In sections 2.4.1.1, point #9 says:
   9.  UAs need to prevent users from clicking-through security
       warnings.  Halting connection attempts in the face of secure
       transport exceptions is acceptable.
What exactly are these secure transport exceptions?  Expired certificates? Mismatched FQDN? Revoked certificates? Unreachable CRL? Untrusted CA? Self-signed?

Point #9 seems to say contradictory things. On the one hand, it says that "UAs need to prevent..."  and I interpret "need" to mean "MUST", but on the other hand, halting connections is just "acceptable". So is it MAY or MUST?

Also, I don't understand why this change is needed. HSTS is supposed to stop a very specific attack vector - a user duped into using insecure HTTP over the (presumably secure) HTTPS. Why is it necessary to all of a sudden change UA behavior?  RFC 2818 specifically allows this:
   If the hostname does not match the identity in the certificate, user
   oriented clients MUST either notify the user (clients MAY give the
   user the opportunity to continue with the connection in any case) or
   terminate the connection with a bad certificate error.

As it is, HSTS cannot be used by servers with self-signed or corporate certificates, for fear that user agents may not allow the user to browse.

My second question regards the UA behavior when policy changes. Suppose a website has had the HSTS header for a while. The UA has a cache entry with a TTL of several more weeks. Now the UA connects to the server (over HTTPS) and does not get an HSTS header at all. What now?  If there was a header and it was merely changed, the spec says to update the cache entry. But if the header is missing altogether, does that mean that the UA should delete the cache entry?

Yoav

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Mon, 22 Nov 2010 09:57:21 -0700

> What exactly are these secure transport exceptions?  Expired certificates?
> Mismatched FQDN? Revoked certificates? Unreachable CRL? Untrusted CA?
> Self-signed?

Anything that would currently pop a browser warning for a user currently.  Browsers differ slightly in how they handle OCSP, etc.  In any case where a browser has already made the policy decision it should show a certificate "error", it must now abort.

> Also, I don't understand why this change is needed. HSTS is supposed to stop
> a very specific attack vector - a user duped into using insecure HTTP over the
> (presumably secure) HTTPS. 
> 
> As it is, HSTS cannot be used by servers with self-signed or corporate
> certificates, for fear that user agents may not allow the user to browse.

That is correct.  I personally believe, as do several of the contributors on this (and I hope I'm not speaking too much out of turn) that self-signed certificate warnings are just a punt, and an easy way for a user to make a bad security decision.  If  you want to support HTTPS, do it with a cert that your browser already trusts.  Anything else is just a recipe for a MiTM attack.  If a host advertises HSTS, it is specifically opting into this scheme, whereby all certificate warnings will cause abort, with no chance to "fool" the user into making the wrong decision.
 
> My second question regards the UA behavior when policy changes. Suppose
> a website has had the HSTS header for a while. The UA has a cache entry with
> a TTL of several more weeks. Now the UA connects to the server (over
> HTTPS) and does not get an HSTS header at all. What now?  If there was a
> header and it was merely changed, the spec says to update the cache entry.
> But if the header is missing altogether, does that mean that the UA should
> delete the cache entry?

I think we can make this clear, but until the client receives a new header, it does not tinker with the cache.  We do say the header should be present in all /most server responses, but the behavior should be that the value persists until set to something else.

- Andy

---

From: Marsh Ray <[email-masked]>
Date: Mon, 22 Nov 2010 11:48:58 -0600

On 11/22/2010 10:57 AM, Steingruebl, Andy wrote:
>> In sections 2.4.1.1, point #9 says: 9.  UAs need to prevent users
>> from clicking-through security warnings.  Halting connection
>> attempts in the face of secure transport exceptions is acceptable.
>> What exactly are these secure transport exceptions?  Expired
>> certificates? Mismatched FQDN? Revoked certificates? Unreachable
>> CRL? Untrusted CA? Self-signed?
>
> Anything that would currently pop a browser warning for a user
> currently.  Browsers differ slightly in how they handle OCSP, etc.
> In any case where a browser has already made the policy decision it
> should show a certificate "error", it must now abort.

I feel that it would be misguided for an RFC to specify MUST with 
regards to UA interaction with the user, however well intentioned it may 
be. It's the user's browser after all, not the IETF's, and not the web 
site's. If a user wants to install (or create) and use a program which 
exchanges valid protocol messages with interaction or screen content, 
that's his right, regardless of what some RFC says.

I agree with the intent however. It seems like a case for a 
strongly-worded SHOULD.

>> Also, I don't understand why this change is needed. HSTS is
>> supposed to stop a very specific attack vector - a user duped into
>> using insecure HTTP over the (presumably secure) HTTPS.
>>
>> As it is, HSTS cannot be used by servers with self-signed or
>> corporate certificates, for fear that user agents may not allow the
>> user to browse.
>
> That is correct.  I personally believe, as do several of the
> contributors on this (and I hope I'm not speaking too much out of
> turn) that self-signed certificate warnings are just a punt, and an
> easy way for a user to make a bad security decision.  If  you want to
> support HTTPS, do it with a cert that your browser already trusts.

Seems entirely reasonable to me that the user should have a way to add 
and remove trust of CAs and even self-signed server certs.

The key distinction being that additions to the trusted set are made 
because of prior arrangement. It specifically needs to not happen 
subsequent to a failed server authentication.

> Anything else is just a recipe for a MiTM attack.  If a host
> advertises HSTS, it is specifically opting into this scheme, whereby
> all certificate warnings will cause abort, with no chance to "fool"
> the user into making the wrong decision.

HSTS should be thought of as a way for a site to communicate its policy 
to the user, via the UA: "I (the site) commit to always running an HTTPS 
service, so you can rewrite http: links and failures on port 443 may 
indicate an attack."

It's not a way for a site to get the UA to force restrictions upon the 
user. Trying to enlist the user's software against their intentions is 
using the same failed logic behind DRM.

- Marsh

---

From: Devdatta Akhawe <[email-masked]>
Date: Mon, 22 Nov 2010 09:53:03 -0800

>
> HSTS should be thought of as a way for a site to communicate its policy to
> the user, via the UA: "I (the site) commit to always running an HTTPS
> It's not a way for a site to get the UA to force restrictions upon the user.
> Trying to enlist the user's software against their intentions is using the
> same failed logic behind DRM.
>

The problem is that the average user has no understanding what the
certificate means and just says 'please show me the content' (clicks
yes)

That said, this behavior of HSTS makes me uncomfortable too.
Unfortunately, some browsers have already implemented this; hopefully
other browsers will pause before implementing this behavior.

-devdatta

> - Marsh
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec
>

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Mon, 22 Nov 2010 11:00:57 -0700

> -----Original Message-----
> From: Marsh Ray [mailto:[email-masked]]
> 
> I feel that it would be misguided for an RFC to specify MUST with regards to
> UA interaction with the user, however well intentioned it may be. It's the
> user's browser after all, not the IETF's, and not the web site's. If a user wants
> to install (or create) and use a program which exchanges valid protocol
> messages with interaction or screen content, that's his right, regardless of
> what some RFC says.

I don't disagree.  I do however feel that this should be exceptions, and maybe in an "about:config" configuration, rather than the default or in plain view in the UI.  Yes, it is the user's computer.  But if we didn't want to make security decisions for them, then browsers wouldn't include phishing filter, certificate warnings, etc. As it is, we are already making security policy decisions for users in the browser, and here were are simply proposing another.

- Andy

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Mon, 22 Nov 2010 11:05:02 -0700

> Trying to enlist the user's software against their intentions is using the same
> failed logic behind DRM.

Sorry, didn't reply to this specific point. Unlike DRM I fully support users being able to opt-out if they'd like.  I'm looking to protect the amateur rather than expert though.   I don't know really though hos you think this is defeating user-intent?  The user in this case doesn't know whether the site in question is really asking them to approve the exception, their browser is.  We're giving the browser more information to make that decision.  Only sites that opt-in to HSTS get this behavior in the first place, so while the server-side does control the behavior (absent a user modifying their UA) it is hard to see how we're defeating user choice here. A contract is implied here, that a site will keep its certificates up to date, etc.

What decision of the user do you really think we're thwarting?  This site has told me previously its only going  to use a cert my browser trusts, but I'm getting a certificate warning, and I think I'll click through it anyway.... ?

- Andy

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 22 Nov 2010 10:11:05 -0800

>I don't disagree.  I do however feel that this should be exceptions, and maybe in an "about:config" configuration, rather than the default or in plain view in the UI.  Yes, it is the user's computer…

The "we" here, the IETF, generally does not make such decisions for users. We make protocols and recommendations to developers. The text in this document should be worded as such.

--Paul Hoffman, Director
--VPN Consortium

---

From: Marsh Ray <[email-masked]>
Date: Mon, 22 Nov 2010 12:11:20 -0600

> certificate means and just says 'please show me the content' (clicks

Yep. It's a problem. Ultimately I don't think there's a technical 
solution to it.

> other browsers will pause before implementing this behavior.

I don't think there's a huge risk if individual browsers implement 
heavy-handed security policy. Users will simply switch to a browser that 
lets them do what they want, or maybe they like a strict browser after 
all. The market can take care of that.

The danger is when a documented protocol seems to guarantee something to 
work a certain way when in reality it doesn't, or is trivial to bypass. 
Mandated UI restrictions will hold up against product designers and 
users about as well as software DRM held out against a reverse engineer 
with a debugger.

However, the imaginary restrictions will get documented in books as if 
they were fact. (Remember the little Javascript tricks that supposedly 
prevented the user from saving images from your site?) Then web 
designers and admins end up relying on them as a security property and 
hilarity ensues.

- Marsh

---

From: Marsh Ray <[email-masked]>
Date: Mon, 22 Nov 2010 12:50:45 -0600

On 11/22/2010 12:05 PM, Steingruebl, Andy wrote:
>
> I don't disagree.  I do however feel that this should be exceptions,
>  and maybe in an "about:config" configuration, rather than the
> default or in plain view in the UI.

Yeah, about:config could be a solution. But I feel it's important to be 
careful of scope creep in a spec, especially if we want it to be 
fully-implemented.

> Yes, it is the user's computer.
> But if we didn't want to make security decisions for them, then
> browsers wouldn't include phishing filter, certificate warnings,
> etc. As it is, we are already making security policy decisions for
> users in the browser, and here were are simply proposing another.

On 11/22/2010 12:11 PM, Paul Hoffman wrote:
 >
 > The "we" here, the IETF, generally does not make such decisions for
 > users. We make protocols and recommendations to developers. The text
 > in this document should be worded as such.

Right, on one level we can think of this as an editorial issue on the 
scope of a protocol spec.

On 11/22/2010 12:05 PM, Steingruebl, Andy wrote:
>
> Sorry, didn't reply to this specific point. Unlike DRM I fully
> support users being able to opt-out if they'd like.  I'm looking to
> protect the amateur rather than expert though.   I don't know really
> though hos you think this is defeating user-intent?

One user intends to access Ebay: "That auction ends in 5 minutes 
darnit!" But they're under MitM attack. Say they're at a hotel or 
airport that's trying to redirect them to a captive portal (yes this 
happened to me several times last week). We all know the difficulty in 
explaining to the user that because some crypto bits don't match up 
somewhere we think they could be the target of some Mission 
Impossible-style operation by an international crime syndicate designed 
to capture their Ebay password. Heck, even plenty of network developers 
still wouldn't believe that possibility (though I predict that will change).

But that user's intent deserves to be defeated.
Think about this more insidious case:

I'm a web developer starting to work on a new secure web site. I get 
some pages up and start to test with SSL. What's the first thing I'm 
going to do? Create some self-signed certificates. Clearly I know that 
there's not a security threat here, possibly my client and server are 
both on the same dev box. But if my web browser doesn't let me make 
occasional exceptions, it's going to be less adopted by web developers, 
and they are a highly influential group of users.

Presumably, many or most sites that will deploy HSTS will try it on 
their QA network first. I bet a lot of them are running self-signed. If 
HSTS strictly requires sites to reconfigure their test networks, I 
predict that will significantly reduce adoption.

>  The user in
> this case doesn't know whether the site in question is really asking
> them to approve the exception, their browser is.  We're giving the
> browser more information to make that decision.  Only sites that
> opt-in to HSTS get this behavior in the first place, so while the
> server-side does control the behavior (absent a user modifying their
> UA) it is hard to see how we're defeating user choice here. A
> contract is implied here, that a site will keep its certificates up
> to date, etc.
>
> What decision of the user do you really think we're thwarting?  This
> site has told me previously its only going  to use a cert my browser
> trusts, but I'm getting a certificate warning, and I think I'll
> click through it anyway.... ?

It's more the unintended consequences of scope creep in the IETF 
document. This proposal represents a great improvement at the protocol 
level. My sense is that probably it should quit while it's ahead, and 
not use "MUST" in regards to user interaction issues (a far distant layer).

- Marsh

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Mon, 22 Nov 2010 12:11:18 -0700

> One user intends to access Ebay: "That auction ends in 5 minutes darnit!" But
> they're under MitM attack. Say they're at a hotel or airport that's trying to
> redirect them to a captive portal (yes this happened to me several times last
> week). We all know the difficulty in explaining to the user that because some
> crypto bits don't match up somewhere we think they could be the target of
> some Mission Impossible-style operation by an international crime syndicate
> designed to capture their Ebay password. Heck, even plenty of network
> developers still wouldn't believe that possibility (though I predict that will
> change).

If you don't think these scenarios are at all worth dealing with, then you probably think HSTS is a stupid idea to begin with, right?  If there are no MiTM attackers, then HSTS doesn't make sense.  If you think MiTM attackers are a real possibility, now or in the future, then you probably care about HSTS, and you probably want to avoid user's getting actively attacked them.

I understand that this seems like a science-fiction style attack to some folks, but frankly so was network sniffing at one point... or middleware boxes spoofing DNS (earthlink) or ISPs spoofing DNS responses (many), etc.   

> I'm a web developer starting to work on a new secure web site. I get some
> pages up and start to test with SSL. What's the first thing I'm going to do?
> Create some self-signed certificates. Clearly I know that there's not a security
> threat here, possibly my client and server are both on the same dev box. But
> if my web browser doesn't let me make occasional exceptions, it's going to
> be less adopted by web developers, and they are a highly influential group of
> users.

Don't set HSTS *or* put those certs into your trust-store.  Both are possibilities.    It isn't like there are no workarounds here.  

If I can convince you for a moment that active MiTM attacks will/do happen, what do you propose as a solution that is workable for the average user?

> level. My sense is that probably it should quit while it's ahead, and not use
> "MUST" in regards to user interaction issues (a far distant layer).

I will concede that strictly specifying UA behavior here may be a stretch.  That said, we've left a lot of attack surface over the years because we haven't been clear in specifications about what we consider good design.  I'll let Jeff and the other contributors take up this specific wording point when they are able to chime in.

- Andy

---

From: Yoav Nir <[email-masked]>
Date: Tue, 23 Nov 2010 07:46:54 +0200

Hi Andy.

Taking both your answers together, suppose I have a web server with a corporate or self-signed certificate, which is OK, as I expect all my users to approve an exception (as it's called in Firefox). I turn on HSTS because I'm worried about them being duped by a fake server using HTTP. To me, HSTS reduces the attack surface by making them dupable only on the first ever connect. Then, as it turns out, a certain browser breaks the connection when connecting from outside the organization, because the CDP is not available. Fine, I turn off HSTS, but because the cache is untouched, the users will get intermittent connectivity problems for three more months.

I agree with Marsh, that this is too much of scope creep. It makes sense for a big website like paypal, amazon or gmail to want strict enforcement on the client. But smaller websites don't have the IT department of such companies, and often let their certificates expire. In their case, having HSTS on would cause a lot of trouble on certificate expiry day.

The use case that I am interested in is not a big commercial website, but rather an SSL-VPN portal. These have two relevant properties: They come pre-packaged, and they're SSL-only. It is up to the customer to get a certificate, or generate a self-signed one. I would have liked to have HSTS on by default for such a product, but if that means that customers with self-signed certificates or corporate certificates get long-lasting connectivity problems, I can't justify that.

Sure, I can have a configuration flag for whether or not we should have the header, but administrators tend to configure those wrong just as much as users tend to click through dangerous screens.

What do the current implementations (Chrome, Firefox) do?

Yoav

On Nov 22, 2010, at 6:57 PM, Steingruebl, Andy wrote:

> Scanned by Check Point Total Security Gateway.

---

From: Adam Barth <[email-masked]>
Date: Mon, 22 Nov 2010 22:06:24 -0800

> Taking both your answers together, suppose I have a web server with a corporate or self-signed certificate, which is OK, as I expect all my users to approve an exception (as it's called in Firefox)…

I don't recommend using HSTS with self-signed certificates.  In this
scenario, I'd recommend the corporation install a root certificate in
all machines owned by the corporation and then use that root
certificate to issue whatever other certificates the corporation
needs.

> I agree with Marsh, that this is too much of scope creep. It makes sense for a big website like paypal, amazon or gmail to want strict enforcement on the client. But smaller websites don't have the…

Folks are already in for a headache if they let their certificates
expire.  They'll get big nasty warnings in either case.  The
difference is only whether those warnings will let the user ignore
them.

If you don't think your organization is sufficiently competent to
schedule a reminder to update its certificates, then I don't recommend
using HSTS.

> The use case that I am interested in is not a big commercial website, but rather an SSL-VPN portal. These have two relevant properties: They come pre-packaged, and they're SSL-only. It is up to the…

Indeed.  Please don't use HSTS with self-signed certificates.  HSTS is
a feature for well-maintained web sites that have a need for strong
security.  The reason we designed HSTS was to differentiate between
sites that actually want strong security and sites that are using TLS
but don't have strong security needs.  If you don't need strong
security, you don't need HSTS (and the additional careful
administration it requires).

> Sure, I can have a configuration flag for whether or not we should have the header, but administrators tend to configure those wrong just as much as users tend to click through dangerous screens.

I don't think user agents should offer such a configuration flag.

> What do the current implementations (Chrome, Firefox) do?

They do what the spec says.  TLS errors on HSTS hosts are treated as
fatal errors, much like the host's DNS name not resolving.  There is
no recourse except to reload the page.

Adam

---

From: Yoav Nir <[email-masked]>
Date: Tue, 23 Nov 2010 11:21:53 +0200

> I don't think user agents should offer such a configuration flag.

Not for the UA. For the portal product.

> no recourse except to reload the page.

I have just tested this with Firefox 4 (beta 8 - yesterday's nightly build) and with Chrome (7.0.517.44 if that matters). I used a website where the certificate has several problems: the CA is untrusted, and the CN does not match the domain name. Clearly a cause for red screen / "I understand the risks" message.

With Chrome, I got the red screen on the first connect, and also on the second connect. But STS worked. I typed "http://" and got "https://" instead.

With Firefox, I got the "I Understand the Risks" page both the first and second time, and again STS worked.

So the truth is that both Firefox and Chrome do what IMO is the right thing, and ignore point #9. 

I agree with those developers' choice, but I guess that debate is what mailing lists are for.

Yoav

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Tue, 23 Nov 2010 10:49:56 -0700

> From: Yoav Nir [mailto:[email-masked]]
> 
> I have just tested this with Firefox 4 (beta 8 - yesterday's nightly build) and
> with Chrome (7.0.517.44 if that matters). I used a website where the
> certificate has several problems: the CA is untrusted, and the CN does not
> match the domain name. Clearly a cause for red screen / "I understand the
> risks" message.
> 
> With Chrome, I got the red screen on the first connect, and also on the
> second connect. But STS worked. I typed "http://" and got "https://" instead.
> 

One area of confusion in the spec/implementations is what is means for a certificate to be "trusted" by the browser.  We didn't deal explicitly with what the browser should do when a user has previously clicked through a certificate warning, and generated a permanent exception in the browser.  Is that certificate now fully trusted, or not?  We didn't get into that very much in the spec, as this isn't a spec about how to validate certificates, it only deals with what the browser should do in case the browser has already decided to generate a certificate warning.

> So the truth is that both Firefox and Chrome do what IMO is the right thing,

There are considerable discussion yesterday about the right behavior, and whether this spec should specify browser behavior.  One of the problems we've discovered in looking at a bunch of existing specs, proposed ideas, etc. is that in general most of the specifications are fairly silent on proper user-agent behavior, and as Paul pointed out the IETF hasn't traditionally felt that putting those rules into these specs is a good idea.

I understand that has been the history, and in our defense, there is a lot of divergence of security behavior in these areas, no consistent set of appropriate practices, and we punt those decisions to private coalitions of the browser makers, CAs, etc. such as the CA Browser Forum.   I'd much rather have at least some of these discussions in this forum or at the W3C than in a private "standards" body, as I think we benefit from having more eyes on these specific problems.

If these specific user-agent treatments don't belong here, but we would like them to be standardized across user-agents, and the user-agent developers are willing to cooperate (so far they have been pretty willing) then I'd like to have a spec to point them to, rather than having to have those discussions entirely in private.   I'm open to community suggestions on how to achieve that, but simply saying that user-agent behavior doesn't belong here isn't really a workable solution without a proposal of where they do belong.

- Andy

---

From: Adam Barth <[email-masked]>
Date: Tue, 23 Nov 2010 11:38:51 -0800

> So the truth is that both Firefox and Chrome do what IMO is the right thing, and ignore point #9.

I suspect there's something fishy about your experimental setup.
That's not the intended behavior for either browser.

Adam

---

From: Yoav Nir <[email-masked]>
Date: Tue, 23 Nov 2010 21:47:56 +0200

> One area of confusion in the spec/implementations is what is means for a certificate to be "trusted" by the browser.  We didn't deal explicitly with what the browser should do when a user has previ…

I thought about that, so I was careful not to store a permanent exception in Firefox, and restarted it between connects. That's why I got the "I Understand the Risks" page again.

---

From: Adam Barth <[email-masked]>
Date: Tue, 23 Nov 2010 13:18:51 -0800

> That's not the intended behavior for either browser.

I suspect the issue with your experiment is that we don't accept
Strict-Transport-Security headers over "broken" TLS connections.  This
help prevent web sites from shooting themselves in the foot when they
think their certificate is valid even though it isn't.  To test this
properly, you need to simulate a real attack scenario.  First, receive
the HSTS directive over a TLS connection with a valid certificate and
then play man-in-the-middle and substitute the attacker's certificate.

Adam

---

From: Travis Hassloch <[email-masked]>
Date: Mon, 29 Nov 2010 15:06:32 -0800

> Yep. It's a problem. Ultimately I don't think there's a technical

Actually, I see HSTS as dealing almost entirely with UI-level issues.

My programmatic clients don't type URLs into address bars, forget to add
https://, click through SSL warnings, etc.  What would it gain them?

BTW, the talk of web services and bots reminds me of elevator controllers:
During one period (1983--84) in the deliberations of ANSI X3J11 (the C
standardization committee) this was the canonical example of a really
stupid, memory-limited computation environment.  "You can't require
`printf(3)' to be part of the default runtime library --- what if you're
targeting an elevator controller?"  Elevator controllers became important
rhetorical weapons on both sides of several holy wars.

> designers and admins end up relying on them as a security property and

I recall reading Northcutt's NIDS book a while back, and seeing sections
stating that certain packets would never be seen because an RFC said that
clients MUST NOT generate them.

IMHO, there isn't a single "MUST" in an RFC that's reliable in that sense.
If it were impossible to do otherwise, it wouldn't need to be specified in
an RFC.  Relying upon RFCs to constrain bad actors is akin to saying your
bank doesn't need walls since theft is illegal.

That all having been said, the baby-duck model (impressioning on a pubkey
the first time you see it) causes big problems with active attackers the
first time, or when you have to update the cert - those are
indistinguishable from a MITM.  Knowing that the cert was updated is not
enough; you need an out-of-band channel to know that the new cert is the
right one.  That's what the key indirection in SSL is there for - in that
case, you only have to have an out-of-band update when a CA cert's pubkey is
changed.  If you're not worried about Mallory, you don't need HSTS.  If you
are, you need real key management.  IMHO.

Thanks!
-- 
Travis Hassloch
Flash Player Security Engineer

---

From: Adam Barth <[email-masked]>
Date: Mon, 29 Nov 2010 15:15:50 -0800

> https://, click through SSL warnings, etc.  What would it gain them?

Don't they?  What does --no-check-certificate do then?

http://www.gnu.org/software/wget/manual/html_node/HTTPS-_0028SSL_002fTLS_0029-Options.html

> are, you need real key management.  IMHO.

Unfortunately, the world isn't quite so black-and-white.  As a
practical matter, HSTS does improve security against Mallory.  For
example, now that I've visited PayPal once with this laptop, I'm
better off when I check my account balance in a coffee shop.

Adam

---

From: Travis Hassloch <[email-masked]>
Date: Mon, 29 Nov 2010 16:49:13 -0800

> http://www.gnu.org/software/wget/manual/html_node/HTTPS-_0028SSL_002fTLS_0029-

I meant "what would (HSTS) gain (a properly-designed programmatic client)"

The problem HSTS addresses seems to be user interaction and click-through
insecurity.  I would hope that its proponents are not trying to prevent
programmers from shooting themselves in the foot, if they try hard enough to
do so.  That is, as others have pointed out, an impossible task.

> better off when I check my account balance in a coffee shop.

I think you misparsed my sentence. I'm saying that if you're worried about
Mallory, then self-signed certs aren't really a strong defense.

Thanks!

---

From: Adam Barth <[email-masked]>
Date: Mon, 29 Nov 2010 17:08:07 -0800

> I meant "what would (HSTS) gain (a properly-designed programmatic client)"

Are you saying that wget isn't properly designed?  I'm not sure I
follow your point.

> do so.  That is, as others have pointed out, an impossible task.

I'm not sure there is a clear distinction between users and
programmers.  I write code, but I also use software.  When passing
--no-check-certificate to wget, am I a user or a programmer?

Adam

---

From: Travis Hassloch <[email-masked]>
Date: Mon, 29 Nov 2010 17:35:29 -0800

I'm pointing out that hsts does not seem to offer much to userless  
agents.

It helps to remember that Paypal eats fraud losses, unlike many other  
use cases where the user is protecting (or not) his own interests.   
Ross Anderson makes some arguments that this is a good thing, but it  
may seem big-brotheresque sometimes when they try to protect the  
session from the user themselves.

Sent from my iPhone

---

From: Marsh Ray <[email-masked]>
Date: Mon, 29 Nov 2010 20:25:34 -0600

> --no-check-certificate to wget, am I a user or a programmer?

You are intentionally being difficult and choosing the most ambiguous 
example rather than one representative of the false dichotomy presumed 
in the earlier discussion! I.e., you're being a programmer.

Wget is a user agent, since a user can invoke it from the command line. 
It's also used in shell scripts, so it's like an https client library too.

I think the point is that some apps which act as https clients are 
written by programmers and deployed by admins. These apps are not user 
agents in the conventional sense, they are more generally client 
applications which happen to be using https as a transport protocol. If 
they were correctly coded, they can be presumed to not bypass 
certificate warnings of their own initiative. Hopefully, the programmer 
and the admin can be relied upon in the security model in a way that the 
general user, as we have learned, can not.

This class of applications often has different characteristics than the 
classic user agent in its usage of https. There is great diversity 
within the set of non-UA https clients as well. What can we say about 
how they might interact with the changes proposed for HSTS?

- Marsh

---

From: Devdatta Akhawe <[email-masked]>
Date: Mon, 29 Nov 2010 18:32:13 -0800

> to be using https as a transport protocol. If they were correctly coded,
> they can be presumed to not bypass certificate warnings of their own
> initiative. Hopefully, the programmer and the admin can be relied upon in
> the security model in a way that the general user, as we have learned, can
> not.

I have been thinking of this while reading this discussion - and the
way I have been phrasing it in my mind is -
when does the decision to over-ride the ceritificate warning take place?

In the case of the browsers, it takes place when the user is trying to
get things done - at which point he will probably just
click on 'go away' (this is one of the reasons, in addition to being
conditioned to do this). This is the behavior that HSTS is trying to
protect against.

I think for User Agents for which you have to make the choice to
ignore certificate warnings at compile time or in the config file etc,
HSTS should not apply. In a way, this also works for a 'ignore HSTS'
setting in about:config for Firefox.

I am not sure if this makes sense to anyone else.

cheers
devdatta

> classic user agent in its usage of https. There is great diversity within
> the set of non-UA https clients as well. What can we say about how they
> might interact with the changes proposed for HSTS?
>
> - Marsh
>

---

From: Marsh Ray <[email-masked]>
Date: Mon, 29 Nov 2010 22:13:36 -0600

> I am not sure if this makes sense to anyone else.

Yes, I think you've got it.

A configuration choice ("accept this certificate for this site") that's 
clearly allowed by the security model paradoxically becomes an insecure 
thing to allow at the moment the user encounters the need to do it!

It's a user interaction designer's nightmare scenario really.

Consider the following scene playing out in office buildings worldwide:

"Hi! I'm your software and I have good news and bad news for you."

"The bad news: There's a problem. That thing you asked me to do, I just 
can't do it.

"But good news! I can fix that easily for you. But...

"Bad news! I won't fix it for you. I was told not to by my programmers. 
They said for me to tell you that this was for your own good. 'It 
wouldn't be secure' they said. For me to conveniently fix your problem 
right now would simply be an invitation for 'a man in the middle attack'.

"Look outside. Do you see a white van with ladders on it? A guy with a 
reel-to-reel tape recorder dressed as a telephone repairman? No?  Well, 
remain vigilant. They could show up at any time.

"Too bad. You know, if you had just asked me to install that certificate 
at any time _before_ you tried to pull up that web page, then that would 
have been secure and I would have certainly allowed it.

"At this point though, the only secure way you can access that site is 
for you to somehow go back in time and make it so that you'd never tried 
to open that web page in the first place.

"But you just had to click on that link, didn't you? Really it's the 
site admin's fault. Blame him, not me.

"Hey! What are you--

[Cut to shot of computer flying out of 10th floor office window]

- Marsh

---

From: Adam Barth <[email-masked]>
Date: Mon, 29 Nov 2010 20:34:21 -0800

On Mon, Nov 29, 2010 at 8:13 PM, Marsh Ray <[email-masked]> wrote:
> "Bad news! I won't fix it for you. I was told not to by my programmers. They
> said for me to tell you that this was for your own good. 'It wouldn't be
> secure' they said. For me to conveniently fix your problem right now would
> simply be an invitation for 'a man in the middle attack'.
>
> "Too bad. You know, if you had just asked me to install that certificate at
> any time _before_ you tried to pull up that web page, then that would have
> been secure and I would have certainly allowed it.
>
> "At this point though, the only secure way you can access that site is for
> you to somehow go back in time and make it so that you'd never tried to open
> that web page in the first place.
>
> "But you just had to click on that link, didn't you? Really it's the site
> admin's fault. Blame him, not me.
>
> "Hey! What are you--
>

In reality, these errors are extremely rare, several orders of
magnitude less common than the certificate errors we encounter today
because we require the user agent to receive the HSTS instruction over
a connection with a valid certificate first.  Instead of using the UI
you suppose above, we just show the same sort of UI we normally show
when we have a fatal network error, for example when the server
refuses the TCP connection.

Adam

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Tue, 30 Nov 2010 08:58:57 -0700

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Devdatta Akhawe
> 
> I have been thinking of this while reading this discussion - and the way I have
> been phrasing it in my mind is - when does the decision to over-ride the
> ceritificate warning take place?
> 
> In the case of the browsers, it takes place when the user is trying to get
> things done - at which point he will probably just click on 'go away' (this is one
> of the reasons, in addition to being conditioned to do this). This is the
> behavior that HSTS is trying to protect against.

In the case of programmatic clients, it is much easier to only offer HTTPS connections in the first place, and not have a listener on port-80.  It is generally only in the web-browser case that a user types in something that is a hostname, or a word, and expects the browser somehow to do the right thing, convert that via DNS suffix appending to a proper hostname, to tack a protocol/scheme onto it, and then make an HTTP connection.  In an HTTP library case, I think it is much more common to pass a full set of instructions to the client library of precisely what to do, and we avoid most of these problems.

- Andy

---

From: Marsh Ray <[email-masked]>
Date: Tue, 30 Nov 2010 10:34:14 -0600

On 11/29/2010 10:34 PM, Adam Barth wrote:
> On Mon, Nov 29, 2010 at 8:13 PM, Marsh Ray<[email-masked]>  wrote:
>>
> you suppose above,

To be clear: I wrote that with the the generic problem in mind - it 
wasn't meant to be specific to HSTS. I was describing how a user might 
perceive the problem that we might empathize a bit, not trying to 
accurately depict an actual UI.

> we just show the same sort of UI we normally show

So here's a scenario you've probably considered, but I'd be interested 
in how it would work out.

I was in a hotel a few weeks back and I plugged into the room ethernet.

I opened my web browser to the start page, about:blank. I pulled up a 
web page by typing "https://....". I think it was probably my bank's site.

I get a certificate mismatch error. Of course, I didn't accept the 
certificate.

Figuring what's going on, I try to open http://google.com/ instead. It 
comes back with a redirect to the hotel's captive portal where I have to 
enter some registration code or other.

So what would have happened if my bank had been using HSTS? Nothing 
different right? I went to https://my-bank-dot-com directly.

What if _also_ google.com had configured HSTS? Wouldn't I have gotten 
the same cert error there, too?

What if all the sites I remember the URLs for had configured HSTS? Would 
this hotel's network just be broken for me? (Arguably it's broken already.)

What if I gave in and accepted the cert error, then this heinous middle 
box presented the hotel chain's home page under somebody else's domain 
name, and the hotel admin just read about HSTS and turned it on?

What if Telco-del-Qwertystan accidentally routes 20% of all Internet 
traffic through their McMantec ThoughtPolice(TM) SSL intercepting 
firewall, which they conveniently equipped with their trusted root CA 
and this box proxies or constructs responses which turns on HSTS for one 
year. Maybe this firewall can even do this with plain http requests, 
too? All by accident, of course.

Or maybe somebody at some sub-sub-CA of a commonly trusted root 
accidentally trips on the way to the secure storage vault and hits the 
button on their phone that posts the private key to pastebin
http://www.google.com/search?q="begin+rsa+private+key"+site%3Apastebin.com
and somebody else makes a viral facebook app that has the helpful side 
effect of turning on HSTS for every non-ssl site anyone visits?

Or what if some TLD operator, who is also a trusted CA, decided it would 
be good for their certificate business if they pre-loaded HSTS on every 
not-yet-registered domain name via a wildcard DNS result?
http://en.wikipedia.org/wiki/Site_Finder

Or somebody gets a valid certificate signed for "*\0example.com" and...

Currently, https://www.amazon.com/ returns a redirect to the plain http: 
version. (For the record, I think that's not so great.) What if there's 
some query string which reflects back in the headers without perfect 
escaping? What if a disgruntled elf uses this to inject an HSTS 
header...and replicates it over a popular social networking site? During 
peak holiday e-shopping?!

It seems like before HSTS a CA-gone-bad could compromise https: sites 
via an active attack, or decrypt captured traffic if DHE were not in 
use. This capability would hopefully end soon after their tomfoolery was 
discovered by removing it from the trusted store or revoking it. With 
HSTS, however, it seems that the potential exists for a long-lasting DoS 
on sites which serve plain http.

- Marsh

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Tue, 30 Nov 2010 10:28:16 -0700

> Behalf Of Marsh Ray

Then this lousy architectural hack that middleboxes do to spoof traffic would break.  We need another standards compliant way for them to do this, rather than just hacking using the tools they have available.   My current pet-idea is a DHCP extension field that tells the client that it will need to authenticate, and where to go to do that.  Then the client can get that value from the DHCP server, and it has a well-established way to know how to get the user on the network.

> What if I gave in and accepted the cert error, then this heinous middle box
> presented the hotel chain's home page under somebody else's domain

Yep, that would be bad.  But, essentially, damned if you do, damned if you don't.  We got lots of complaints that HSTS completely eliminated a user's ability to choose to accept a self-signed cert.  We also want to prevent MiTM attacks.  We went with the TOFU approach because we don't currently have a reliable OOB bootstrapping method.  We're hoping that wider DNSSEC deployment gives us more options in that area.

> What if Telco-del-Qwertystan accidentally routes 20% of all Internet traffic
> through their McMantec ThoughtPolice(TM) SSL intercepting firewall, which
> they conveniently equipped with their trusted root CA and this box proxies
> or constructs responses which turns on HSTS for one year. Maybe this
> firewall can even do this with plain http requests, too? All by accident, of
> course.

Well, in this case a user will still get a certificate warning for every site they visit unless they install this CA as a root in their browser.  Accepting that cert for https://www.foo.com won't make the browser trust that cert for *, just for that one site.

> accidentally trips on the way to the secure storage vault and hits the button
> on their phone that posts the private key to pastebin

So, you want us to design a protocol that protects against all the things that can go wrong with a key compromise?  Really, or are you just throwing out science fiction here?

> Or what if some TLD operator, who is also a trusted CA, decided it would be
> good for their certificate business if they pre-loaded HSTS on every not-yet-
> registered domain name via a wildcard DNS result?

This isn't a technology/protocol issue, this is a policy issue, and it isn't going to be solved purely with technology.

> It seems like before HSTS a CA-gone-bad could compromise https: sites via
> an active attack, or decrypt captured traffic if DHE were not in use. This
> capability would hopefully end soon after their tomfoolery was discovered
> by removing it from the trusted store or revoking it. With HSTS, however, it
> seems that the potential exists for a long-lasting DoS on sites which serve
> plain http.

Just like a rogue ISP, DNS provider, etc. can publish really long TTL records for things.  I really don't know what you're proposing here to solve the problem we'd like to solve.  Are you saying we should give up on trying to solve it?

- Andy

---

From: Devdatta Akhawe <[email-masked]>
Date: Tue, 30 Nov 2010 10:19:18 -0800

>
> In the case of programmatic clients,

This is what I was trying to address in my email - instead of making a
distinction between programmatic clients and non programmatic clients
(where do you put wget ?), I was saying that we should make the
distinction based on 'when can the decision to overwrite cert wanings
take place?'  In the case of browsers, the current problem is that
this decision is made by the user when he wants to get things done,
which HSTS is rightly trying to solve.

even for programmatic clients, the decision to over ride cert errors
is taken by a human somewhere , probably via a config file or call
parameter.

-devdatta

---

From: Travis Hassloch <[email-masked]>
Date: Tue, 30 Nov 2010 10:53:49 -0800

> enter some registration code or other.

I was actually thinking the same thing last night and intending to ask this
very same question.  It's even worse if you've installed one of the
extensions that force you to the HTTPS link by default; I tried google.com
and a few others before finding a common site that didn't have rules in the
firefox extension.

> name...

I've honestly wondered, from time to time, whether these sorts of things
were breaking any laws.  It's at least misrepresentation; pretending
ownership of a domain name, possibly a trademark, and representing one's own
web content as belonging to someone else.

I saw a web site the other day where the provider had helpfully put up a
page saying the web site was experiencing technical difficulties.  However,
it wasn't so helpful to the mirroring scripts, which decided the site no
longer had so many gigabytes of information on it, and proceeded to erase
the local copy, and create a new copy, with new last-modified timestamps,
newer than the actual site.

I personally wouldn't mind too much if HSTS made such things simply stop
working, though would be concerned if HSTS made such things into an
inadvertent DoS tool.

Also, if the domain name changed hands, it might be unusable for some users
until/unless the new admin paid the "root CA tax" (since it prevents
self-signed, and those users would be unable to access a plain HTTP site to
obtain a non-canonical root CA cert).

Thanks!

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Tue, 30 Nov 2010 12:03:03 -0700

> Behalf Of Travis Hassloch

> ownership of a domain name, possibly a trademark, and representing one's
> own web content as belonging to someone else.

Most of them (middleboxes) just redirect to their URL, rather than hosting content on the intercepted domain. That said, Kaminsky found bugs in the ones that ISPs were using for typo-monetization that did allow XSS of the spoofed domain, which was a seriously scary situation...

IANAL, but reputable sources tell me that while these redirects may in fact be a violation of some sort, actually making a case of it wouldn't be easy, nor cheap, nor very likely to succeed.

- Andy

---

From: Marsh Ray <[email-masked]>
Date: Tue, 30 Nov 2010 15:10:39 -0600

On 11/30/2010 11:28 AM, Steingruebl, Andy wrote:
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Marsh Ray
>>
>>
>> What if all the sites I remember the URLs for had configured HSTS?
>> Would this hotel's network just be broken for me? (Arguably it's
>> broken already.)
>
> Then this lousy architectural hack that middleboxes do to spoof
> traffic would break.  We need another standards compliant way for
> them to do this, rather than just hacking using the tools they have
> available.   My current pet-idea is a DHCP extension field that tells
> the client that it will need to authenticate, and where to go to do
> that.  Then the client can get that value from the DHCP server, and
> it has a well-established way to know how to get the user on the
> network.

I think there is a 'set proxy' option in DHCP, though I don't know how 
many clients would follow it. Windows broadcasts around for "WPAD" to 
try to discover a proxy. Of course, spoofing responses either of these 
messages is usually enough to gain the attacker MitM capability against 
that computer for as long as he remains connected.

>> What if I gave in and accepted the cert error, then this heinous
>> middle box presented the hotel chain's home page under somebody
>> else's domain name, and the hotel admin just read about HSTS and
>> turned it on?
>
> Yep, that would be bad.  But, essentially, damned if you do, damned
> if you don't.

Option C?

>  We got lots of complaints that HSTS completely
> eliminated a user's ability to choose to accept a self-signed cert.

Uh, yeah, that's kind of the point.

> We also want to prevent MiTM attacks.  We went with the TOFU approach
> because we don't currently have a reliable OOB bootstrapping method.

Well the header is only accepted from a properly cert-authenticated 
server. That's way better than TOFU.

> We're hoping that wider DNSSEC deployment gives us more options in
> that area.

Almost like what you want is a distributed table. Perhaps you could just 
replicate something like a digest of the hostname with a signature by 
the server's cert.

> Well, in this case a user will still get a certificate warning for
> every site they visit unless they install this CA as a root in their

I'm using 'Qwertystan' as a placeholder for any number of trusted root 
CAs that come with my browser and OS.

> browser.  Accepting that cert for https://www.foo.com won't make the
> browser trust that cert for *, just for that one site.
>
>> and somebody else makes a viral facebook app that has the helpful
>> side effect of turning on HSTS for every non-ssl site anyone
>> visits?
>
> So, you want us to design a protocol that protects against all the
> things that can go wrong with a key compromise?

No, but we should try our very best to understand them.

>  Really, or are you
> just throwing out science fiction here?

I really don't know. The conclusion I've come to recently is that 
sometimes the most outlandish-sounding threats will eventually become 
real possibilities, if the fundamental technology will allow it. Imagine 
going back just 15 years and predicting the inevitability of Zeus and 
Stuxnet. You'd likely be considered a crank.

Actually, I think all of the things I mentioned have to some extent 
already happened, though not in such a worst-case combination. I have no 
hard evidence for the uncontrolled root CA key is

>> result? http://en.wikipedia.org/wiki/Site_Finder
>
> This isn't a technology/protocol issue, this is a policy issue, and
> it isn't going to be solved purely with technology.

Yeah fair enough. But since we're actively changing the technology, it 
seems like we're obligated to think about the policy implications at 
this point.

>> It seems like before HSTS a CA-gone-bad could compromise https:
>> sites via an active attack, or decrypt captured traffic if DHE were
>> not in use. This capability would hopefully end soon after their
>> tomfoolery was discovered by removing it from the trusted store or
>> revoking it. With HSTS, however, it seems that the potential exists
>> for a long-lasting DoS on sites which serve plain http.
>
> Just like a rogue ISP, DNS provider, etc. can publish really long TTL
> records for things.

Seems like a good analogy, but don't those tend to get cleared out with 
a reboot?

> I really don't know what you're proposing here
> to solve the problem we'd like to solve.  Are you saying we should
> give up on trying to solve it?

No, I'm just brainstorming and asking questions, intentionally without 
regard to whether or not it reflects well or poorly on any particular idea.

While it's true that a rogue CA can create all sorts of mischief, I am 
starting to think that HSTS may represent a categorical increase in the 
severity of certain attacks.

An attacker who can exploit a header injection via URL and cause the 
client to request an image from a chosen https URL can disable that 
client's ability to access the corresponding http site (and subdomains) 
for "max-max-age".

An attacker who can exploit a header injection via URL and cause the 
client to request an image from a chosen https URL can disable that 
client's ability to access the corresponding http site (and subdomains) 
for "max-max-age".

An attacker who can impersonate a legitimate https site to the browser 
can disable http access to that site and its subdomains. DoS on a scale 
never before seen could be possible if an attacker had access to a 
trusted root key or is able to obtain an overly-broad wildcard (e.g., 
*\0...). For example, a client could be made to request https://com/ and 
if the attacker could reply with an accepted cert, he could set HSTS on 
all .com websites, for max-max-age. This could be repeated with a few 
other TLDs, effectively removing the client's ability to connect to the 
non-https web. The target URL https://./ may need consideration as well.

An attacker who can cause the client to request any one url from an HSTS 
site and view the response can determine if the user had contact with 
that server at any time during the previous max-age. This allows 
external attackers to probe laptops and mobile devices for information 
about the internal corporate network.

A user who is willing to accept a self-signed certificate (perhaps they 
are anticipating it from their personal router or an unimportant 
website) may perhaps be tricked into accepting an overly-broad wildcard 
cert ("*" or "*.com") with their request redirected to a phony top-level 
domain. The browser may not faithfully show all the details of the 
requested host, or the user may not understand that the effects of 
accepting this cert could extend beyond the site he thought he'd requested.

The HSTS flag, particularly with the subdomains option, has the 
potential to spill over to unintended systems. Often many components of 
a system share an https client facility. For example, if microsoft.com 
(or their hosting provider) accidentally set HSTS with subdomains for a 
period of time, it could conceivably prevent machines from contacting 
update servers. I think the update process may rely on plain http for 
the initial connection.

Does HSTS have any interactions with non-transparent http proxies? 
Should a browser be willing to talk plain http with a proxy for which 
the dns name matches a known HSTS domain?

Just some thoughts.

- Marsh

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Tue, 30 Nov 2010 14:43:40 -0700

> Sent: Tuesday, November 30, 2010 1:11 PM
> To: Steingruebl, Andy
> Cc: Adam Barth; [email-masked]
> Subject: Re: [websec] Some questions about HSTS
> 
> I think there is a 'set proxy' option in DHCP, though I don't know how many
> clients would follow it. Windows broadcasts around for "WPAD" to try to
> discover a proxy. Of course, spoofing responses either of these messages is
> usually enough to gain the attacker MitM capability against that computer for
> as long as he remains connected.

Yeah, I didn't know how well this was supported.  And, even there, you end up relying on HTTP-407 for proxy authentication if you want to do this inline, and that mechanism can't use forms, etc.  So, you're still kind of hosed essentially if you go this route.

> I really don't know. The conclusion I've come to recently is that sometimes
> the most outlandish-sounding threats will eventually become real
> possibilities, if the fundamental technology will allow it. Imagine going back
> just 15 years and predicting the inevitability of Zeus and Stuxnet. You'd likely
> be considered a crank.

I agree with this, which is why HSTS in the first place.  We are still trying to measure how much malicious MiTM is happening in the real world.  We have existence proofs from real access points, etc. but we don't have percentage data, etc.  Hoping to get more of that.  But, given the number of weak access points out there, easily compromised via things like CSRF, its really a question of when, not if, these attacks happen at scale.

> An attacker who can exploit a header injection via URL and cause the client to
> request an image from a chosen https URL can disable that client's ability to
> access the corresponding http site (and subdomains) for "max-max-age".

Yep. In the same way that a site that is vulnerable to  XSS cannot protect itself against CSRF.  There are some layers here.  HSTS doesn't protect against malware on the client either, and it isn't designed to.
 
> An attacker who can cause the client to request any one url from an HSTS site
> and view the response can determine if the user had contact with that server
> at any time during the previous max-age. This allows external attackers to
> probe laptops and mobile devices for information about the internal
> corporate network.

I suppose, but again this kind of low-grade information leak isn't that valuable, and if the connection were HTTP you could tell by watching the size of responses whether the client had visited because it might have things cached.  

> Should a browser be willing to talk plain http with a proxy for which the dns
> name matches a known HSTS domain?

It uses a proxy as normal.  It doesn't start doing HSTS until after CONNECT goes through the proxy.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 01 Dec 2010 15:53:14 +0900

> that computer for as long as he remains connected.

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

Regards,   Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]