6 ms·

The Internet's Secret Back Door

34 points by jancona 16y ago

devmonk 16y ago
Interesting. Also interesting was that SSL has been hacked before, although I've not heard much about it after then. For example: http://hackaday.com/2008/12/30/25c3-hackers-completely-break-ssl-using-200-ps3s/ http://hackaday.com/2008/12/30/25c3-hackers-completely-break...
RiderOfGiraffes 16y ago
Dup: http://news.ycombinator.com/item?id=1640117 http://news.ycombinator.com/item?id=1640117 Having said that - no comments there.
- bensummers 16y ago
  Dup detection isn't terribly good here. Trailing /'s, Google Analytics link-junk all aren't detected.
  - kngspook 16y ago
    The source code for the news.yc website is open source, right? We should patch it...
    - RiderOfGiraffes 16y ago
      I'm pretty sure the live version has mods that aren't in the public version. PG has said that he makes mods to improve various aspects, particularly things like detecting voting rings and other such gaming of the system.
augustl 16y ago
I don't understand how SSL can be secure. Aren't the keys for encrypting and decrypting transferred in the open before encryption can take place? If so, isn't a man-in-the-middle able to snoop those keys?
- asmithmd1 16y ago
  I like this analogy for how keys are exchanged and never exposed in transit: I put my secret in a box and put a lock on it for which only I have the key and ship the box to you. When you receive the box you put your own lock on the box for which only you have the key and send the box now with two locks back to me. When I get the box I take my lock off and send it back to you. Finally you open the box by taking your lock off. The box is always locked in transit and no keys were ever out of the owners hands.
  - augustl 16y ago
    Great! This explanation was worth the downvotes my post got :)
  - electromagnetic 16y ago
    Thank you, this is one of the most succinct explanations I've read. I understood how it worked in a roundabout concept, but you made the explanation simple like it should be.
  - brownleej 16y ago
    I don't think this is the method SSL uses, because what you're describing is just a variant of symmetric-key encryption. I think SSL uses asymmetric-key encryption. The better metaphor for that is a lock that anyone can lock, but only one person can unlock.
    - jacobolus 16y ago
      That’s how SSL/TLS does the authorization step, but the typical encryption of the actual content sent back and forth uses a symmetric-key block cipher (the two sides negotiate and it’s pretty modular, so I think you can do whatever kind of encryption you want on the messages, even just sending plain text after a TLS handshake if you want). See http://en.wikipedia.org/wiki/Cipher_suite http://en.wikipedia.org/wiki/Cipher_suite
      - 16y ago
