On 05/10/2009 01:24, Peter Djalaliev wrote:
It is our standard security nightmare. Side A thinks it is Side B's
problem. Side B thinks it is Side A's problem. In the meantime the
user doesn't use the tech because it doesn't work, and the sides are too
busy arguing to solve the problem. So zero security is delivered.
In this case, it is always the part closest to the user that has to do
the mostest. Maybe it's not a browser-tech or client-side-TLS issue,
but *it is a browser issue*.
It is the browder's responsibility to present an SSL error to the user
in an accessible way.
OK! Well, I agree with that.
However, browsers usually make certificates
visible to users and, therefore, it is assumed that users understand
certificates and basic certificate-related issues.
That's a fascinating leap there! "Visibility means understanding..."
There is ongoing
research on this topic and I am not sure if anybody can state with
confidence whether this assumption is correct and whether Firefox's
interface is clear enough to understand.
Oh, then this is something to fix! I can :) No, and no.
I can prove it in about 5 mails. Ask on this group what a certificate
means. If this group cannot agree what a certificate means, what hope
do the 1 billion browser users have?
Skipping aside all that. Browsers *do not* display "certificates and
certificate-related issues" when it comes to landing on a
client-cert-demanding SSL website.
They should.
PS: Also, it is standard security doctrine in many places that when
something isn't quite right that no information is returned. Something
to do with security advice of not being an oracle.
On the contrary, systems that fail silently can be both frustrating
(to the user) and very harmful (if the user assumes that the lack of
error means the success of a transaction). If no information is
returned, it is still unclear whether the transaction should succeed
or fail.
Oh, I don't disagree with that. I was just pointing out one more
barrier to getting that info to the users. There are whole communities
out there that believe different things, opposing things, to what is
believed here.
there are somewhat two schools of thought here: be precise in what you
send, be flexible in what you receive. Return comprehensive info. I
think this is a sort of early general net idea, from the days when there
was no distinction between user & developer.
Then there is a *security variant* of the above: be precise in what you
send, be precise in what you accept. Don't reveal any information, and
it can only work if it is precise. I think this more or less tracked
back to DJB. This is a sort of retro-response to schlock protocols from
the first mode discovering security failures.
The problem of course is that neither of these modes are suitable for
this topic because of the early design assumptions in the protocol (some
might say early mistakes...).
iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
