7 ms·

If browsers would be happy to allow users to a site with a self-signed SSL certificate, which is far more secure than HTTP, then I'd be happy to put in the extr

If browsers would be happy to allow users to a site with a self-signed SSL certificate, which is far more secure than HTTP, then I'd be happy to put in the extra time and effort to ensure 100% of communications occured over HTTPS. Until then it's extra time, effort and cost to offer something that most users do not understand and do not care about.

mukyu 16y ago
A self-signed cert provides effectively zero protection. You have no guarantee of the identity of the site and there is no confidentiality in your traffic. Key continuity (the only assurance you have that the cert might be legit) is not effective on the web, where you are likely to interact with hundreds of unknown hosts. If browsers do not throw big warnings at self-signed certs it is trivial to impersonate even sites that do have real certificates. The user sees a lock icon and thinks they are secure, but they are sending their credit card to someone other than Amazon.com. This is slightly fixed by EV certs, but there is still a large user training issue.
- jedsmith 16y ago
  > A self-signed cert provides effectively zero protection. From the other end. I had this debate with someone in person, and they tried to tell me that since you cannot trust the other end with a self-signed there is no point in protecting your traffic from eavesdroppers on the open AP. That makes no sense to me, but he was passionate enough about it that I let it go. He never could tell me why, so I invite a more learned HNer to complete his argument for him and persuade me. My take: There's a difference between identity and encryption, and I think warning users about a site that wants encryption but doesn't necessarily want or need identity is a bigger user-training mistake than anything else browsers have ever done. Perhaps the lock was the problem there; in that case, if I offer a self-signed certificate, perhaps the better UI experience would be to inform the user in that "Page Info" that their connection is encrypted, but they have no idea if the other end is who they say they are -- and don't bless the page with a lock, bar, anything. The entire construction of https:// https:// needing to imply both encryption and identity doesn't make sense to me, as I see them as distinct concepts. One does not necessarily imply the other, but browsers make it so. Maybe this is inherent to SSL/TLS itself and I'm the off-base one, but logically it makes sense to me.
  - mukyu 16y ago
    There are not many cases where you can read traffic, but not intercept/inject your own. All you need to do is generate your own cert for the site and the user will encrypt their traffic to you. This is why the lack authentication means that no confidentiality is provided.
    - rwmj 16y ago
      You just ensure the browser warns you if the self-signed certificate changes. It works fine this way for ssh.
      - arethuza 16y ago
        Out of interest, if you are warned that a site's SSL certificate has changed, what steps would you take to confirm the authenticity of the new certificate?
        ezyang 16y ago
        You use the same model as SSH: give a big warning with klaxons "Warning, this site's SSL certificate has changed, it is possible that you are being actively attacked" and then force the user to dig into an text file and manually remove the offending memorized entry (no prompt for saying "Ignore and carry on"). The hope being that an inexperienced user would find someone more competent to help them out. There are loads of ways this could go wrong (the phishing website earnestly telling the user that they "changed" their SSL key and that you need to follow these simple steps to "fix" your browser; the initial contact being the bogus website; the huge loss of traffic if your SSL key legitimately changes and you're not prepared; you need to deal with revocation).
        ZoFreX 16y ago
        I normally contact someone who is on a completely different internet connection to myself. I asked a friend of mine who lives the other side of the world to tell me what he saw the cert in question as, and it did not match the cert I was being given, so I rejected it.
- tedunangst 16y ago
  It provides protection if you have access to a reasonably trusted network. Let's say HN adds https with a self signed cert. I trust my home network, more or less, so I'll agree and accept the cert. Then if I take my laptop on the road, I can verify that the cert I'm getting over public wifi is the same cert I downloaded at home. That is tons better than the current "broadcast your password in plaintext" scenario we've got going on now. It means you can't trust sites if you're out of the house and you haven't been there before, but every site I care about trusting gets visited from in my house. And how big are certs? Not that big. It's conceivable you could download a bundle of them beforehand. We're getting almost back to CA land, though, so I'm going to cut this idea short, but you can imagine a service that collects certs and verifies nothing except that they are the same as they were last week.
- deleted 16y ago
  [deleted]
- asharp 16y ago
  Yes and no. Yes, on any sort of small network, you can be instantly MITM'd with basically no protection. No, in that on any sort of large scale traffic it becomes impractical to filter, ie. with modest hardware you can trawl through http at say 10Gbps, it's basically impossible to MITM at that sort of speed without much greater hardware requirements. Imo, having a self signed certificate simply appear to be http, ie. no "secure" icon, no locks, etc. would be a good middle ground.
- jeza 16y ago
  If an attacker manages to MITM your initial browser installation or upgrade download then we're in trouble. We'd then have to resort to verifying the authenticity of our browser install file through some other means. You could use HTTPS for your download though you'd need to be sure that you've done this every time and the original copy was from a trusted source. No doubt this is why open source developers are so keen to exchange GPG keys when they meet in person. Though at least when you're using some public wifi AP, you're unlikely to be upgrading your browser.
pilif 16y ago
Let's use FireSheep to illustrate the problem: If browsers wouldn't complain about self-signed certificates, I would extend FireSheep just a little bit to arp-spoof the IP-address of the gateway. This means that all the traffic in $coffeeshop is now being routed through my machine. Now whenever I see someone logging into facebook, I'm just pretending to be facebook, using my very own self-signed certificate. The user on the other end wouldn't notice at all if they didn't warn about self-signed certificates. Now the user thinks they log into facebook while they are actually logging in at my proxy. Browsers that blindly accept self-signed certificates would make for a much worse attack than firesheep (Firesheep allows hijacking of active sessions, man-in-the-middle-ing SSL connections gives you the password for offline use. You could of course try and work around this by having browsers "blow up" if the certificate changes at all. But what if facebook has to renew their self-signed certificate? Ok. Then let's just blow up if the signer authority changes? How do you make sure that the facebook who has signed the current certificate is actually the real facebook and not me impersonating as facebook? Accepting self-signed certificates might work with some kind of web of trust. Imagine the browser showing a message like: "Do your trust this site? 99.992% of our users have seen the same certificate, so it's pretty certain that this is really the right site" This, again, works until Facebook has to change that certificate: "Do you trust this site? 0.00001% of our users have seen this certificate. This is probably a phishing attempt" Don't get me wrong. I think that the current CAs overcharge for their services. I do think that there are way too many CAs already listed in your browsers. I do think that the whole process is too complicated. But over the years, I really came to an understanding that this, for the moment, is a necessary evil.
- ericmoritz 16y ago
  We had a dream of taking an ardrino, a wifi shield and writing a session cookie sniffer that will tweet/facebook status updates that says something along the lines of, "X coffee is so much better than Y coffee" and hiding the think somewhere need two competing coffee shops. Seemed like a perfect demonstration of how bad the problem is. We never got around to doing it though.

mukyu 16y ago

A self-signed cert provides effectively zero protection. You have no guarantee of the identity of the site and there is no confidentiality in your traffic. Key continuity (the only assurance you have that the cert might be legit) is not effective on the web, where you are likely to interact with hundreds of unknown hosts. If browsers do not throw big warnings at self-signed certs it is trivial to impersonate even sites that do have real certificates. The user sees a lock icon and thinks they are secure, but they are sending their credit card to someone other than Amazon.com. This is slightly fixed by EV certs, but there is still a large user training issue.

jedsmith 16y ago
> A self-signed cert provides effectively zero protection. From the other end. I had this debate with someone in person, and they tried to tell me that since you cannot trust the other end with a self-signed there is no point in protecting your traffic from eavesdroppers on the open AP. That makes no sense to me, but he was passionate enough about it that I let it go. He never could tell me why, so I invite a more learned HNer to complete his argument for him and persuade me. My take: There's a difference between identity and encryption, and I think warning users about a site that wants encryption but doesn't necessarily want or need identity is a bigger user-training mistake than anything else browsers have ever done. Perhaps the lock was the problem there; in that case, if I offer a self-signed certificate, perhaps the better UI experience would be to inform the user in that "Page Info" that their connection is encrypted, but they have no idea if the other end is who they say they are -- and don't bless the page with a lock, bar, anything. The entire construction of https:// https:// needing to imply both encryption and identity doesn't make sense to me, as I see them as distinct concepts. One does not necessarily imply the other, but browsers make it so. Maybe this is inherent to SSL/TLS itself and I'm the off-base one, but logically it makes sense to me.
- mukyu 16y ago
  There are not many cases where you can read traffic, but not intercept/inject your own. All you need to do is generate your own cert for the site and the user will encrypt their traffic to you. This is why the lack authentication means that no confidentiality is provided.
  - rwmj 16y ago
    You just ensure the browser warns you if the self-signed certificate changes. It works fine this way for ssh.
    - arethuza 16y ago
      Out of interest, if you are warned that a site's SSL certificate has changed, what steps would you take to confirm the authenticity of the new certificate?
      - ezyang 16y ago
        You use the same model as SSH: give a big warning with klaxons "Warning, this site's SSL certificate has changed, it is possible that you are being actively attacked" and then force the user to dig into an text file and manually remove the offending memorized entry (no prompt for saying "Ignore and carry on"). The hope being that an inexperienced user would find someone more competent to help them out. There are loads of ways this could go wrong (the phishing website earnestly telling the user that they "changed" their SSL key and that you need to follow these simple steps to "fix" your browser; the initial contact being the bogus website; the huge loss of traffic if your SSL key legitimately changes and you're not prepared; you need to deal with revocation).
      - ZoFreX 16y ago
        I normally contact someone who is on a completely different internet connection to myself. I asked a friend of mine who lives the other side of the world to tell me what he saw the cert in question as, and it did not match the cert I was being given, so I rejected it.
tedunangst 16y ago
It provides protection if you have access to a reasonably trusted network. Let's say HN adds https with a self signed cert. I trust my home network, more or less, so I'll agree and accept the cert. Then if I take my laptop on the road, I can verify that the cert I'm getting over public wifi is the same cert I downloaded at home. That is tons better than the current "broadcast your password in plaintext" scenario we've got going on now. It means you can't trust sites if you're out of the house and you haven't been there before, but every site I care about trusting gets visited from in my house. And how big are certs? Not that big. It's conceivable you could download a bundle of them beforehand. We're getting almost back to CA land, though, so I'm going to cut this idea short, but you can imagine a service that collects certs and verifies nothing except that they are the same as they were last week.
deleted 16y ago
[deleted]
asharp 16y ago
Yes and no. Yes, on any sort of small network, you can be instantly MITM'd with basically no protection. No, in that on any sort of large scale traffic it becomes impractical to filter, ie. with modest hardware you can trawl through http at say 10Gbps, it's basically impossible to MITM at that sort of speed without much greater hardware requirements. Imo, having a self signed certificate simply appear to be http, ie. no "secure" icon, no locks, etc. would be a good middle ground.
jeza 16y ago
If an attacker manages to MITM your initial browser installation or upgrade download then we're in trouble. We'd then have to resort to verifying the authenticity of our browser install file through some other means. You could use HTTPS for your download though you'd need to be sure that you've done this every time and the original copy was from a trusted source. No doubt this is why open source developers are so keen to exchange GPG keys when they meet in person. Though at least when you're using some public wifi AP, you're unlikely to be upgrading your browser.

pilif 16y ago

Let's use FireSheep to illustrate the problem: If browsers wouldn't complain about self-signed certificates, I would extend FireSheep just a little bit to arp-spoof the IP-address of the gateway. This means that all the traffic in $coffeeshop is now being routed through my machine. Now whenever I see someone logging into facebook, I'm just pretending to be facebook, using my very own self-signed certificate. The user on the other end wouldn't notice at all if they didn't warn about self-signed certificates. Now the user thinks they log into facebook while they are actually logging in at my proxy. Browsers that blindly accept self-signed certificates would make for a much worse attack than firesheep (Firesheep allows hijacking of active sessions, man-in-the-middle-ing SSL connections gives you the password for offline use. You could of course try and work around this by having browsers "blow up" if the certificate changes at all. But what if facebook has to renew their self-signed certificate? Ok. Then let's just blow up if the signer authority changes? How do you make sure that the facebook who has signed the current certificate is actually the real facebook and not me impersonating as facebook? Accepting self-signed certificates might work with some kind of web of trust. Imagine the browser showing a message like: "Do your trust this site? 99.992% of our users have seen the same certificate, so it's pretty certain that this is really the right site" This, again, works until Facebook has to change that certificate: "Do you trust this site? 0.00001% of our users have seen this certificate. This is probably a phishing attempt" Don't get me wrong. I think that the current CAs overcharge for their services. I do think that there are way too many CAs already listed in your browsers. I do think that the whole process is too complicated. But over the years, I really came to an understanding that this, for the moment, is a necessary evil.

ericmoritz 16y ago
We had a dream of taking an ardrino, a wifi shield and writing a session cookie sniffer that will tweet/facebook status updates that says something along the lines of, "X coffee is so much better than Y coffee" and hiding the think somewhere need two competing coffee shops. Seemed like a perfect demonstration of how bad the problem is. We never got around to doing it though.