6 ms·

I'm really glad to see this. I really dislike that browsers seem to treat self-signed certificates as worse than plain HTTP (in that self-signed certificates c

I'm really glad to see this. I really dislike that browsers seem to treat self-signed certificates as worse than plain HTTP (in that self-signed certificates cause a big scary yellow warning that looks similar to the big scary red warning for invalid certs). Self-signed certs are bad insofar as you can't prove that someone else isn't MITMing the connection and serving you an encrypted, but untrustworthy, proxy page. But with plain HTTP, you already have no guarantees that that isn't happening![0] If I understand it correctly, this seems to combine the best of both: encouraging the use of self-signed certificates over plain HTTP, while still rewarding verified certs (ie, signed by a trusted third party) over self-signed. [0] If you really care, you should use a CA-signed cert. But every attack that possible when using self-signed certs is not only possible when using plain HTTP, but much easier to execute, and also much easier to execute silently.

tines 12y ago
I won't defend it, but I can imagine that an argument for why self-signed certs could be worse than plain HTTP might be that if you're using HTTP, the communication isn't meant to be secure/trustworthy, but the presence of a certificate means that your communication is meant to be one or both, and since the cert is self-signed, it may not be either. This argument does presume that site administrators know what does and doesn't need to be confidential, which of course may not be the case. Some argue that all communication should be encrypted, but that's another issue.
- Dylan16807 12y ago
  It's an argument made through misleading categories. Self-signed certs specifically are not an indication that the connection needs to be trustworthy, so treating it like HTTP is fine. If it's marked with HSTS, then fail it like HTTP. Don't show secure cookies. Easy.
  - Buge 12y ago
    But if someone clicks a link that says https:// https://, then the person who created that link wanted there to be authentication, so an error would be the correct behavior.
    - Dylan16807 12y ago
      1. Not true if that link replaced one that said http via an automatic process. Such as HTTPS Everywhere or a search engine doing the wrong thing. 2. Certificate errors are much more confusing than a failure to connect.
      - jimktrains2 12y ago
        I don't want my UA showing me the wrong protocol though.
        Dylan16807 12y ago
        Depends on how you define "wrong". The S stands for secure, that's been pounded into people's heads. HTTP 1 and 2 are miles apart and get the same protocol marker. So a secure connection with TLS gets shown as HTTPS, and an insecure connection with TLS gets shown as HTTP.
        jimktrains2 12y ago
        > The S stands for secure, that's been pounded into people's heads. The S stands for "this connection is on port 443 and has been negotiated with TLS". That means it's being encrypted and has been authenticated. > HTTP 1 and 2 are miles apart and get the same protocol marker. Which was and is a terrible terrible idea and among the many reasons I dislike HTTP2. > So a secure connection with TLS gets shown as HTTPS, and an insecure connection with TLS gets shown as HTTP. Which is a terrible terrible idea. The protocol marker should denote the protocol used, not some fluffy stuff that doesn't really mean anything to the user.
        12y ago
- vbezhenar 12y ago
  Self-signed certificate provides defense against passive attacker, and HTTP does not. That's an important difference IMO.
  - deleted 12y ago
    [deleted]
  - copsarebastards 12y ago
    That's good in that it requires a slightly more sophisticated attack, but I don't really view that as a very effective defense. However, the bigger thing a self-signed cert allows you is the ability to verify later if your communication has been snooped by an active attacker--which is very significant. It's problematic that the communications aren't authenticated before they occur, but that doesn't mean they can't be authenticated later (via CAs or other means).
    - Wicher 12y ago
      > That's good in that it requires a slightly more sophisticated attack, but I don't really view that as a very effective defense. A slightly more sophisticated attack, indeed — but one that doesn't scale well. It ups the cost of mass surveillance tremendously.
      - copsarebastards 12y ago
        I hear this frequently but I don't buy it. What about the MITM scales worse than a passive listener? As far as I can tell, both insertion of a passive listener and a MITM are algorithmically O(n) on the number of connections being surveilled. All you're increasing for the MITM is the constant factor. When you're on the order of billions of connections being surveilled, even linear growth is hard, but we know that the NSA already has done that. Increasing the difficulty by a constant factor is not much harder, and there's no question that the NSA has the budget to do so. And in fact, the constant factor isn't even large: it's whatever the resource costs of two connection handshakes per connection is, plus decryption/encryption on the data flowing across, all of which are highly optimized algorithms at this point.
