On Wed, Jun 20, 2001 at 10:19:21AM -0600, Vernon Schryver wrote:
| > From: Adam Shostack <adam(_at_)homeport(_dot_)org>
| > To: Vernon Schryver <vjs(_at_)calcite(_dot_)rhyolite(_dot_)com>
| > Cc: ietf-openproxy(_at_)IMC(_dot_)ORG, ietf(_at_)ietf(_dot_)org
|
| > ...
| > Unfortunately, the become your own CA solution doesn't actually help
| > deal with the issue of man-in-the-middle attacks. The threat under
| > discussion is that there is a proxy modifying content; we'd like to
| > prevent that. If the server sends a key without reference to some
| > established authority, then the MITM may simply replace that key with
| > one of its own, or translate the http-over-SSL request into a
| > cleartext http request, or otherwise munge the session, because there
| > is no way for the browser to figure out if the self-signed key is the
| > one the server sent.
| >
| > (I find it unfortunate because often, become your own CA is a good
| > idea, and this is one of the few cases where its not.)
|
| That is what Verisign would like you to believe, but it is inaccurate
| in more than one way.
|
| In fact, becoming your own CA is most of a solution to man-in-the-middle
| attacks. In practice (e.g. assuming you are not under special attack by
| people who could and would also mount "back bag," TEMPEST, and other
| attacks against you and your systems), all that remains is to exchange
| certificates with operators of other SMTP servers and clients that you
| care about.
Yes. I made a point of saying "The threat under discussion is that
there is a proxy modifying content..." because this discussion started
with OPES. In that particular case, where random people might
approach your website, you want to send them content that is
authenticated, and there is no out-of-band channel, then you don't have a
way to send them a certificate reliably.
The CA service could add value against the OPES attacker by offering
that out-of-band channel. Of course, the CA needs to verify that it
offers certificates only to "authorized" entities, and the browser
needs to check that the cert matches the site you think you're
visiting. So theres not a lot of value there, but there is potential.
In the case of email with "servers you care about," the self-certified
key works fine; there is motivation to use an out-of-band channel such
as verifying the key at an IETF meeting, via a PGP wot, etc.
| A second problem with the Verisign sales--uh--information is that there
| are hassles in detecting STARTTLS verfy=NO or =FAIL in MUA's. It's not
| good enough to have to read Received: lines to check that a message that
| looks as if it came from the IETF's list was really from the IETF's SMTP
| client. This problem has nothing to do with whether you pay Verisign's
| ridiculous fees for almost nothing. However, for squashing the data
| muggers, this problem is not relevant.
Sure. But thats for the case where you have a well-known server.
Well known servers get much less benefit from CA services than do
random ones. I'm not asserting that a random server gets substantial
benefit from a CA service; only that a well known server gets even
less.
Adam
--
"It is seldom that liberty of any kind is lost all at once."
-Hume