7 ms·

> 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

> 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.
  - mukyu 16y ago
    That is key continuity. It works for ssh because you generally know the parties you are trying to connect to ahead of time and have ways to communicate with them (to confirm keys etc). You do not have the same relationship with 99.99% of the servers you will be connecting to over https. It does not work.
    - rwmj 16y ago
      Actually I don't visit webservers with a uniform random distribution. I come back to some frequently (eg. my bank, HN, BBC News, ...) Maybe that's just me though.
jevinskie 16y ago
The reason is that to achieve true security, they go hand in hand. Without identity verification, you can simply perform a MITM attack (decrypt connection from client, re-encrypt when talking to the server). Firesheep showed MITM over HTTP to be trivially easy. Modifying Firesheep to do the same MITM attacks over HTTPS with self-signed certificates would be equally easy.
- jedsmith 16y ago
  > Firesheep showed MITM over HTTP to be trivially easy. Firesheep does not perform MITM attacks (the media made this mistake too). It catches sessions out of the air and impersonates them, which is session hijacking. As you wrote yourself, a man in the middle attack makes the victim think he is communicating with the far end; Firesheep doesn't involve the victim except to catch his packets.
Herring 16y ago
MITM is a type of eavesdropper.
tptacek 16y ago
Jed. Imagine a world in which browsers don't throw a fit when given self-signed certificates. Imagine Jedsville.com, your new startup that, to save $15, uses a self-signed certificate. Imagine me, visiting that website, getting a certificate so that my browser and your server can agree on an AES key for us to encrypt traffic with. Tell me this. How does my browser know if I've agreed with your server for a key, or with the man-in-the-middle proxy I've transparently been redirected to?
- jedsmith 16y ago
  I'm not sure why you condescend me by writing my name in responses to me, but it bugs me to death. That's the second time you've done it to me (you did it when I took the unpopular side in the Square credit card bonanza, too), and I am capable of communicating with you from the same level. I don't see you naming other people you're communicating with to add emphasis, so I must assume it's me. > to save $15, uses a self-signed certificate. Valid SSL can be had from StartSSL for no charge. Money is not the issue, it's browsers completely flipping their shit at a self-signed. > How does my browser know if I've agreed with your server for a key, or with the man-in-the-middle proxy I've transparently been redirected to? It doesn't. Which is why, quoting myself and adding emphasis: > 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 This is the function of the big red warning, but it's the implementation of that very warning that I disagree with. However, the traffic in between you and the other end (the other end that you cannot verify, remember) is still encrypted from completely unrelated third parties, so there is still a negligible benefit. It limits "opened Wireshark and watched you work" to "need to know specifically what I'm after and generate a certificate and poison DNS and ..." A self-signed alone raises the barrier to entry at Starbucks significantly from "really, really easy" to "need to reconnoiter the target and have significant control over the network".
  - tptacek 16y ago
    I'm sorry you find that condescending. I don't mean it to be. The distinction you're trying to draw between "attacks that can be carried out with Wireshark" and "attacks that can be carried out with Wireshark and a Perl script" aren't meaningful to me, so I'm obviously the wrong person to try to persuade you about this. Sorry for wasting your time.
