On 13/12/2017 22:40, Matthew Hardeman wrote:
On Tuesday, December 12, 2017 at 3:52:40 PM UTC-6, Ryan Sleevi wrote:
Yes. This is the foundation and limit of Web Security.
https://en.wikipedia.org/wiki/Same-origin_policy
This is what is programatically enforced. Anything else either requires new
technology to technically enforce it (such as a new scheme), or is
offloading the liability to the user.
The notion that a sub-resource load of a non-EV sort should downgrade the EV
display status of the page is very questionable.
I'm not sure we need namespace separation for EV versus non-EV subresouces.
The cause for this is simple:
It is the main page resource at the root of the document which causes each
sub-resource to be loaded.
There is a "curatorship", if you will, engaged by the site author. If there are
sub-resources loaded in, whether they are EV or not, it is the root page author's place to
"take responsibility" for the contents of the DV or EV validated sub-resources that they
cause to be loaded.
Frankly, I reduce third party origin resources to zero on web applications on
systems I design where those systems have strong security implications.
Of course, that strategy is probably not likely to be popular at Google, which
is, in a quite high percentage of instances, the target origin of all kinds of
sub-resources loaded in pages across the web.
If anyone takes the following comment seriously, this probably spawns an
entirely separate conversation: I regard an EV certificate as more of a
code-signing of a given webpage / website and of the sub-resources whether or
not same origin, as they descend from the root page load.
For clarity, I was not referring to the subresource problem. Only to
the following simpler but important cases:
1. Mid-event change of certificate for *the same* address (DNS name)
to a certificate that has any non-trivial differences from the
certificate used by the browser to render its address bar indicator.
This should be seen as a security-relevant connection failure and
cause the browser to stop before sending any request under that
weaker certificate. False alarms would normally only happen during
a certificate rollover or with inconsistently configured server farms.
2. POST (not GET) to a different address than the page address, where
that other address does not present an equally-strong or stronger
certificate naming the same entity.
This should result in security warnings similar to posting to a
http address.
Similar protections could be added (with less urgency) for switching to
a less secure encryption algorithm (based on the Browser's
classification of what is stronger/weaker/equivalent/incomparable).
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
