[Bug 27271] New: Normatively require https for all ancestor origins when requiring https at all

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27271

            Bug ID: 27271
           Summary: Normatively require https for all ancestor origins
                    when requiring https at all
           Product: HTML WG
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Encrypted Media Extensions
          Assignee: adrianba@microsoft.com
          Reporter: hsivonen@hsivonen.fi
        QA Contact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-media@w3.org

The current spec text suggest that "user agents MAY choose to only support the
EME APIs and/or specific Key Systems (i.e. based on privacy and security risks)
on secure origins". This formulation has the downside of imposing the cost of
TLS on MSE while failing to foil a MITM from injecting EME usage into http
origins. Specifically, with this formulation, a MITM gets to inject iframes
that load an https page from a legitimately MITM-controlled domain into http
pages. Furthermore, since the MITM also gets to transfer data between the http
page (into which the MITM inject additional JavaScript) and the MITM-controlled
https site, the MITM  can associate whatever distinctive identifiers exposed to
the MITM-controlled https site with the page that the iframe has been injected
into.

To address this problem, please require all the ancestor origins to be secure
origins when the EME API is being limited to secure origins.

(Start proposed spec text for a *normative* section)

When the User Agent is limiting the support of the APIs described in this
document or a specific Key System to secure origins, the secure origin
requirement MUST apply not only to the origin calling the APIs described in
this document but also to all the ancestor origins in the browsing context
chain up to and including the top-level browsing context.

Note: This ensures that a network attacker cannot work around the secure origin
restriction by injecting an iframe with a attacker-hosted https-origin document
into an http-origin victim page. Also, this makes it harder for a site to foil
the intended privacy properties of the secure origin restriction by exposing
EME messages to an insecure origin by using postMessage() to send data to an
insecure-origin parent browsing context.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 7 November 2014 12:20:45 UTC