> I was thinking through possible attack scenarios against this proposed > UI and came up with a dangerous one: > > You are filling out a form in a page served by a site certified by > Verisign. You hit the submit button. Your HTTPS connection has timed > out, so the browser initiates a new HTTPS connection. This time, the > phisher intercepts the connection attempt and responds with a > self-signed certificate. The browser does not warn, but the lock icons > disappear. It is unfortunately too late though, the form POST has > already been sent.
Or, perhaps more interestingly, the phisher intercepts and responds with any old cert signed by any old CA. So the lock stays on. Presumably the status bar domain name would change so the cert would prefer to be consistent there, hence your suggestion of a self-signed cert (and sacrifice of the lock). This could be improved with a look-alike cert from a root CA. > The check on the site's cryptographic identity really has to happen at > connection time, before any data is sent. If the provided > cryptographic identity cannot be immediately correlated to the pending > request, a warning really must be issued. Does the restart take no account of the prior connection? If so, I'd suspect it would be easy to knock out an existing connection, and force a restart. I'm not quite sure of what the import of this attack means. It seems to be a relatively straightforward MITM. In which case, if a phisher has gone to the trouble of running an MITM we would have to ask whether he'd bother to get a CA-signed cert to do it, in which case he more or less becomes a chinese proxy, and he could just as easily attack the first connection. (It's more difficult to untraceably "own" an intermediate router than to get a cert.) iang _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
