I think we've already been over much of this material.
Yes, SSL is being used for a tiny percentage of total traffic.
So what? This is not a measure of SSL's success. It is not a
measure of the "security" of the total user base of the web.
Most of the info that travels the net needs no "protection". Its
value is SO LITTLE that no-one would spend a penny to collect it.
We shouldn't be concerned that that info is not encrypted.
Most users have a pretty good idea of what they want protected, and
what information they have that needs protection. They don't care
about the lock when they go read the daily news, or the daily porn
(:-), but when they go to their bank, or pay bills online, they want
protection. They want to know that they're sharing that info only
with the bank, or the specific party to whom they've previously
decided to entrust that information. Some of them would also like
protection of confidential email, but most do not even realize that
such capabilities exist.
The measure of crypto success is what percentage of the time they
get protection for that traffic that they want protected. That
protection means more than encryption. It means assuring that the
encrypted traffic ends up in the hands of the right (authenticated)
party at the other end, the one to whom they've chosen to entrust
their data.
So, the objective here is NOT to drive the percentage of encrypted
traffic to 100%. It is to ensure that the data worth protecting
(as judged by the holders of that data) is protected, that is, is
communicated only between the user and the chosen and authenticated
remote party.
Encryption without authentication is worthless. It's false security.
Getting everyone to use SSL, without meaningful authentication of
at least one of the peers, is worthless.
If CPUs were free, and certs were free (due to absense of costly
identity verification), and all http servers became https servers,
(but with no greater assurances of the peer's identity than http gives
today) web users would have no more security than they have today, and
probably less.
The lock would then be truly meaningless. It would be closed all the
time, and users would have NO reason to trust their browser's connection
with their bank any more than its connection with any criminal enterprise.
The lock has to sometimes appear unlocked in order for there to be any
value to it ever appering locked. Strong authentication remains
crucial to the encryption having any protective value.
The cost of certs is the BIG major drawback to the deployment of
SSL, right? In the 8 years I've worked on SSL, that has never been
the finding of any of the market research firms that periodically
examine questions like that.
SSL continues to be unpopular in large part due to the cost of the
additional "iron" needed to do it. https servers do only a fraction
of the pages/second that http servers do.
At one time, it was considered "common knowledge" among IT types that
an https server did 1/7 of the throughput of a comparable http server,
which meant that it took 7 times as much hardware to accomplish the
same throughput. THAT's the big cost of SSL, not the cost of certs.
Today, that fraction may be a little closer to 1/1, e.g. say 1/5 or
1/4, but it still means that SSL is a large server cost multiplier.
Free certs will hardly help that.
It is unclear who Mozilla serves. [...] Who is the constituency?
To my mind, Mozilla serves two constituencies: users
and developers. It does not serve CAs. Nor auditing firms.
It should be users, period. And mozilla's security components should
serve to maximize users' security, not developer convenience, nor web
server admin convenience, nor even USER convenience, when that user
convenience brings about the detriment of the user's security.
A security developer who chooses developer convenience over user
security is probably guilty of malfeasence. And so is a security
developer who chooses the user's immediate gratification over the
user's own security. A security developer who chooses the user's
security over the user's instant gratification ought not be accused
of serving a consitituency of developers.
Users look to the developers to give them improved security for the
types of transactions where they (users) want security. But very often
the users have no real idea which practices improve security and which
destroy it. Hence the phenomenon of users clicking through all the
"warning dialogs" produced by the SSL/security code when insecure
behavior is detected. When developing for such circumstances, the
developer is faced with the choice of developing for the user's
immediate convenience, versus the user's security. Allowing the user
to override every security warning for every insecure event may give
the user immediate gratification, but it undermines the whole premise
of the SSL code, to provide security. One might ask, why bother to
have SSL if every time it detects insecure operation, it is overridden?
Similarly, allowing the browser to honor certs from CAs that do not
take adequate (or ANY) measures to ensure the identity of the parties
to whom they issue certificates may provide immediate user gratification,
but does not ultimately lead to user security.
So, the challenge ahead is to decide what criteria are to be used to
determine whether or not a CA takes adequate measures.
_______________________________________________
mozilla-crypto mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-crypto
