On Wed, 2007-12-05 at 11:48 +0000, Stef Walter wrote: > Owen Taylor wrote: > >>> (And note that Stef's proposal doesn't just greenlight a connection to > >>> https://bugs.freedesktop.org, it greenlights a https connection to a > >>> DNS-spoofed https://mybank.com.) > >> Neither bugs.freedesktop.org or a DNS spoofed https site would be > >> 'greenlighted' under my proposal. Just the opposite. It would be treated > >> just like the untrusted connection that it is. > > > > If I have a bookmark (or link) to https://mybank.com and I go there, and > > I see my banking site, and even the correct https URL in my browser > > line, and the only indication that something went wrong is that the > > I don't get a lock icon, that's not greenlighting? > > > > You can't expect people to be warned by the *absence* of something. > > True. It makes sense in the bookmark case. > > In other cases, if the scammer used or redirected to a normal http > non-SSL connection, then then the only warning would be the absence of > the lock icon and the 's' in the URL. phishing is really a different issue; as Alex points out, the lock icon has nothing to do whether you are getting phished or not... it simply means that you are connected to the URL you tried to connect to. My particular concern here is man-in-the-middle-attacks against the case when you *are* connecting to the URL you wanted to connect to. > > (Sure, ssh-style checking against history would help, in certain > > cases, but you are still losing much of the strength of https.) > > I'm not sure I understand. Let's say some history checking of certifates > -> domains was implemented, how that would cause a loss of strength in > https? Obviously you've thought about these issues thoroughly, so I'm > interested. So, history checking can be effective against the case of hijacking https://mybank.com, if made strong enough. (That is, if someone has in the past seen a CA-signed cert for a site, then connection via a self-signed cert is blocked, no if, no ands, no buts, no no dialogs.) But that still leaves a basic premise here that I object to: that a self-signed certificate is worth something. Roughly speaking, the networking world is divided into two pieces: - The part that is mostly secure, with no sniffing possible. - The part that is completely insecure, with both sniffing and man-in-the-middle attacks possible. Even when we remove the lock icon, if we pass a self-signed certificate without objection we are OK'ing it, because the person creating the site switched to https and didn't get any complaints from their users. And because users connected to the URL they were given and it worked. (Again, going back to Alex's point, making users focus on whether a lock icon is their or not is actually counterproductive, because what users will then assume is that the lock icon means "secure". Which it doesn't.) And I don't think that history checking can be used to upgrade the security of self-signed certificates. Say, you tried to file a bug on https://bugs.freedesktop.org and you got a message that the certificate changed. When would *you* think that it was actually an attempt to hack your freedesktop.org password, rather than the admins changing the certificate? - Owen
Attachment:
signature.asc
Description: This is a digitally signed message part