To repeat, the positions are entrenched, and it isn't worth repeating
the debate. The main point to understand is that:
*the browsers have to block mixed content*
and the thread Subject is spot on.
(fwiw, some easy rebuttal below, and why.)
iang
On 15/08/13 12:27 PM, Gervase Markham wrote:
On 13/08/13 18:11, ianG wrote:
Badly. Riddled with bad, false and self-serving assumptions. here's
just one:
"Before we begin, we must understand that
Security = Encryption * Authentication."
Wrong. That happens to be the SSLv2 security offering, aka C.I.A. for
confidentiality, integrity, authenticity. That model has only the
vaguest relationship to the security of the users. Even the inventors
of SSLv2 don't hold onto that position with any seriousness any more.
[Perhaps you don't mean to, but you do have a habit of writing your
points in a way which takes 3x as much effort to parse and understand as
other people's, often due to your assuming too much shared knowledge.
This provides a disincentive to engage with your argument.]
Without citations and further elaboration, there is nothing above that
can be interacted with.
Perhaps you don't realise or recall, but you and I have been sparring
this way for many years now. You will typically find ways to attack and
downgrade the words [0]. This prepares the ground to ignore or
otherwise clamp down on the discussion. Mozilla as a consistent
practice will not open up or discuss security models, and your above
deflection follows this practice.
Here is why *the browsers have to move to block mixed content* :
Even the browsers don't implement that model, because they famously do
not state to the user who is authenticating what. Substitutions without
notice are part of the architecture.
Yep. And that's just fine. Users do not want to figure out which of 60
CAs they trust; they'd rather delegate that job to Mozilla. And we take
it seriously. If we say FooCA is OK to do authentication, then (for our
users) it's OK - and if they turn out not to be OK, we give them the boot.
Right, browser vendors are in a trap of their own making. The browsers
offer a binary security feature. It's either all ON or all OFF.
We now have a decade of evidence that the model of all ON or all OFF has
poor performance [1] against attackers. Which leads to the browser
vendors having to choose: either replace or fix the model, or make it
ON but harder ON.
They chose ON-harder.
Which means *the browsers have to move to block mixed content* . Mixed
content has no place in an on-off world.
This doesn't seem to me to be an argument against "Security = Encryption
* Authentication".
The point of that phrase is "Zero encryption => zero security", "zero
authentication of the endpoint => zero security".
I know, these are all familiar and understandable arguments. Logical,
even mathematical.
Just wrong, because you started with false assumptions.
Zero encryption does not mean zero security [2], not even approximately.
Zero authentication does not mean zero security [3], again not even closely.
As the assumptions are hopelessly irreparably flawed, the rest of the
article is a fail. Until we can deal with assumptions properly, it
isn't even worth describing the hows & whys that your article leads to
false results.
iang
[0] E.g., I write badly (ad hominem) in some sense, and, I do not cite
evidence (not worthy of attention).
[1] I mark the start of serious phishing of browser users at 2003.
[2] Consider dual channel authentication, shared one use passwords,
emailed password recovery tokens, hashing, etc. This list is also very
long.
[3] Consider: the SSH world has secured its servers for nearly two
decades now without users bothering to authenticate first time. TOFU
secures. Skype worked so well without knowing who it was dealing with
(!) for so long, the NSA had to beg them to weaken their protocols. For
more flagrant and complicated example, authentication of dissidents
leads to capture, torture, death. A.k.a., lower security.
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
