[aklug] Re: Tor + Firefox

On Tue, 14 Feb 2012, Christopher Howard wrote:

> You're assumption that verifying origin of content is not important as
> long as you are only reading ("perusing") it is not a valid one. First
> of all, if a MITM were to occur (which is what would be happening if
> you accepted a self-signed certificate belonging to someone who did
> not actually control the domain with which you wanted to communicate)
> the attacker would be able insert malicious content (dangerous
> JavaScript, e.g.) or even completely replace the site.

I think you're over-thinking this. MITM attacks require one of three
things: 1) actively sitting in the routing path between the client
and the server, 2) able to perform DNS cache poisoning, or 3) already
have a presence on the client.

In the instance of #1, you've got a boat load of trouble, regardless,
but signed certificates from a trusted authority helps, but only as
far as you can trust your client software. When you look at things
that have happened in the past, like, say, ye ole embedded null in
the common name field, even that is not a guarantee. In the instance
that he's very near your primary gateway you've got bigger problems
than just being able to verify he's not spoofing gentoo. All told,
though, the number of people in any position to even try such an
attack is relatively small, hence the risk is relatively low.

#2 can also be mitigatedby CA signing, but the same caveats from #1
still apply. #2 is something you need to take into account since
it allows an attack from someone not in a position to otherwise
intercept your traffic. Because of that the number of people who could
perform these attacks is significantly larger. Luckily, the cure
is very simple to deploy: *never* use public DNS. Not your ISP, not
Google, *no one*. Deploy your own caching DNS server with a valid
root zone, and allow no one but your client access to it. That alone
makes you magnitudes harder to attack.

#3: you're screwed. Wipe the box, start over. More than likely
not an issue for you, though.

From my perspective, that makes a true MITM a smaller probability
than the likelihood of a CA compromise. Especially since the CA is
so much more of a high value target, and no large organization is
bereft of morons. We have ample examples of attacks being covered
up, sometimes for years. I don't believe for a moment that there
isn't something huge compromised already, but we won't find out till
much later, if at all...

End sum: if you can trust your DNS, and have no evidence #1 happening,
self-signed certificates for content that exposes none of *your*
sensitive information is a relatively safe bet. And it doesn't demand
unreasonable economic hardship on that poor web server operator you've
been hammering.

> Furthermore, the integrity of purely "informational" sites can often
> be quiet significant. For example, I have complained to gentoo.org for
> not providing HTTPS support for the documentation pages which give
> information regarding the installation and verification of their code
> signing keys (including the fingerprints). Similar things could be
> said for names, phone numbers, addresses, news, and so on.

In these examples DNS security is once again far more important.
What you're missing is that SSL authenticates the server you're talking
to, it does *nothing* to authenticate the *content* it's serving.
That's why you still need those signing keys for package signatures,
etc., regardless of whether the server they're served off of is SSL or
not.

> Obviously after you have decided to trust the self-signed cert, these
> matters are not a concern. But when you first arrive at a site with a
> self-signed cert, you must either go to some other measure to verify
> the validity of the cert, or you must blindly accept it and gamble on
> it not being a MITM. As a general rule, I am not willing to take the
> latter course.

Eh, see above. For most sites that have none of your SPI you're really
not gaining anything of value, and likely cordoning yourself off from
otherwise valuable information.

> How many actual invalid certificates have been released, compared to
> the total number of certificate issued? (Say, for the year.) I'm not
> saying the global CA system is 100% perfect, but if it is even
> 99.9999% reliable then it makes sense to me.

It's not about invalid certificates over time, it's about the magnitude
of risk once something bad happens. If Verisign's signing keys get
compromised, for instance, it's a huge section of the Internet that
you can't trust, period. If that's your primary/only factor for
determining trust, that is. Heck, hacking a resellers account on a
major CA site can cause damage, and it's already happened.

> And as I said, with browsers like Firefox, every time one of the
> hacking incidents occurs, it comes up on the mailing lists, often with
> a huge debate over whether the CA should be dropped from the default
> list. So, if you see that particular CA is getting hacked more than
> you like or implementing poor security practices, you are free to
> delete that CA's cert from your collection.

I'm not saying you're wrong, but I do think there's a rational
cost/benefit analysis to be made. For any site that has *your* SPI,
certainly, CA signing is one of many safety checks to be made. But
even then, I would be hard pressed to say it's the most important, and
it's definitely not the only check. But for all others, you're probably
inconveniencing yourself more than anything else.

         --Arthur Corliss
           Live Free or Die
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Tue, 14 Feb 2012 19:10:56 -0900 (AKST)