4 ms·

The whole system, now close to 20 years old, needs a reboot. I know, that's easy for me to say. But it's showing its age, and could really benefit from a comple

The whole system, now close to 20 years old, needs a reboot. I know, that's easy for me to say. But it's showing its age, and could really benefit from a complete rethink.

lmm 13y ago
Do you have specific criticisms? In cryptography, a system that has withstood scrutiny for that long is a rare and exceedingly valuable thing. By all means use it as the ugly foundations that you hide beneath the beautiful edifice on top, but throwing it away would be madness.
- area51org 13y ago
  You're right, I'm being vague. I'm looking for two things, really: 1- simpler implementation — one that is easier for users to understand, and includes client certs by default 2- one with a re-engineered cryptographic implementation, one less likely to have the kind of numerous security flaws that have been uncovered in SSL/TLS over the years SSL was originally meant to serve two purposes: 1- encrypt communication 2- verify, through a trusted 3rd party, that the remote service you're contacting is actually who it says it is Most laymen, and many technologists, do not know that #2 even exists. Worse, this authentication portion has been all but destroyed by liberal certificate authorities like GoDaddy. From my experience, anyone can get a certificate for a domain without any kind of check to see if you have the right to use that domain. So, in theory, you could register "amaz0n.com" with GoDaddy, get a cert for it, and start using it, without any kind of background check. In the early days (when Verisign was the only CA in town), a business had to supply a Dunn & Bradstreet number and be subject to other background checking before being issued a CA-signed cert. If that sounds heavy-handed, it shouldn't: Verisign was supposed to have the users' backs. If you tried to get a cert for Amaz0n.com, it would have been rejected unless you could prove you actually are Amazon.com. I think that kind of authentication has a real place on the modern Internet. edit: formatting
  - lmm 13y ago
    >1- simpler implementation — one that is easier for users to understand, and includes client certs by default I'm not sure what you're suggesting. A nicer UI would definitely be a good idea, but you can do that without changing the underlying crypto implementation. >2- one with a re-engineered cryptographic implementation, one less likely to have the kind of numerous security flaws that have been uncovered in SSL/TLS over the years That's not how you get secure cryptography. You need not just a secure algorithm but a secure implementation, one resistant to timing attacks, compression attacks, and all sorts of nonobvious things. OpenSSL is far from developer-friendly, but the vulnerabilities have been hammered out over those 20 years, and there is a body of knowledge on how to use it securely. A new implementation would have to go through that all over again. >From my experience, anyone can get a certificate for a domain without any kind of check to see if you have the right to use that domain. So, in theory, you could register "amaz0n.com" with GoDaddy, get a cert for it, and start using it, without any kind of background check. In the early days (when Verisign was the only CA in town), a business had to supply a Dunn & Bradstreet number and be subject to other background checking before being issued a CA-signed cert. If that sounds heavy-handed, it shouldn't: Verisign was supposed to have the users' backs. If you tried to get a cert for Amaz0n.com, it would have been rejected unless you could prove you actually are Amazon.com. True enough, but fixing that doesn't require any changes to SSL itself - you just have to curate the list of root certificates the browser trusts more carefully.
  - spc476 13y ago
    I've been playing around with DJB's NaCl (http://nacl.cr.yp.to/ http://nacl.cr.yp.to/) and have found it to be a very easy API to use (if a bit quirky to install). Using this, I've come to the conclusion that the actual cryptography is trivial compared to key management ("trivial" in the meaning "it's done and proven, it should be easy to use," not in the "anybody can write their own encryption system").
  - Aqua_Geek 13y ago
    Verisign still verifies - at least to some extent. Last time I got a cert I had to take my business registration stuff to a notary and get them to notarize a statement to the effect that I am who I say I am, etc.
- toyg 13y ago
  I wouldn't say SSL "withstood scrutiny" after all. We now know that state actors routinely MIM popular services with rogue keys (Iran, Turkey, Egypt, China and Syria are the ones we know about), and are happy to steal keys to distribute malware (US/Israel with Stuxnet). It was fairly robust in the 90s when knowledge was scarce, but as malicious actors got more confident with the technology, it started to show the cracks. Now with PRISM and total global surveillance becoming a sad reality, we could certainly do with more decentralized approaches and (ideally) overcoming the "authority" paradigm (but this will likely remain a dream).
  - jerf 13y ago
    Those are weaknesses in the signing authorities. Signing authorities are a layer of SSL, and a rather high one. It is possible to use SSL without them. I have an app I've written that uses SSL, and since it's essentially one thing we own talking to another thing we own (from a security perspective), there's no signing authority, no Verisign, no NSA, just, is this the exact SSL cert we issued to this SSL user or not? Not that there aren't other problems at times with SSL, especially depending on how you use it, but your criticism may be more limited than you realize.
- sanderjd 13y ago
  I think the strongest criticism is that nobody on the mainstream internet is using this stuff. I'm not sure what your parent meant by a "complete reboot", but my interpretation is that all of the user experience needs a reboot, not the underlying crytpo.

The whole system, now close to 20 years old, needs a reboot. I know, that's easy for me to say. But it's showing its age, and could really benefit from a complete rethink.

lmm 13y ago

Do you have specific criticisms? In cryptography, a system that has withstood scrutiny for that long is a rare and exceedingly valuable thing. By all means use it as the ugly foundations that you hide beneath the beautiful edifice on top, but throwing it away would be madness.

area51org 13y ago
You're right, I'm being vague. I'm looking for two things, really: 1- simpler implementation — one that is easier for users to understand, and includes client certs by default 2- one with a re-engineered cryptographic implementation, one less likely to have the kind of numerous security flaws that have been uncovered in SSL/TLS over the years SSL was originally meant to serve two purposes: 1- encrypt communication 2- verify, through a trusted 3rd party, that the remote service you're contacting is actually who it says it is Most laymen, and many technologists, do not know that #2 even exists. Worse, this authentication portion has been all but destroyed by liberal certificate authorities like GoDaddy. From my experience, anyone can get a certificate for a domain without any kind of check to see if you have the right to use that domain. So, in theory, you could register "amaz0n.com" with GoDaddy, get a cert for it, and start using it, without any kind of background check. In the early days (when Verisign was the only CA in town), a business had to supply a Dunn & Bradstreet number and be subject to other background checking before being issued a CA-signed cert. If that sounds heavy-handed, it shouldn't: Verisign was supposed to have the users' backs. If you tried to get a cert for Amaz0n.com, it would have been rejected unless you could prove you actually are Amazon.com. I think that kind of authentication has a real place on the modern Internet. edit: formatting
- lmm 13y ago
  >1- simpler implementation — one that is easier for users to understand, and includes client certs by default I'm not sure what you're suggesting. A nicer UI would definitely be a good idea, but you can do that without changing the underlying crypto implementation. >2- one with a re-engineered cryptographic implementation, one less likely to have the kind of numerous security flaws that have been uncovered in SSL/TLS over the years That's not how you get secure cryptography. You need not just a secure algorithm but a secure implementation, one resistant to timing attacks, compression attacks, and all sorts of nonobvious things. OpenSSL is far from developer-friendly, but the vulnerabilities have been hammered out over those 20 years, and there is a body of knowledge on how to use it securely. A new implementation would have to go through that all over again. >From my experience, anyone can get a certificate for a domain without any kind of check to see if you have the right to use that domain. So, in theory, you could register "amaz0n.com" with GoDaddy, get a cert for it, and start using it, without any kind of background check. In the early days (when Verisign was the only CA in town), a business had to supply a Dunn & Bradstreet number and be subject to other background checking before being issued a CA-signed cert. If that sounds heavy-handed, it shouldn't: Verisign was supposed to have the users' backs. If you tried to get a cert for Amaz0n.com, it would have been rejected unless you could prove you actually are Amazon.com. True enough, but fixing that doesn't require any changes to SSL itself - you just have to curate the list of root certificates the browser trusts more carefully.
- spc476 13y ago
  I've been playing around with DJB's NaCl (http://nacl.cr.yp.to/ http://nacl.cr.yp.to/) and have found it to be a very easy API to use (if a bit quirky to install). Using this, I've come to the conclusion that the actual cryptography is trivial compared to key management ("trivial" in the meaning "it's done and proven, it should be easy to use," not in the "anybody can write their own encryption system").
- Aqua_Geek 13y ago
  Verisign still verifies - at least to some extent. Last time I got a cert I had to take my business registration stuff to a notary and get them to notarize a statement to the effect that I am who I say I am, etc.
toyg 13y ago
I wouldn't say SSL "withstood scrutiny" after all. We now know that state actors routinely MIM popular services with rogue keys (Iran, Turkey, Egypt, China and Syria are the ones we know about), and are happy to steal keys to distribute malware (US/Israel with Stuxnet). It was fairly robust in the 90s when knowledge was scarce, but as malicious actors got more confident with the technology, it started to show the cracks. Now with PRISM and total global surveillance becoming a sad reality, we could certainly do with more decentralized approaches and (ideally) overcoming the "authority" paradigm (but this will likely remain a dream).
- jerf 13y ago
  Those are weaknesses in the signing authorities. Signing authorities are a layer of SSL, and a rather high one. It is possible to use SSL without them. I have an app I've written that uses SSL, and since it's essentially one thing we own talking to another thing we own (from a security perspective), there's no signing authority, no Verisign, no NSA, just, is this the exact SSL cert we issued to this SSL user or not? Not that there aren't other problems at times with SSL, especially depending on how you use it, but your criticism may be more limited than you realize.
sanderjd 13y ago
I think the strongest criticism is that nobody on the mainstream internet is using this stuff. I'm not sure what your parent meant by a "complete reboot", but my interpretation is that all of the user experience needs a reboot, not the underlying crytpo.