6 ms·

Current system for SSL certs has failed hard, in principle and empirically

28 points by bensummers 16y ago

rlpb 16y ago
> Of 16 M IPs listening on 443, 10.8 M started SSL handshake; of those, 4.3 M used CA-signed cert chains (slide 14). Thus, the majority of servers use "invalid"/invalid/self-signed certs. How many of these IPs listening on 443 are public web servers? I know of a lot of things that listen for SSL on 443 that aren't HTTP as 443 can get through firewalls easily. For all we know, there already exists an out-of-band process to validate those self-signed certs. For example, I am one of these cases. I listen for SSL on port 443 using a self-signed cert, but all clients have that CA (and only that CA) pre-loaded.
- rlpb 16y ago
  In addition, it occurs to me that I've observed many sites that aren't security critical but seem to be running on a self-signed cert. For example, many mailing list archives seem to operate both on HTTP and HTTPS with a self-signed cert. As they are only hosting public data and clearly are happy to provide it without SSL as well, there is no security failure here.
  - klync 16y ago
    I think you would still have to count that as a security failure. For one, you don't know why there is ssl and non-ssl - there could be content that's available over ssl and/or via login which you don't see using the "public" http url schema. The server could be set up to make this transparent to you, making it appear that ssl is superfluous. Second, even if that's the case, a broken SSL implementation is still a broken SSL implementation, even if it's protecting content that doesn't seem to need protecting.
    - rlpb 16y ago
      > ...a broken SSL implementation is still a broken SSL implementation, even if it's protecting content that doesn't seem to need protecting. That depends on what is required of the SSL implementation. A self-signed cert which the client cannot verify still provides some protection. It is MITM-able, but casual snooping is prevented. If this is the specification, then this implementation is not broken. Put it this way. Forget the specifics of SSL for a moment. If unencrypted data is acceptable, then in what way is having the option of weak-but-slightly-better encryption suddenly "broken"? This analysis is flawed because it assumes that strong security was required by all who use SSL at all. Many installations use a self-signed SSL cert by default. These default configurations often remain when security is not required and therefore not configured further. I suspect that this skews the figures far enough to make this sort of analysis meaningless.
      - klync 16y ago
        Hey rlpb, Sorry, I tried to reply to your post about 4 times yesterday, and it never went through for some reason. I agree with what you're saying about self-signed certs being not necessarily broken. Maybe I mis-read your original message, but what I was objecting to was the idea that a site that apparently has the same content available over http and [broken] https is not a problem; I'm saying that broken is broken regardless of the content it's protecting. As to what constitutes "broken" ... I think we agree - that would be SSL. :P
- bensummers 16y ago
  Access to our non-public systems is (partially) controlled through SSL server and client certificates, both of which use a CA we control. This is probably a good practise for systems you are keen on defending, because the public CA system is so broken.
JunkDNA 16y ago
I think there are a lot of site owners who make the mistake of thinking that SSL is only about encryption. They see these certs as a way to prevent data snooping. It's easy to see when a browser doesn't show a little lock icon or warns about an untrusted cert. The identity management side that protects against outright website forgery is harder to police and largely hidden from end users and customers of the CA's. As a result, there is probably insufficient pressure on the CA's to pay attention to some of this stuff.
- tbrownaw 16y ago
  The identity management side that protects against outright website forgery is harder to police and largely hidden from end users and customers of the CA's If it's hidden from end users, how the hell can it actually work? As a result, there is probably insufficient pressure on the CA's to pay attention to some of this stuff. All that matters is the one CA that pays the least attention, and I don't see how site owners have any control over that.
StavrosK 16y ago
I am very much partial to the Perspectives way of doing SSL authentication: http://www.cs.cmu.edu/~perspectives/firefox.html http://www.cs.cmu.edu/~perspectives/firefox.html I don't need to know if the guy has paid someone to sign their certificate, I need to know if that certificate has been there for longer (even if it's self-signed). It's just more valuable information than whether or not a guy has $10. I really hope Perspectives becomes standard in all browsers, then we can slowly migrate away from central signing CAs.
klync 16y ago
I've used a self-signed cert for years, and eventually I got over being annoyed at browsers for lying to users and telling me that the cert was not to be trusted. The fact is, as I'm sure most at HN know, that SSL tries to solve two problems - identity and encryption. We definitely need a better way to validate a site's identity. I hope this study provides a kick in the pants toward that end.
- robryan 16y ago
  It's a tradeoff I guess, at the low end people don't want to provide documents, wait and pay a decent amount to get their identity verified. Maybe it would be best to separate them, you can self sign or equivalent for encryption and the identity system can be separate.
  - Retric 16y ago
    There is little point in encrypting traffic if you can't differentiate between a man in the middle and your desired endpoint. EX: Conceder I open encrypted connection to amazone.com which pretends to be amazon.com they open an encrypted connection to amazon.com. Amazone can now pretend to be Amazon and read all my encrypted traffic.
    - Dylan16807 16y ago
      Consider someone sniffing wifi. I'm worried about eavesdropping much more often than man in the middle, and nontrusted SSL could provide that if browsers would stop freaking out and just go without a padlock.
    - klync 16y ago
      Users can differentiate between "amazon.com" and "amazone.com" via the browser's location bar. There's nothing stopping the owner of "amazone.com" from getting an SSL cert signed by a "trusted authority", so SSL does not help in this respect. My opinion is that conflating identity with encryption is a fundamental problem.

