> > While this is true, keep in mind that there is more to mounting
> > a successful cryptographic attack than adding root keys and fake
> > certificates. It is also necessary to intercept the messages which
> > might have gone to the legitimate recipient, and possibly decrypt and
> > re-encrypt them. All this implies an attacker who has at least temporary
> > write access to the victim's computer, and long term read/write control
> > over the communication channels he will use.
>
> I do not believe this attack requires "long term read/write" access to
> the victim's computer. If I want to get a forged certificate into a
> clients Browser all I have to do is convince the user to browse my
> secure server with Netscape (or another browser) that will prompt the
> user to install my unrecognized root certificate.
That's a good point, most browsers are configured to make it easy to
install root certificates.
However this is just the first step in an effective compromise. Now you
need to get him to use a bogus certificate when he thinks he is using
a good one. He tries to connect to a secure site, and you need to step
in and play man in the middle. You must hijack his connection to, say,
www.amazon.com, and direct it to your own site. Then you can offer your
bogus cert for www.amazon.com and get it accepted.
You need to have long-term control over the communications channel in
order to be able to do these interceptions and get your bogus certs
accepted. There is more to it than just getting your root cert installed.
And note that the value to the attacker of a browser compromise is
relatively limited. In most cases the worst that will happen is that
you could steal a credit card number. Such a prize is hardly worth
the necessary trouble and expense. This is probably why the browser
companies have done so little to prevent the installation of untrustworthy
root certs. There just isn't that much an attacker can do with them.
