[aklug] Re: Tor + Firefox

On Tue, 14 Feb 2012, Christopher Howard wrote:

> Upon further consideration, I must concede a certain degree to your
> arguments, particularly your economic ones: I can see how the current
> CA system is rather lame, in that even small time operators have to
> pay large amounts of money for the privilege of having a signed cert
> that is recognized as valid by the browsers, a problem that can get
> quite expensive if he happens to own multiple domains. Doubtlessly
> this has done a great deal to slow the adoption of SSL as whole, which
> is very unfortunate. Obviously, it would be better for 100% of the Web
> to be using SSL and self-signed certificates than only 10% of the Web
> using SSL with CA-signed certificates.
>
> Having granted that, I will continue to hold (and I think you would
> agree) that self-signed certificates are still not the best answer to
> the problem. It is unfortunate that we don't have a better system in
> place. One idea that I like is to replace the commercial CAs with
> non-profit organizations, who would provide the service for free or at
> the smallest expense possible. And who wouldn't have any motivation to
> cut corners on security. Another option would be a Web of trust, like PGP.

Well, they have tried (see: cacert.org). That said, I tend to think that
the ultimate solution will be DNSSEC-based, with verification keys being
delivered via some kind of special resource record. Which will be
nice, since it will put the CAs out of business (for the most part),
but will definitely require a lot more maintenance and infrastructure
to keep the whole chain of trust intact.

> Purely for the sake of accuracy, however, I do want to address a few
> points you made:

Fair enough.

> You state that, "in the instance #1, you've got a boat load of
> trouble". However, that's not true if you are using SSL, and you know
> you can trust the certificate of the person you are communicating
> with. When SSL is active, it is impossible for the MITM to modify or
> take over the connection, because any attempts to do so would kill the
> connection completely (due to the way SSL is designed). And even that
> "attack" would be pointless because it would only reveal that the
> attacker exists. The whole point of SSL is dealing with the reality
> that you can't trust the nodes between you and the host you are trying
> to communicate with.

I think you missed my point. You're right only as far as this specific
TCP traffic is concerned. What I was trying to point out is that if you
can't trust the router (or operators) handling the bulk of your traffic
across all protocols, your attack surface is freaking huge. Protecting
your SSL traffic is going to be the least of your problems. In terms
of relative problem scale, SSL isn't going to make you rest any easier.
At least, it shouldn't.

> As to matter of not be able to trust your client software, it is
> pointless to even bring it up because that is a problem no matter what
> you are doing.

Yes and no. Yes, it's a problem, period. No, it's not pointless to
bring it up. For a software stack that's been repeatedly attacked
with some success it bears asking the question as to how much you can
rely upon it in the first place. Are you betting that all the major
problems are already shaken out? Are you really confident that you're
as safe, or safer than before the last few vulnerabilities? If not,
you'd better look at the bigger picture and not rely too heavily on
only SSL for verification. Heck, it's not just the core SSL libraries,
it's the software linked to it. Some of the browser issues haven't
been entirely the fault of SSL.

In short, SSL is a valuable tool in the tool box, but don't let it
lull you into a false sense of security.

> There could be some ambiguity in what you mean here by "authenticate",
> but on a technical level SSL *definitely* does authenticate the
> content as well as the connection. Each SSL record sent receives an
> cryptographically-hashed MAC (HMAC) that ensures both the integrity
> and the authenticity of the plain-text message in the record. So it is
> impossible for the attacker to modify the message in any way without
> alerting the receiving party to the tampering attempt.
>
> But if what you meant was that SSL does not provide /application
> layer/ authentication, yes, that is obviously correct. Although, HTTPS
> /could/ serve as an effective substitute for code signing, if you were
> certain that the person writing the code was the same person who
> controlled the SSL certificate, and you always downloaded the code
> from his Web site instead of getting it from a third-party repository.

Heh, are we going to cryptographically sign cryptographic signatures?
My point is that serving up public keys or package signatures for end
user verification is not made any safer by putting them on a SSL web
server than on a regular HTTP server. The only possible benefit would
be if you're under MITM attack scenario #1. Again, not only would that
be the least of your problems, but even then the attacker would have to
make sure that you're not only downloading packages and signatures, but
you're also getting a certificate from him for verification. Which is
not typically how that's done. There's a chain of trust, you have to
take that leap of faith only with your first contact (downloading that
first distro image, for instance). After that, any certificate updates
would be delivered via signed packages verified with the previous
certificate. Just like any software updates.

In short, the attacker would have to own you from the very beginning in
order to make that work. Not to belabor the point, but, if *that* were
the case...

         --Arthur Corliss
           Live Free or Die
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Wed Feb 15 00:14:19 2012