- yellowapple 12y ago
  The problem with that argument is that HTTPS is being increasingly used for all traffic, rather than just traffic meant to be confidential/authenticated. As a result, the semantic difference between HTTP and HTTPS is being lost in those cases.
- rdtsc 12y ago
  It is a GUI problem. How it is presented to the user. Typical mildly advanced user thinks this way: I see https:// https:// in URL bar and no scary red/yellow untrusted cert dialog? -- Ok I am all set to type my credit card number in. There are the green brackground in there too, which I forget what it means, but it presumes some extra "security/authentication" thing. What should the encrypted but not authenticated mode show? https:// https:// with a yellow or gray bar? Try to teach the user about is the difference between authenticated vs encrypted. Warn them once and put a "Got it, do not bother me again" dialog. Remember windows vista with "deny or allow?" dialog every single time you did anything with your computer. The intent was good but how the users perceived it was the problem. Here it is the same problem.
duaneb 12y ago
I would even go so far as to say that shipping with root certificates undermines the security of every user by APPEARING to verify identity, when in reality you're just trusting Mozilla, Apple, Google, Microsoft, etc., and they cannot possibly verify any fraction of the CAs that are handed out daily.
Kalium 12y ago
In a world where users automatically equate encryption with safety, self-signed should be regarded with skepticism.
IgorPartola 12y ago
I will again state my solution to this: drop all support for HTTP. There still seem to be a large number of people that don't get why illusion of security is worse than knowing for a fact that there is no security. However, dropping HTTP solves this confusion and a host of other problems. Along with that, perhaps we can revamp the current CA system and have something that more closely resembles decentralized secure web. Once again, if you advocate using HTTP, go ahead and drop ssh in favor of telnet.
- rogerbinns 12y ago
  Do you really mean dropping HTTP? HTTP itself just requires an underlying reliable byte stream and does not dictate whether that is bare TCP, TLS, or any other concoction. Assuming you mean drop HTTP over bare TCP, and are advocating for HTTP over TLS, then everyone knows that is the right thing to aim for. But advocating revolution won't get anywhere since there is a phenomenal number of systems to update. Just like IPv6 deployment, it will take decades before HTTP over bare TCP is removed. The article is an excellent proposal because it helps migration. Certificates do need to be sorted out. Heck they currently hinge on names, yet what name does a random router bought at Best Buy and plugged into my network have? Or the armada of IOT devices coming along - thermostats, fridges, light bulbs?
  - IgorPartola 12y ago
    You are technically correct (the best kind), but of course I mean dropping HTTP in favor of HTTPS. I don't think many people could possibly confuse what I meant. We all know the way this works and I don't want to get bogged down in semantics. I don't see anything there as constructive. I am advocation for a revolution. We have the technology today, and after Let's Encrypt goes live all we really need is for Google to announce that Chrome will run for six months with a warning when using HTTP (similar to what it does bow for self-signed certs) and the will stop supporting HTTP altogether. How quickly do you figure people will move if this was announced?
    - rogerbinns 12y ago
akjj 12y ago
The argument against this is that a URL starting with https means something, at least to some users and your proposal would undermine that. When I want to go to my bank, I type chase into the address bar and choose one of the suggestions that starts with https and then go about my business. Maybe I should be paying attention to whether or not there's a green lock in the upper left and maybe I'd notice if it were missing, but I don't intentionally look for for the lock. In your proposed change, the absence of a lock icon would be the only way I'd notice if my connection were being MITM'ed. So, in that way it would be making the web less secure for users who are entering an https URL and expect it to be secure. That's what's attractive to me about Firefox's opportunistic encryption proposal. It really makes no change in the UX compared to an unencrypted connection, not in the URL and not in the time to connect.
- untog 12y ago
  I'd be interested to know how many users notice the HTTPS as opposed to the padlock. After all, no-one types the "http" in a web address anyway.
  - rdtsc 12y ago
    There are different classes of users. Above average users will notice. My mom for example won't notice. She doesn't know what a URL bar is. She doesn't even look at that place. She clicks on her toolbar for Gmail and other sites she uses. She wouldn't care if it said http:// http:// https:// https:// or foobar://. She will be scared and be afraid to proceed if she would see the "Warning, untrusted certificate!" dialog. My wife knows something about http vs https. If it says https she knows it is safe to type in her credit card number. https means "secure". But she doesn't know about authentication vs encryption. And will be equally scared about "Warning, untrusted certificate!" dialog. That might as well say "Your computer is hacked and you have a virus". Anyway just giving a perceptive on how this affects different classes of users. As I put it in another post, it is in large about the UI.
  - deckiedan 12y ago
    How about an open padlock? If I saw that my initial reaction would be "WFT?", mouse-over it, and then get a dialog explaining it.
