[whatwg] whatwg Digest, Vol 82, Issue 10

[Glenn Maynard]

On Wed, Jan 5, 2011 at 6:54 PM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> It's not really irrevocable.  A MITM only has access to the info as
> long as he's conducting the MITM.  As soon as the attack ends, the
> attacker stops getting info.  Moreover, anyone who's intercepting your
> Internet traffic could probably make a good guess at your location
> anyway, such as by looking up your IP address or triangulating
> latency.  So I don't think that it's such a big deal if MITMs can
> compromise geolocation, relatively speaking.

MITM is just one attack, and the solution is the easiest to define
(SSL), even if there are practical issues that should be improved.

Javascript injection is a harder problem, for example: it isn't
prevented by SSL, can persist without maintenance (unlike an MITM
attack), can be introduced untracably and without any special network
access (you don't need to "get in the middle"), and so in practice are
much more common than MITM attacks.

(Let's not get too caught up in how serious a geolocation attack is;
it's just one example, anyway.  The main thing that makes it
particularly notable is that it's actually a live, deployed API.)


> * If your cert expires or you misconfigure the site something else
> goes wrong, all your users get scary error messages.  In some cases
> the browser will even refuse to let them proceed at all.  (Chrome does
> this for revoked certificates and I've run into it a couple of times.
> Of course, I wasn't submitting sensitive information to the site, so I
> just used another browser.)

It's bothered me for a long time that browsers treat self-signed
certificates as *less* secure than plaintext, which is nonsense.
Despite being vulnerable to MITM attacks, even an untrusted
certificate helps prevent passive sniffing attacks.  Browsers should
accept self-signed certificates and present them as an insecure
connection, as if they were simply HTTP, not show warnings.

As for revoked certificates, while they're a major red flag--they're a
category of certificate issues that *should* show large, scary
warnings--it's completely unacceptable for a browser to actually
*refuse* to allow the user to proceed.

By the way, another real-world issue with SSL is that it's
considerably more computationally expensive: handling encrypted
requests takes much more CPU, especially for high-bandwidth servers.
Not every service can afford to buy extra or more powerful servers to
handle this.

-- 
Glenn Maynard