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