brazzledazzle 12y ago
The problem is a "real" certificate being MitM'd and replaced with a self signed one. Things like certificate pinning might be able to mitigate that. Even though it's been a bit of a farce (in no small part due to the quizzically large set of trusted root CAs) the idea is that the CAs that you trust do their due diligence and don't sign fraudulent requests. >[0] If you really care, you should use a CA-signed cert. But every attack that possible when using self-signed certs is not only possible when using plain HTTP, but much easier to execute, and also much easier to execute silently. Right, but the owner of the server you're connecting to is the one that has to choose if the data they're serving or receiving qualifies for protection of this sort. By omission they've basically taken the position that their pages or data are not worth preventing an attacker from MitM'ing you. If you allow self-signed certificates to fly without a warning at that point you're taking the decision to secure from a MitM attack away from the server owner that wants to protect their pages. Sure, a savvy user would notice a change, but what if they've never been to that site before? Here's a scenario: Bob's Widgets sells Widget 9000 and has a secure site with a certificate signed by a CA. Alice hops on free WiFi at a Widget convention and visits for the first time, hoping to buy some of these amazing widgets Bob sells. Except Mallory intercepted the traffic and swapped out a self signed certificate. Bob's only way of telling Alice that his certificate and therefore traffic is authentic is by using one signed by a trusted third party. Now that isn't to say that I don't think your idea has merit. It just doesn't fit into how we currently do things. What might work is a keeping port 80 and port 443. Port 80 is secured by a self-signed certificate but the user isn't informed (via their browser's indicators, like a green icon or what-have-you) that their connection is secure because it isn't in the sense that it will protect them from MitM attacks. It is however encrypted and you can have the browsers trigger warnings when the key changes similar to the way SSH does. 443 still behaves exactly the same where users only trust CA signed certs by default.

tines 12y ago

I won't defend it, but I can imagine that an argument for why self-signed certs could be worse than plain HTTP might be that if you're using HTTP, the communication isn't meant to be secure/trustworthy, but the presence of a certificate means that your communication is meant to be one or both, and since the cert is self-signed, it may not be either. This argument does presume that site administrators know what does and doesn't need to be confidential, which of course may not be the case. Some argue that all communication should be encrypted, but that's another issue.

Dylan16807 12y ago
It's an argument made through misleading categories. Self-signed certs specifically are not an indication that the connection needs to be trustworthy, so treating it like HTTP is fine. If it's marked with HSTS, then fail it like HTTP. Don't show secure cookies. Easy.
- Buge 12y ago
  But if someone clicks a link that says https:// https://, then the person who created that link wanted there to be authentication, so an error would be the correct behavior.
  - Dylan16807 12y ago
    1. Not true if that link replaced one that said http via an automatic process. Such as HTTPS Everywhere or a search engine doing the wrong thing. 2. Certificate errors are much more confusing than a failure to connect.
    - jimktrains2 12y ago
      I don't want my UA showing me the wrong protocol though.
      - Dylan16807 12y ago
        Depends on how you define "wrong". The S stands for secure, that's been pounded into people's heads. HTTP 1 and 2 are miles apart and get the same protocol marker. So a secure connection with TLS gets shown as HTTPS, and an insecure connection with TLS gets shown as HTTP.
        jimktrains2 12y ago
        > The S stands for secure, that's been pounded into people's heads. The S stands for "this connection is on port 443 and has been negotiated with TLS". That means it's being encrypted and has been authenticated. > HTTP 1 and 2 are miles apart and get the same protocol marker. Which was and is a terrible terrible idea and among the many reasons I dislike HTTP2. > So a secure connection with TLS gets shown as HTTPS, and an insecure connection with TLS gets shown as HTTP. Which is a terrible terrible idea. The protocol marker should denote the protocol used, not some fluffy stuff that doesn't really mean anything to the user.
        12y ago
vbezhenar 12y ago
Self-signed certificate provides defense against passive attacker, and HTTP does not. That's an important difference IMO.
- deleted 12y ago
  [deleted]
- copsarebastards 12y ago
  That's good in that it requires a slightly more sophisticated attack, but I don't really view that as a very effective defense. However, the bigger thing a self-signed cert allows you is the ability to verify later if your communication has been snooped by an active attacker--which is very significant. It's problematic that the communications aren't authenticated before they occur, but that doesn't mean they can't be authenticated later (via CAs or other means).
  - Wicher 12y ago
    > That's good in that it requires a slightly more sophisticated attack, but I don't really view that as a very effective defense. A slightly more sophisticated attack, indeed — but one that doesn't scale well. It ups the cost of mass surveillance tremendously.
    - copsarebastards 12y ago
      I hear this frequently but I don't buy it. What about the MITM scales worse than a passive listener? As far as I can tell, both insertion of a passive listener and a MITM are algorithmically O(n) on the number of connections being surveilled. All you're increasing for the MITM is the constant factor. When you're on the order of billions of connections being surveilled, even linear growth is hard, but we know that the NSA already has done that. Increasing the difficulty by a constant factor is not much harder, and there's no question that the NSA has the budget to do so. And in fact, the constant factor isn't even large: it's whatever the resource costs of two connection handshakes per connection is, plus decryption/encryption on the data flowing across, all of which are highly optimized algorithms at this point.
yellowapple 12y ago
The problem with that argument is that HTTPS is being increasingly used for all traffic, rather than just traffic meant to be confidential/authenticated. As a result, the semantic difference between HTTP and HTTPS is being lost in those cases.
rdtsc 12y ago
It is a GUI problem. How it is presented to the user. Typical mildly advanced user thinks this way: I see https:// https:// in URL bar and no scary red/yellow untrusted cert dialog? -- Ok I am all set to type my credit card number in. There are the green brackground in there too, which I forget what it means, but it presumes some extra "security/authentication" thing. What should the encrypted but not authenticated mode show? https:// https:// with a yellow or gray bar? Try to teach the user about is the difference between authenticated vs encrypted. Warn them once and put a "Got it, do not bother me again" dialog. Remember windows vista with "deny or allow?" dialog every single time you did anything with your computer. The intent was good but how the users perceived it was the problem. Here it is the same problem.

duaneb 12y ago

I would even go so far as to say that shipping with root certificates undermines the security of every user by APPEARING to verify identity, when in reality you're just trusting Mozilla, Apple, Google, Microsoft, etc., and they cannot possibly verify any fraction of the CAs that are handed out daily.

Kalium 12y ago

In a world where users automatically equate encryption with safety, self-signed should be regarded with skepticism.

IgorPartola 12y ago

I will again state my solution to this: drop all support for HTTP. There still seem to be a large number of people that don't get why illusion of security is worse than knowing for a fact that there is no security. However, dropping HTTP solves this confusion and a host of other problems. Along with that, perhaps we can revamp the current CA system and have something that more closely resembles decentralized secure web. Once again, if you advocate using HTTP, go ahead and drop ssh in favor of telnet.

rogerbinns 12y ago
Do you really mean dropping HTTP? HTTP itself just requires an underlying reliable byte stream and does not dictate whether that is bare TCP, TLS, or any other concoction. Assuming you mean drop HTTP over bare TCP, and are advocating for HTTP over TLS, then everyone knows that is the right thing to aim for. But advocating revolution won't get anywhere since there is a phenomenal number of systems to update. Just like IPv6 deployment, it will take decades before HTTP over bare TCP is removed. The article is an excellent proposal because it helps migration. Certificates do need to be sorted out. Heck they currently hinge on names, yet what name does a random router bought at Best Buy and plugged into my network have? Or the armada of IOT devices coming along - thermostats, fridges, light bulbs?
- IgorPartola 12y ago
  You are technically correct (the best kind), but of course I mean dropping HTTP in favor of HTTPS. I don't think many people could possibly confuse what I meant. We all know the way this works and I don't want to get bogged down in semantics. I don't see anything there as constructive. I am advocation for a revolution. We have the technology today, and after Let's Encrypt goes live all we really need is for Google to announce that Chrome will run for six months with a warning when using HTTP (similar to what it does bow for self-signed certs) and the will stop supporting HTTP altogether. How quickly do you figure people will move if this was announced?
  - rogerbinns 12y ago

akjj 12y ago

The argument against this is that a URL starting with https means something, at least to some users and your proposal would undermine that. When I want to go to my bank, I type chase into the address bar and choose one of the suggestions that starts with https and then go about my business. Maybe I should be paying attention to whether or not there's a green lock in the upper left and maybe I'd notice if it were missing, but I don't intentionally look for for the lock. In your proposed change, the absence of a lock icon would be the only way I'd notice if my connection were being MITM'ed. So, in that way it would be making the web less secure for users who are entering an https URL and expect it to be secure. That's what's attractive to me about Firefox's opportunistic encryption proposal. It really makes no change in the UX compared to an unencrypted connection, not in the URL and not in the time to connect.

untog 12y ago
I'd be interested to know how many users notice the HTTPS as opposed to the padlock. After all, no-one types the "http" in a web address anyway.
- rdtsc 12y ago
  There are different classes of users. Above average users will notice. My mom for example won't notice. She doesn't know what a URL bar is. She doesn't even look at that place. She clicks on her toolbar for Gmail and other sites she uses. She wouldn't care if it said http:// http:// https:// https:// or foobar://. She will be scared and be afraid to proceed if she would see the "Warning, untrusted certificate!" dialog. My wife knows something about http vs https. If it says https she knows it is safe to type in her credit card number. https means "secure". But she doesn't know about authentication vs encryption. And will be equally scared about "Warning, untrusted certificate!" dialog. That might as well say "Your computer is hacked and you have a virus". Anyway just giving a perceptive on how this affects different classes of users. As I put it in another post, it is in large about the UI.
- deckiedan 12y ago
  How about an open padlock? If I saw that my initial reaction would be "WFT?", mouse-over it, and then get a dialog explaining it.

brazzledazzle 12y ago

The problem is a "real" certificate being MitM'd and replaced with a self signed one. Things like certificate pinning might be able to mitigate that. Even though it's been a bit of a farce (in no small part due to the quizzically large set of trusted root CAs) the idea is that the CAs that you trust do their due diligence and don't sign fraudulent requests. >[0] If you really care, you should use a CA-signed cert. But every attack that possible when using self-signed certs is not only possible when using plain HTTP, but much easier to execute, and also much easier to execute silently. Right, but the owner of the server you're connecting to is the one that has to choose if the data they're serving or receiving qualifies for protection of this sort. By omission they've basically taken the position that their pages or data are not worth preventing an attacker from MitM'ing you. If you allow self-signed certificates to fly without a warning at that point you're taking the decision to secure from a MitM attack away from the server owner that wants to protect their pages. Sure, a savvy user would notice a change, but what if they've never been to that site before? Here's a scenario: Bob's Widgets sells Widget 9000 and has a secure site with a certificate signed by a CA. Alice hops on free WiFi at a Widget convention and visits for the first time, hoping to buy some of these amazing widgets Bob sells. Except Mallory intercepted the traffic and swapped out a self signed certificate. Bob's only way of telling Alice that his certificate and therefore traffic is authentic is by using one signed by a trusted third party. Now that isn't to say that I don't think your idea has merit. It just doesn't fit into how we currently do things. What might work is a keeping port 80 and port 443. Port 80 is secured by a self-signed certificate but the user isn't informed (via their browser's indicators, like a green icon or what-have-you) that their connection is secure because it isn't in the sense that it will protect them from MitM attacks. It is however encrypted and you can have the browsers trigger warnings when the key changes similar to the way SSH does. 443 still behaves exactly the same where users only trust CA signed certs by default.