[whatwg] fixing the authentication problem

[Kristof Zelechovski]

Internet Explorer will continue to display warnings about unencrypted
submissions until you explicitly instruct it not to.  I find this feature
useful per se, it works as "Do you really want to submit this information?"
Sometimes I do not, e.g. when I press something accidentally, and it allows
me to back off.  This is the default setting.
Unencrypted connections are safer because they do not give a false
impression of security.  The browser says that the submission is unsafe
unless the user is heedless enough to disable the warning.  The warning can
be disabled for backwards compatibility, so that the browser can behave like
when there was no secure HTTP at all.  On the other hand, there are no
legacy considerations regarding invalid certificates.
In the case of a self-signed certificate, the data as encrypted can be read
only by the receiving server; but nothing prohibits the server from abusing
your data, including forwarding the information unencrypted.  This is a
false sense of security.
"<Evil.org> poses as <blog.com>" means that it presents a site identical to
<blog.com>, which may also be in the domain of <blog.com>.
I did not try to address the original suggestion.  I only wanted to justify
the assumption that compromised encryption is more dangerous than no
encryption (think of Aenigma).
Chris
-----Original Message-----
From: Eduard Pascual [mailto:herenvardo at gmail.com] 
Sent: Wednesday, October 22, 2008 1:40 AM
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.