kronusaturn 16y ago
It's not inherent to SSL/TLS, it's a general issue. If you can't verify that the encryption key you're using actually belongs to the person you think it does, you're only protected against passive eavesdropping. Which buys you only weak protection against government mass surveillance, and none at all against someone doing something like DNS spoofing. On the other hand, the whole top-down certificate authority model is pretty weak anyway, especially since browsers don't provide any warning when a certificate for a site you've visited before has changed before its expiration date.
burgerbrain 16y ago
MITMing someone with selfsigned certs on an open wifi network is trivial. Any scriptkiddy can do it with mere minutes of setup and technical rampup: (http://www.thoughtcrime.org/software/sslsniff/ http://www.thoughtcrime.org/software/sslsniff/). In the real world, self-signed certs provide neither identity verification nor security.
- deleted 16y ago
  [deleted]
DrStalker 16y ago
>There's a difference between identity and encryption, I agree completely with this and would love a way to encrypt all the sites I look after without jumping through all the hoops needed to confirm identity to get an SSL cert that doens't make the site appear less secure than an unsecured HTTP site.
arethuza 16y ago
"encryption and identity... as distinct concepts" It is pretty standard to view these as separate concepts, see: http://en.wikipedia.org/wiki/Information_security http://en.wikipedia.org/wiki/Information_security
ezyang 16y ago
The key about self-signed certificates is that while they don't give specific identity assurances, they do give identity assurances across multiple transactions with the website. That is, the website I talked to yesterday is the same one I'm talking to today. If I had to implement "automatic" HTTPS, I would probably ask browsers to automatically accept self-signed certificates on the first transaction. Thus, with no user-interaction in the good case, an attacker must manage to MiTM the user on the very first time they access a site, and this is considerably harder to do and less likely to result in interesting information. So I do believe encryption without MiTM protection is a security increase. But there are usability trade-offs and obvious costs for rolling something out like this, and I don't think this particular proposal makes the cut, unfortunately.
dspillett 16y ago
If you are accessing a HTTPS site with a certificate that was not ultimately signed by a private key matching one of the public keys your browser has been told to trust, and you are using a public network (free wireless somewhere, for instance) how can you tell that the certificate your browser receives came from the destination server (your self signed cert) or a transparent proxy somewhere between you and it? A certificate signed by a non-trusted key will look the same to the browser whether it was signed by the site owner or a third party, so it would not be able to tell that a transparent proxy is decrypting the content from the server and re-encrypting it to send to you (potentially inspecting and logging the content on the way through that process). The way around this is for there to be fee SSL signing CAs that have their root trust certificate commonly installed. It is getting to the point now startssl's root key used for their free certificates is trusted by most browsers (http://en.wikipedia.org/wiki/StartCom http://en.wikipedia.org/wiki/StartCom), so you can probably use those for your needs. I don't think any other of the free providers (like cacert.org) have this level of acceptance yet. The difference between using a free cert from startssl or similar and using a self-signed certificate is that startssl will only issue a certificate to someone who has somehow verified they are in control of the name being certified (i.e. their contact details are in the whois records or such - I'm not sure what validation method they use as I've not used their service yet myself but they must do something adequate enough to get their root cert trusted by the big name browsers/OSs), whereas I can self-sign a certificate for any domain name, as could you, as could that nefarious transparent proxy. TL;DR: For personal use on your own machines, use a self signed cert and install your CA cert as trusted on your machines. For more general access (i.e. a public facing service) you'll have to try startssl or pay your dues (otherwise even "encryption only" does not work because of the proxy problem).
- mukyu 16y ago
  The only identity verification done by the vast majority of CAs is that you must be able to reply to email sent to one of a few email addresses at the domain you are trying to get a cert for. There have even been cases where people have gotten certs for free email providers just by signing up for one of those email addresses.
  - 16y ago
asharp 16y ago
SSL locks identity with encryption to prevent MITM attacks.

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.
- mukyu 16y ago
  That is key continuity. It works for ssh because you generally know the parties you are trying to connect to ahead of time and have ways to communicate with them (to confirm keys etc). You do not have the same relationship with 99.99% of the servers you will be connecting to over https. It does not work.
  - rwmj 16y ago
    Actually I don't visit webservers with a uniform random distribution. I come back to some frequently (eg. my bank, HN, BBC News, ...) Maybe that's just me though.

jevinskie 16y ago

The reason is that to achieve true security, they go hand in hand. Without identity verification, you can simply perform a MITM attack (decrypt connection from client, re-encrypt when talking to the server). Firesheep showed MITM over HTTP to be trivially easy. Modifying Firesheep to do the same MITM attacks over HTTPS with self-signed certificates would be equally easy.

jedsmith 16y ago
> Firesheep showed MITM over HTTP to be trivially easy. Firesheep does not perform MITM attacks (the media made this mistake too). It catches sessions out of the air and impersonates them, which is session hijacking. As you wrote yourself, a man in the middle attack makes the victim think he is communicating with the far end; Firesheep doesn't involve the victim except to catch his packets.

Herring 16y ago

MITM is a type of eavesdropper.

tptacek 16y ago

Jed. Imagine a world in which browsers don't throw a fit when given self-signed certificates. Imagine Jedsville.com, your new startup that, to save $15, uses a self-signed certificate. Imagine me, visiting that website, getting a certificate so that my browser and your server can agree on an AES key for us to encrypt traffic with. Tell me this. How does my browser know if I've agreed with your server for a key, or with the man-in-the-middle proxy I've transparently been redirected to?

jedsmith 16y ago
I'm not sure why you condescend me by writing my name in responses to me, but it bugs me to death. That's the second time you've done it to me (you did it when I took the unpopular side in the Square credit card bonanza, too), and I am capable of communicating with you from the same level. I don't see you naming other people you're communicating with to add emphasis, so I must assume it's me. > to save $15, uses a self-signed certificate. Valid SSL can be had from StartSSL for no charge. Money is not the issue, it's browsers completely flipping their shit at a self-signed. > How does my browser know if I've agreed with your server for a key, or with the man-in-the-middle proxy I've transparently been redirected to? It doesn't. Which is why, quoting myself and adding emphasis: > 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 This is the function of the big red warning, but it's the implementation of that very warning that I disagree with. However, the traffic in between you and the other end (the other end that you cannot verify, remember) is still encrypted from completely unrelated third parties, so there is still a negligible benefit. It limits "opened Wireshark and watched you work" to "need to know specifically what I'm after and generate a certificate and poison DNS and ..." A self-signed alone raises the barrier to entry at Starbucks significantly from "really, really easy" to "need to reconnoiter the target and have significant control over the network".
- tptacek 16y ago
  I'm sorry you find that condescending. I don't mean it to be. The distinction you're trying to draw between "attacks that can be carried out with Wireshark" and "attacks that can be carried out with Wireshark and a Perl script" aren't meaningful to me, so I'm obviously the wrong person to try to persuade you about this. Sorry for wasting your time.

kronusaturn 16y ago

It's not inherent to SSL/TLS, it's a general issue. If you can't verify that the encryption key you're using actually belongs to the person you think it does, you're only protected against passive eavesdropping. Which buys you only weak protection against government mass surveillance, and none at all against someone doing something like DNS spoofing. On the other hand, the whole top-down certificate authority model is pretty weak anyway, especially since browsers don't provide any warning when a certificate for a site you've visited before has changed before its expiration date.

burgerbrain 16y ago

MITMing someone with selfsigned certs on an open wifi network is trivial. Any scriptkiddy can do it with mere minutes of setup and technical rampup: (http://www.thoughtcrime.org/software/sslsniff/ http://www.thoughtcrime.org/software/sslsniff/). In the real world, self-signed certs provide neither identity verification nor security.

deleted 16y ago
[deleted]

DrStalker 16y ago

>There's a difference between identity and encryption, I agree completely with this and would love a way to encrypt all the sites I look after without jumping through all the hoops needed to confirm identity to get an SSL cert that doens't make the site appear less secure than an unsecured HTTP site.

arethuza 16y ago

"encryption and identity... as distinct concepts" It is pretty standard to view these as separate concepts, see: http://en.wikipedia.org/wiki/Information_security http://en.wikipedia.org/wiki/Information_security

ezyang 16y ago

The key about self-signed certificates is that while they don't give specific identity assurances, they do give identity assurances across multiple transactions with the website. That is, the website I talked to yesterday is the same one I'm talking to today. If I had to implement "automatic" HTTPS, I would probably ask browsers to automatically accept self-signed certificates on the first transaction. Thus, with no user-interaction in the good case, an attacker must manage to MiTM the user on the very first time they access a site, and this is considerably harder to do and less likely to result in interesting information. So I do believe encryption without MiTM protection is a security increase. But there are usability trade-offs and obvious costs for rolling something out like this, and I don't think this particular proposal makes the cut, unfortunately.

dspillett 16y ago

If you are accessing a HTTPS site with a certificate that was not ultimately signed by a private key matching one of the public keys your browser has been told to trust, and you are using a public network (free wireless somewhere, for instance) how can you tell that the certificate your browser receives came from the destination server (your self signed cert) or a transparent proxy somewhere between you and it? A certificate signed by a non-trusted key will look the same to the browser whether it was signed by the site owner or a third party, so it would not be able to tell that a transparent proxy is decrypting the content from the server and re-encrypting it to send to you (potentially inspecting and logging the content on the way through that process). The way around this is for there to be fee SSL signing CAs that have their root trust certificate commonly installed. It is getting to the point now startssl's root key used for their free certificates is trusted by most browsers (http://en.wikipedia.org/wiki/StartCom http://en.wikipedia.org/wiki/StartCom), so you can probably use those for your needs. I don't think any other of the free providers (like cacert.org) have this level of acceptance yet. The difference between using a free cert from startssl or similar and using a self-signed certificate is that startssl will only issue a certificate to someone who has somehow verified they are in control of the name being certified (i.e. their contact details are in the whois records or such - I'm not sure what validation method they use as I've not used their service yet myself but they must do something adequate enough to get their root cert trusted by the big name browsers/OSs), whereas I can self-sign a certificate for any domain name, as could you, as could that nefarious transparent proxy. TL;DR: For personal use on your own machines, use a self signed cert and install your CA cert as trusted on your machines. For more general access (i.e. a public facing service) you'll have to try startssl or pay your dues (otherwise even "encryption only" does not work because of the proxy problem).

mukyu 16y ago
The only identity verification done by the vast majority of CAs is that you must be able to reply to email sent to one of a few email addresses at the domain you are trying to get a cert for. There have even been cases where people have gotten certs for free email providers just by signing up for one of those email addresses.
- 16y ago

asharp 16y ago

SSL locks identity with encryption to prevent MITM attacks.