28 points by bensummers 16y ago

rlpb 16y ago

> Of 16 M IPs listening on 443, 10.8 M started SSL handshake; of those, 4.3 M used CA-signed cert chains (slide 14). Thus, the majority of servers use "invalid"/invalid/self-signed certs. How many of these IPs listening on 443 are public web servers? I know of a lot of things that listen for SSL on 443 that aren't HTTP as 443 can get through firewalls easily. For all we know, there already exists an out-of-band process to validate those self-signed certs. For example, I am one of these cases. I listen for SSL on port 443 using a self-signed cert, but all clients have that CA (and only that CA) pre-loaded.

rlpb 16y ago
In addition, it occurs to me that I've observed many sites that aren't security critical but seem to be running on a self-signed cert. For example, many mailing list archives seem to operate both on HTTP and HTTPS with a self-signed cert. As they are only hosting public data and clearly are happy to provide it without SSL as well, there is no security failure here.
- klync 16y ago
  I think you would still have to count that as a security failure. For one, you don't know why there is ssl and non-ssl - there could be content that's available over ssl and/or via login which you don't see using the "public" http url schema. The server could be set up to make this transparent to you, making it appear that ssl is superfluous. Second, even if that's the case, a broken SSL implementation is still a broken SSL implementation, even if it's protecting content that doesn't seem to need protecting.
  - rlpb 16y ago
    > ...a broken SSL implementation is still a broken SSL implementation, even if it's protecting content that doesn't seem to need protecting. That depends on what is required of the SSL implementation. A self-signed cert which the client cannot verify still provides some protection. It is MITM-able, but casual snooping is prevented. If this is the specification, then this implementation is not broken. Put it this way. Forget the specifics of SSL for a moment. If unencrypted data is acceptable, then in what way is having the option of weak-but-slightly-better encryption suddenly "broken"? This analysis is flawed because it assumes that strong security was required by all who use SSL at all. Many installations use a self-signed SSL cert by default. These default configurations often remain when security is not required and therefore not configured further. I suspect that this skews the figures far enough to make this sort of analysis meaningless.
    - klync 16y ago
      Hey rlpb, Sorry, I tried to reply to your post about 4 times yesterday, and it never went through for some reason. I agree with what you're saying about self-signed certs being not necessarily broken. Maybe I mis-read your original message, but what I was objecting to was the idea that a site that apparently has the same content available over http and [broken] https is not a problem; I'm saying that broken is broken regardless of the content it's protecting. As to what constitutes "broken" ... I think we agree - that would be SSL. :P
bensummers 16y ago
Access to our non-public systems is (partially) controlled through SSL server and client certificates, both of which use a CA we control. This is probably a good practise for systems you are keen on defending, because the public CA system is so broken.

JunkDNA 16y ago

I think there are a lot of site owners who make the mistake of thinking that SSL is only about encryption. They see these certs as a way to prevent data snooping. It's easy to see when a browser doesn't show a little lock icon or warns about an untrusted cert. The identity management side that protects against outright website forgery is harder to police and largely hidden from end users and customers of the CA's. As a result, there is probably insufficient pressure on the CA's to pay attention to some of this stuff.

tbrownaw 16y ago
The identity management side that protects against outright website forgery is harder to police and largely hidden from end users and customers of the CA's If it's hidden from end users, how the hell can it actually work? As a result, there is probably insufficient pressure on the CA's to pay attention to some of this stuff. All that matters is the one CA that pays the least attention, and I don't see how site owners have any control over that.

StavrosK 16y ago

I am very much partial to the Perspectives way of doing SSL authentication: http://www.cs.cmu.edu/~perspectives/firefox.html http://www.cs.cmu.edu/~perspectives/firefox.html I don't need to know if the guy has paid someone to sign their certificate, I need to know if that certificate has been there for longer (even if it's self-signed). It's just more valuable information than whether or not a guy has $10. I really hope Perspectives becomes standard in all browsers, then we can slowly migrate away from central signing CAs.

klync 16y ago

I've used a self-signed cert for years, and eventually I got over being annoyed at browsers for lying to users and telling me that the cert was not to be trusted. The fact is, as I'm sure most at HN know, that SSL tries to solve two problems - identity and encryption. We definitely need a better way to validate a site's identity. I hope this study provides a kick in the pants toward that end.

robryan 16y ago
It's a tradeoff I guess, at the low end people don't want to provide documents, wait and pay a decent amount to get their identity verified. Maybe it would be best to separate them, you can self sign or equivalent for encryption and the identity system can be separate.
- Retric 16y ago
  There is little point in encrypting traffic if you can't differentiate between a man in the middle and your desired endpoint. EX: Conceder I open encrypted connection to amazone.com which pretends to be amazon.com they open an encrypted connection to amazon.com. Amazone can now pretend to be Amazon and read all my encrypted traffic.
  - Dylan16807 16y ago
    Consider someone sniffing wifi. I'm worried about eavesdropping much more often than man in the middle, and nontrusted SSL could provide that if browsers would stop freaking out and just go without a padlock.
  - klync 16y ago
    Users can differentiate between "amazon.com" and "amazone.com" via the browser's location bar. There's nothing stopping the owner of "amazone.com" from getting an SSL cert signed by a "trusted authority", so SSL does not help in this respect. My opinion is that conflating identity with encryption is a fundamental problem.