[whatwg] fixing the authentication problem

[Kristof Zelechovski]

Sending any data, including, log-in data, through an unencrypted connection
is greeted by a warning dialogue box in Internet Explorer.  A similar
precaution is taken when the server certificate is not trusted.  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.

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?
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Eduard Pascual
Sent: Tuesday, October 21, 2008 4:37 PM
To: Aaron Swartz; whatwg at lists.whatwg.org
Subject: Re: [whatwg] fixing the authentication problem

On Tue, Oct 21, 2008 at 2:16 PM, Aaron Swartz <me at aaronsw.com> wrote:
>
> Some major web services redirect the user to an SSL server for
> the login transaction, but SSL is too expensive for the vast majority
> of services.
The issue is not SSL being expensive: the only expensive part is
having a third party (the Certification Authority) to endorse your SSL
keys, but for basic authentication self-signed certificates *should*
be enough: when a user logs into a forum, for example, s/he shouldn't
care about example.com being actually owned by Example Inc.; but just
about the fact that the username and password will only be readable by
example.com, regardless of who is behind example.com.
The actual issue is that current UAs are over-paranoid about
self-signed certificates: of course, a CA-endorsed certificate is
safer than a self-signed one (specially for transactions involving
money); but a self-signed certificate is still safer than no
certificate enough (and definitely safe enough for login purposes):
browsers, however, treat a self-signed certificate as almost a
guarantee of fraud, while sending login data through unencrypted
connections doesn't even raise an eyebrow: this behavior is definitely
wrong, and this wrong behavior is the actual issue that should be
dealt with (I don't really know if it should fall within HTML5's scope
to deal with this, probably it doesn't). In essence, if UAs *lie* to
the user about security (treating "cheap" self-signed certificates for
login as fraud attempts; but unsecure communications as a non-issue),
then what's the point at all about security?