[aklug] Re: Tor + Firefox

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

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

>
> 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.
>

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.

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.

>
> 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.
>

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.

- --
frigidcode.com
theologia.indicium.us
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPO1SkAAoJEI2DxlFxTtgdexYIALtGrdw2ax+blWjwv7xvqinv
KOY7tjZlxn2cGpFwWachXOQCdRpw4mkyORRxQxGtg4pAjnoRl8k/E5IxyDW+Ro4g
N4k4IyATrMijdbwQwIoicnzUBYwOerx/DZVJ1l7xK4djGswBP6D8TBkbcbjWef/p
hDPnd2un0I4XkTqKsJ+p0wYt1YOONljO+5FOi3W85YzYrhZOnjPmyJEDCyEHvQ60
3MRjwNxCNYFLk+bIKdKCyuqiA3l/R7wuLzvTn2sug1JNpViwdpCrgjlxY/KoHJmV
MUnLVALYNm47YgK5ERgFm9zatKTT87Se4Hm4kC1DfqvO6MyXic7xVKKISQKrT+A=
=eNuI
-----END PGP SIGNATURE-----
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Tue Feb 14 21:43:19 2012