[whatwg] fixing the authentication problem

[Eduard Pascual]

On Tue, Oct 21, 2008 at 4:35 PM, Kristof Zelechovski
<giecrilj at stegny.2a.pl> wrote:
> Sending any data, including, log-in data, through an unencrypted connection
> is greeted by a warning dialogue box in Internet Explorer.
Only the first time. IIRC, the "don't display this again" checkbox is
checked by default.

> A similar precaution is taken when the server certificate is not trusted.
Not similar at all: for unencrypted connections, you have the "don't
bother me again" option, in the form of an obvious checkbox; while
with self-signed certificates you are "warned" continuously; with the
only option to "install" the certificate on your system to trust it
(which is a non-trivial task; out of the reach for most average users;
still annoying even for web professionals; and, to top it up, you need
to do it on a site-by-site basis).
It doesn't make any sense for UAs to treat unencrypted connections as
safer than (some) encrypted ones: that's simply wrong.

> The risk of using an invalid certificate is bigger than not using any because
> your level of trust is bigger while you are equally unprotected.
That's, simply put, not true. The "level of trust" doesn't actually
depend (for average users) on the certificate at all, but on what the
browser says about it.
The level of protection, instead, is independent from the user, and
it's not the same for each case:
On an unencrypted connection, everyone could read the data being sent.
This is no protection at all.
On a connection encrypted with a self-signed certificate, the user can
rest assured that the data is only readable by the server, regardless
of who is actually behind that server. There is some protection here,
even if it's not the most possible.
On an encrypted connection with a CA-signed cert, the user has the
protection from encryption (only the server will be able to read the
data), plus the guarantee that the CA has taken care to verify that
the entity in charge of that server is who it claims to be.

> It is not enough to make sure that your credentials do not unintentionally
> leave <example.com>.
> Consider the following scenario:
> 1. You want to update your blog at <blog.com>
> 2. <Evil.org> poses as <blog.com> by phishing or DNS poisoning.
> 3. You log in to <evil.org> using your credentials of <blog.com>.
> 4. The bad guys at <evil.org> use your credentials to post an entry at
> <blog.com> that you are going to deploy a dirty bomb in NYC.
> 5. You travel to the USA and you end up in Guantanamo.
> Nice, eh?
Although I'm not sure what do you mean by "<Evil.org> poses as
<blog.com>", I see no point in Aaron's original suggestion that would
deal with such a case.

In summary, besides UAs' paranoia, I can't see any case where the
suggested feature would provide anything self-signed certificates
don't already provide. And since it involves using public-key
encryption, I don't see any reason why UAs would treat the encryption
keys differently from current SSL certificates.

On Tue, Oct 21, 2008 at 6:08 PM, Andy Lyttle <whatwg at phroggy.com> wrote:
> 4. The need for a dedicated IP address, instead of using name-based virtual
> hosts.
>
> That and #1 are the reasons I don't use it more.
#4 is, again, a cost, but not an expensive one: most of the hosts I
know of offer dedicated IP for a fee that's just a fraction of the
actual hosting price.
And, about #1, I just read my points about self-signed certificates in
this and my previous mail.