Re: [websec] of quoted-string header field param value syntax (was: Strict-Transport-Security syntax redux)
On 2012-01-14 01:24, =JeffH wrote: In terms of this question of whether the STS header field directive ABNF should be.. 1) directive = token [ = ( token | quoted-string ) ] ..or.. 2) directive = token [ = token ] ..I can see both sides of the argument. However, I've been thinking about it and grepping thru specs as well as firefox and chrome code, which has led me to think that from an overall (specification) consistency perspective, I'm leaning towards spec'g it with quoted-string in the ABNF (ie, as (1)). And has been pointed out in +1 the discussion, it is sort of a moot point because the STS header field does not at this time make use of the quoted-string production, nor do we have on the table any extension directives that would do so. It's not a moot point at all. If you don't spec it now, extensions will not ever be able to use quoted-string, because recipients parsing over those extensions will trip over them. In going through the FF and Chrome code, I note that both of their STS header field parsing methods appear to be special-case and AFAICT don't make use of other, more general HTTP header field parsing routines that are available in both implementations, and that are used to parse other HTTP response header fields. These latter more general HTTP header field parsing routines appear to be used for processing various of the other HTTP response and request header fields (and they appear to handle quoted-string). But it isn't clear why they aren't used for STS. It also isn't clear how uniformly these parsing routines are used for the panoply of HTTP header fields -- some other header fields appear to be special-cased as well (tho my c++ foo is wanting and the code is vast..). So yeah, it does seem messy. It's true what right now there isn't a lot of re-use of header field parsers. This is likely because of historic reasons; different header fields have different parsing quirks. But of course that's not an excuse to add unneeded special cases in the future. Example: just a few weeks ago we discussed the Prefer header field in the HTTPbis WG, and we have been able to make it parse exactly like Expect (after fixing Expect as well, see http://trac.tools.ietf.org/wg/httpbis/trac/ticket/327). Best regards, Julian ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #34: HSTS cache manipulation and misuse by server enabled by wildcard cert
Interesting.
But I don't see how subdomains help. If I have a website called
charcount-5.example.com, and I use a wildcard *.example.com certificate, the
HSTS entry is still written for charcount-5.example.com. Adding subdomains
would affect *.charcount-5.example.com, not 0-H.example.com.
I wouldn't want to force the includeSubdomains, as there may be valid reasons
to have a subdomain of example.com that is HTTP, whereas the decision on buying
a wildcard certificate is a matter of cost and convenience.
Yoav
On Jan 15, 2012, at 4:52 AM, websec issue tracker wrote:
#34: HSTS cache manipulation and misuse by server enabled by wildcard cert
See..
The Double-Edged Sword of HSTS Persistence and Privacy -- by Mikhail
Davidov
http://haxsys.net/2011/04/the-double-edged-sword-of-hsts-persistence-and-
privacy/
summary:
This technique allows a web app on one domain to surreptitiously send a
message to another web app on another domain via manipulation of the HSTS
cache...
If server wields a wildcard cert, eg for *.example.com, then example.com
can create any number of subdomains of example.com, with any subdomain
name, and then direct user agents to fetch resources from these
subdomains. If HSTS Policy is returned for each of these subdomains, and
includeSubDomains is not used, then any number of entries will be created
in in the user agent's HSTS store. E.g., an web page like the below would
accomplish this..
[img]https://charcount-5.example.com/setbit.png[/img] -- this
stores the char count of the msg
[img]https://0-H.example.com/setbit.png[/img]
[img]https://1-E.example.com/setbit.png[/img]
[img]https://2-L.example.com/setbit.png[/img]
[img]https://3-L.example.com/setbit.png[/img]
[img]https://4-O.example.com/setbit.png[/img]
These entries can be read back by some other web application under some
other domain name by causing the user agent to send HTTP requests to
example.com in order to brute-force the character count subdomain name --
the server responds whether the name is available over just http -- which
means it is a miss, or over HTTPS, which is a hit..
http://charcount-1.trackingexampledomain.com/getbit.png [ Server: HTTP ]
http://charcount-2.trackingexampledomain.com/getbit.png [ Server: HTTP ]
http://charcount-3.trackingexampledomain.com/getbit.png [ Server: HTTP ]
http://charcount-4.trackingexampledomain.com/getbit.png [ Server: HTTP ]
http://charcount-5.trackingexampledomain.com/getbit.png [ Server: HTTPS!
] -- msg char count is 5
Then the web app can brute force each character of the message in a
similar fashion.
the original message-sending domain web app can clear the cached message
by causing the user agent to re-request resources from the same dubdomains
and returning a HSTS header for each with max-age=0.
For a resolution, Mikhail suggests..
My proposal is to amend the draft to force the includeSubDomains flag on
wildcard certificates. This would limit them to only one entry in the
browsers HSTS database and make the technique above prohibitively
expensive to non-CA owners as a separate signed SSL certificate would be
needed for every bit of information stored and limit encoding options.
--
-+-
Reporter: | Owner: draft-ietf-websec-strict-transport-
jeff.hodges@… | sec@…
Type: defect | Status: new
Priority: major| Milestone:
Component: strict- |Version:
transport-sec | Keywords:
Severity: Active WG|
Document |
-+-
Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/34
websec http://tools.ietf.org/websec/
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec
IƧ��[�(^rC�{S�֥I�.�+r�^��
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec
Re: [websec] #34: HSTS cache manipulation and misuse by server enabled by wildcard cert
Why not just postMessage of the HTML form element? If you want be more sneaky about it, you can just the HTTP cache. Anyway, web sites are allowed to send messages to each other. Adam On Sat, Jan 14, 2012 at 6:52 PM, websec issue tracker trac+web...@trac.tools.ietf.org wrote: #34: HSTS cache manipulation and misuse by server enabled by wildcard cert See.. The Double-Edged Sword of HSTS Persistence and Privacy -- by Mikhail Davidov http://haxsys.net/2011/04/the-double-edged-sword-of-hsts-persistence-and- privacy/ summary: This technique allows a web app on one domain to surreptitiously send a message to another web app on another domain via manipulation of the HSTS cache... If server wields a wildcard cert, eg for *.example.com, then example.com can create any number of subdomains of example.com, with any subdomain name, and then direct user agents to fetch resources from these subdomains. If HSTS Policy is returned for each of these subdomains, and includeSubDomains is not used, then any number of entries will be created in in the user agent's HSTS store. E.g., an web page like the below would accomplish this.. [img]https://charcount-5.example.com/setbit.png[/img] -- this stores the char count of the msg [img]https://0-H.example.com/setbit.png[/img] [img]https://1-E.example.com/setbit.png[/img] [img]https://2-L.example.com/setbit.png[/img] [img]https://3-L.example.com/setbit.png[/img] [img]https://4-O.example.com/setbit.png[/img] These entries can be read back by some other web application under some other domain name by causing the user agent to send HTTP requests to example.com in order to brute-force the character count subdomain name -- the server responds whether the name is available over just http -- which means it is a miss, or over HTTPS, which is a hit.. http://charcount-1.trackingexampledomain.com/getbit.png [ Server: HTTP ] http://charcount-2.trackingexampledomain.com/getbit.png [ Server: HTTP ] http://charcount-3.trackingexampledomain.com/getbit.png [ Server: HTTP ] http://charcount-4.trackingexampledomain.com/getbit.png [ Server: HTTP ] http://charcount-5.trackingexampledomain.com/getbit.png [ Server: HTTPS! ] -- msg char count is 5 Then the web app can brute force each character of the message in a similar fashion. the original message-sending domain web app can clear the cached message by causing the user agent to re-request resources from the same dubdomains and returning a HSTS header for each with max-age=0. For a resolution, Mikhail suggests.. My proposal is to amend the draft to force the includeSubDomains flag on wildcard certificates. This would limit them to only one entry in the browsers HSTS database and make the technique above prohibitively expensive to non-CA owners as a separate signed SSL certificate would be needed for every bit of information stored and limit encoding options. -- -+- Reporter: | Owner: draft-ietf-websec-strict-transport- jeff.hodges@… | sec@… Type: defect | Status: new Priority: major | Milestone: Component: strict- | Version: transport-sec | Keywords: Severity: Active WG | Document | -+- Ticket URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/34 websec http://tools.ietf.org/websec/ ___ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
