Hi, Yoav--
Ivan Ristic's new "Bulletproof SSL and TLS" covers "Cookie Manipulation
Attacks" quite nicely. As he explains well, a serious limitation with HTTP
cookies is that they do not carry their metadata when resent to the server,
so a secure cookie set by "secure.tools.ietf.org" is, upon receipt by the
server in a request's Cookie header, indistinguishable from a insecure
cookie of the same name set by "tools.ietf.org". The cookie does not convey
the origin from which it was set.
RFC6797 Section 14 notes that HSTS's includeSubdomains feature blocks a
similar problem (namely, an insecure cookie set by
http://sub.secure.tools.ietf.org could be set against its parent
secure.tools.ietf.org). However, because includeSubdomains only applies to
sub-domains, rather than parent-domains, this protection is insufficient to
address cookie injection attacks against a parent domain.
It's hard to argue that this limitation is a flaw in HSTS (because the
alternative would be to permit a subdomain to define a HSTS policy for its
parent). However, because it is a threat against a site that is otherwise
protected via HSTS, I would suggest that there should be implementation
guidance of the form: "Any page secured by HSTS that is at a
third-level-effective-domain (www.privatedomain.etld) or lower in the DNS
hierarchy should include a resource reference to the parent privatedomain
(e.g. https://privatedomain.etld/1x1.gif) such that the dereferencing of
that resource will provide the UA the opportunity to store a HSTS policy
that will protect the entire privatedomain tree."
-Eric
-----Original Message-----
From: Yoav Nir
Sent: Friday, August 8, 2014 4:16 PM
To: Eric Lawrence ; Barry Leiba
Cc: RFC Errata System ; Jeff Hodges ; Collin Jackson ; Adam Barth ; Pete
Resnick ; Tobias Gondrom ; [email protected]
Subject: Re: [Technical Errata Reported] RFC6797 (4075)
On Aug 8, 2014, at 10:54 PM, Barry Leiba <[email protected]> wrote:
I'm afraid I'm only a consumer of RFCs and thus I'm not sure I understand
the distinction here. To me, it seems that the RFC's threat model is
incomplete.
Perhaps it is, but the distinction is about whether an error was made
in writing the document, or whether there's a flaw in the protocol, an
issue that wasn't considered in the discussion, or the like.
The sentence you're addressing is entirely consistent with the rest of
Section 14.4, and doesn't look like "errata" to me. It's quite
possible that the working group blew it and should have thought about
things differently. It's possible that someone should write an update
to RFC 6797 to correct it, and that your input would be useful.
But you're asking the websec working group to consider an update, not
making an errata report, as I see it.
Does anyone from websec have a comment on this?
Hi Barry.
Reading this, it doesn’t look like an error in the document, but as an
attack that the group may not have considered, which HSTS may not protect.
If this is indeed valid, and if this had been caught in IETF last call or
IESG review, this would probably have been sent back to the working group to
complete.
Eric: I’m trying to understand the issue, so please see the below and tell
me if I understood it correctly.
Suppose we set up secure.tools.ietf.org and a sub-domain of tools.ietf.org
and set HSTS on that domain (but not on tools.ietf.org, which is available
in HTTP)
I browse http://tools.ietf.org. Because I’m not using HTTPS, an attacker
intercepts the connection and injects a cookie for all subdomain (Path=/;
Domain=tools.ietf.org).
My next connection to https://secure.tools.ietf.org will send this cookie.
Did I get this correctly?
So my first reaction was “No way. You can’t set a Secure cookie over an HTTP
connection, can you? Just like you can’t set HSTS over an HTTP connection.”
So I went to find where in RFC 6265 it says that. So of course it doesn’t.
Googling it shows that I’m not the first to wonder about that. In anyone has
some insight about this, I’d be glad to know. Is it just that cookies have
always worked like this, so we’re not changing it now?
Unless I’m missing something, this could be a real problem, and there are
several ways to mitigate it. Any of them requires a new document that either
replaces 6797 or updates it ( I can see this solved with a 2-page +
boilerplate document). But I don’t think an errata report is the way to go
on this.
Yoav
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
