[whatwg] fixing the authentication problem

[WeBMartians]

Somewhere, is there a definition of "trust" in this context? I say that in all seriousness; it's not a facetious remark. I feel that
it might be useful. 

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Eduard Pascual
Sent: Tuesday, 2008 October 21 19:40
To: Kristof Zelechovski; Andy Lyttle; whatwg at lists.whatwg.org
Subject: Re: [whatwg] fixing the authentication problem

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.