kenj0418 16y ago
Was anyone else scared that the link was to goatse?
shaggy 16y ago
"Whenever you're sending sensitive information online—say, your credit card number to Amazon or a message over Gmail—the content is encrypted before being sent and then decrypted by the Web site you sent it to. (Sites using this secure mode have URLs that start with "https," and browsers add a padlock icon as well to demonstrate you're communicating securely.) Every vendor has its own rules for how to scramble information so that only it, the intended recipient, can decode it." SSL does not encrypt content and vendors don't all ahve their own rules about how SSL works. It's a standard. I really wish that journalists covering technical matters would do enough research to explain things properly.
jleader 16y ago
I don't know enough about certificate revocation lists (CRLs) to be sure, but isn't it possible for individual browser users to import them? In that case, couldn't the EFF or similar organizations take matters into their own hands, and release lists of certificates they think users should be cautious about? I suspect libel laws make this more difficult, but perhaps not impossible, if revocation providers are careful not to overstate their case, but just say "here's a list of certificates of organizations who have been documented to meet the following criteria...". [Edited to add:] http://en.wikipedia.org/wiki/Revocation_list#Publishing_Revocation_Lists http://en.wikipedia.org/wiki/Revocation_list#Publishing_Revo... says that "To prevent spoofing or denial-of-service attacks, CRLs usually carry a digital signature associated with the CA by which they are published. To validate a specific CRL prior to relying on it, the certificate of its corresponding CA is needed, which can usually be found in a public directory." It's not clear whether the browser checks this signature, or whether the user is expected to. In the latter case, a CRL could be signed by the 3rd party revocation provider instead.
js2 16y ago
tl;dr - the article is about the susceptibility of SSL protected websites to man-in-the-middle attacks due to the CA trust model being only as strong as the least competent/trustworthy CA that a given browser, well, trusts. Background: Browsers check for a man-in-the-middle attack by verifying that: a) remote site's certificate is signed by a certificate authority (CA) that the browser trusts; b) the URL matches the common-name attribute (CN) in the site's certificate. So, for an attacker to get around this check, they need to: a) forge/spoof DNS (relatively easy); b) get a cert signed by a CA the browser trusts with a matching CN of the site to be spoofed (supposed to be relatively hard). (There is also Extended Validation, I won't go into that here.) Unfortunately, these days, browsers trust _a lot_ of CA's, either directly or via chained certificates. Some of these chained certificates may be surprising to you. https://www.eff.org/observatory https://www.eff.org/observatory
- tptacek 16y ago
  The good news is that this isn't a problem with the SSL protocol so much as it is a problem with how the CA's and browser vendors have decided to configure SSL. Which means you can fix a lot of this by removing certs from your browser configuration.
thyrsus 16y ago
So long as Verizon happily issues new CAs to Etisalat, the following is a weak measure, but for the moment: is there a way in various browsers to declare that you don't trust specific CAs? I can't practically remove the Verizon certificate (in my Certificate Authorities tab, I don't see Verizon, but I do see GTE Corporation which was its previous name, so I'll guess they're the same...), but could I declare "don't trust certificates containing these certificates"?
- kngspook 16y ago
  Yeah, you can usually delete certs, at least in third-party browsers, even if they're built in. I'm not sure if you can delete any of the OS's built-in certs ('cept maybe on Linux); and I'm not sure I'd want to risk that. Verizon/GTE/whoever probably authenticates a lot of really useful people too... (Which is a risk with deleting the browser's root certs as well.)

34 points by jancona 16y ago

Interesting. Also interesting was that SSL has been hacked before, although I've not heard much about it after then. For example: http://hackaday.com/2008/12/30/25c3-hackers-completely-break-ssl-using-200-ps3s/ http://hackaday.com/2008/12/30/25c3-hackers-completely-break...

RiderOfGiraffes 16y ago

Dup: http://news.ycombinator.com/item?id=1640117 http://news.ycombinator.com/item?id=1640117 Having said that - no comments there.

bensummers 16y ago
Dup detection isn't terribly good here. Trailing /'s, Google Analytics link-junk all aren't detected.
- kngspook 16y ago
  The source code for the news.yc website is open source, right? We should patch it...
  - RiderOfGiraffes 16y ago
    I'm pretty sure the live version has mods that aren't in the public version. PG has said that he makes mods to improve various aspects, particularly things like detecting voting rings and other such gaming of the system.

augustl 16y ago

I don't understand how SSL can be secure. Aren't the keys for encrypting and decrypting transferred in the open before encryption can take place? If so, isn't a man-in-the-middle able to snoop those keys?

asmithmd1 16y ago
I like this analogy for how keys are exchanged and never exposed in transit: I put my secret in a box and put a lock on it for which only I have the key and ship the box to you. When you receive the box you put your own lock on the box for which only you have the key and send the box now with two locks back to me. When I get the box I take my lock off and send it back to you. Finally you open the box by taking your lock off. The box is always locked in transit and no keys were ever out of the owners hands.
- augustl 16y ago
  Great! This explanation was worth the downvotes my post got :)
- electromagnetic 16y ago
  Thank you, this is one of the most succinct explanations I've read. I understood how it worked in a roundabout concept, but you made the explanation simple like it should be.
- brownleej 16y ago
  I don't think this is the method SSL uses, because what you're describing is just a variant of symmetric-key encryption. I think SSL uses asymmetric-key encryption. The better metaphor for that is a lock that anyone can lock, but only one person can unlock.
  - jacobolus 16y ago
    That’s how SSL/TLS does the authorization step, but the typical encryption of the actual content sent back and forth uses a symmetric-key block cipher (the two sides negotiate and it’s pretty modular, so I think you can do whatever kind of encryption you want on the messages, even just sending plain text after a TLS handshake if you want). See http://en.wikipedia.org/wiki/Cipher_suite http://en.wikipedia.org/wiki/Cipher_suite
    - 16y ago

kenj0418 16y ago

Was anyone else scared that the link was to goatse?

shaggy 16y ago

"Whenever you're sending sensitive information online—say, your credit card number to Amazon or a message over Gmail—the content is encrypted before being sent and then decrypted by the Web site you sent it to. (Sites using this secure mode have URLs that start with "https," and browsers add a padlock icon as well to demonstrate you're communicating securely.) Every vendor has its own rules for how to scramble information so that only it, the intended recipient, can decode it." SSL does not encrypt content and vendors don't all ahve their own rules about how SSL works. It's a standard. I really wish that journalists covering technical matters would do enough research to explain things properly.

jleader 16y ago

I don't know enough about certificate revocation lists (CRLs) to be sure, but isn't it possible for individual browser users to import them? In that case, couldn't the EFF or similar organizations take matters into their own hands, and release lists of certificates they think users should be cautious about? I suspect libel laws make this more difficult, but perhaps not impossible, if revocation providers are careful not to overstate their case, but just say "here's a list of certificates of organizations who have been documented to meet the following criteria...". [Edited to add:] http://en.wikipedia.org/wiki/Revocation_list#Publishing_Revocation_Lists http://en.wikipedia.org/wiki/Revocation_list#Publishing_Revo... says that "To prevent spoofing or denial-of-service attacks, CRLs usually carry a digital signature associated with the CA by which they are published. To validate a specific CRL prior to relying on it, the certificate of its corresponding CA is needed, which can usually be found in a public directory." It's not clear whether the browser checks this signature, or whether the user is expected to. In the latter case, a CRL could be signed by the 3rd party revocation provider instead.

js2 16y ago

tl;dr - the article is about the susceptibility of SSL protected websites to man-in-the-middle attacks due to the CA trust model being only as strong as the least competent/trustworthy CA that a given browser, well, trusts. Background: Browsers check for a man-in-the-middle attack by verifying that: a) remote site's certificate is signed by a certificate authority (CA) that the browser trusts; b) the URL matches the common-name attribute (CN) in the site's certificate. So, for an attacker to get around this check, they need to: a) forge/spoof DNS (relatively easy); b) get a cert signed by a CA the browser trusts with a matching CN of the site to be spoofed (supposed to be relatively hard). (There is also Extended Validation, I won't go into that here.) Unfortunately, these days, browsers trust _a lot_ of CA's, either directly or via chained certificates. Some of these chained certificates may be surprising to you. https://www.eff.org/observatory https://www.eff.org/observatory

tptacek 16y ago
The good news is that this isn't a problem with the SSL protocol so much as it is a problem with how the CA's and browser vendors have decided to configure SSL. Which means you can fix a lot of this by removing certs from your browser configuration.

thyrsus 16y ago

So long as Verizon happily issues new CAs to Etisalat, the following is a weak measure, but for the moment: is there a way in various browsers to declare that you don't trust specific CAs? I can't practically remove the Verizon certificate (in my Certificate Authorities tab, I don't see Verizon, but I do see GTE Corporation which was its previous name, so I'll guess they're the same...), but could I declare "don't trust certificates containing these certificates"?

kngspook 16y ago
Yeah, you can usually delete certs, at least in third-party browsers, even if they're built in. I'm not sure if you can delete any of the OS's built-in certs ('cept maybe on Linux); and I'm not sure I'd want to risk that. Verizon/GTE/whoever probably authenticates a lot of really useful people too... (Which is a risk with deleting the browser's root certs as well.)