On Wed, Dec 13, 2017 at 1:19 PM, Jakob Bohm via dev-security-policy < [email protected]> wrote: > > I would be sorely disappointed
Prepare to be sorely disappointed > and consider it a security bug It is not a bug. It is not part of the security boundary of the Web, thus WontFix/WorkingAsIntended. Feature Requests to change this behaviour will be closed, with reference to "Beware Finer Grained Origins", which explains the flaws in that. > if a > browser shows one validated certificate then submits a posted form to a > connection with a substantially different certificate. This is what browsers do. As referenced earlier in the discussion about Same Origin Policy, and more generally, the security notion of origins - as these two certificates do not constitute distinct origins, they are the same in privilege, capability, and trust. That is how the Web works. This has been mentioned several times, but I'm greatly appreciative for Nick spelling it out, as it does seem some degree of progress has been made in arriving at common talking points. > There may be a > (very short) list of permitted variations for cases such as server farms > with separate private keys per server. But any real change of > certificate mid-transaction should be blocked the same way cross-domain > posting is usually blocked. > They are not blocked. This is also covered in the SOP and how the web works. > Checking for certificate equality is an easy programmatic task, deciding > if a real world entity is trustworthy is not. Unquestionably. Yet using certificates to do so is both technically and procedurally deficient. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
