4 ms·

SSL snake oil. SSL and the percieved trust around it has to die. It's a big lie, especially with broken CAs, lax security, poor encryption due to internationa

SSL snake oil. SSL and the percieved trust around it has to die. It's a big lie, especially with broken CAs, lax security, poor encryption due to international policy and several technical and conceptual flaws. Some critique here to back me up: http://www.theregister.co.uk/2011/04/11/state_of_ssl_analysis/ http://www.theregister.co.uk/2011/04/11/state_of_ssl_analysi...

ebiester 15y ago
Okay, so SSL dies. it's gone. Kaput. Now what? I get that a false sense of security is worse, but we haven't yet figured out a better way that is still decentralized and works with a wide variety of user skill levels. Because people who aren't expert users deserve security too. And they deserve functionality.
- pointyhat 15y ago
  SSL was never decentralised. It was always centralised with CA's which is the issue. We need a reputation based, distributed public key architecture.
  - tptacek 15y ago
    So build one. Your preference actually has very little to do with the X509 CA architecture. Today we have a complex little forest of fiat CAs. No part of the TLS architecture prevents you from replacing that with an even more complex and more full-featured web of smaller CAs. I'm not being sarcastic. Your decentralized reputation scheme could very well be better than our severely compromised system of central CAs.
- pnathan 15y ago
  people who aren't expert users deserve security too. And they deserve functionality. Well, SSL certainly isn't giving serious security in the "My ISP has been intruded" attack model. You can't have both security and ignorance. If you really want to be secure, you're going to have to learn how to be secure, and then to know how to implement it.
  - tptacek 15y ago
    Your ISP can be completely compromised and SSL/TLS will continue to work, even in its broken incarnation in your browser configuration.
    - pnathan 15y ago
      Umm. What do you mean by work? If my ISP injects certain proxies in my route, they can unwrap the encrypted communication.
      - tptacek 15y ago
        No they can't. That's not how TLS works. The problem we are talking about is not that SSL/TLS- the- protocol allows ISPs to decrypt traffic. It's that some browsers have been shipped with a certificate authority that is willing to sign Google CN's. Remove that CA's cert. What's your ISP going to do now?
        pnathan 15y ago
        A brief search for TLS MITM suggests to my inexperienced eye that there are indeed TLS attacks via MITM cert-swapping that the ISP can assert. --- edit. Not looking for argument. Looking for facts. - This is my top hit for 'tls mitm proxy' http://www.delegate.org/delegate/mitm/ http://www.delegate.org/delegate/mitm/ It's dated as '06, however. - I can install Fiddler (Windows https debugger) on my machine and read https traffic in the clear. - A competent admin assures me that Websense can read https traffic. Couldn't really dig real detail up on the websense sites though. This chap suggests the admin is not wrong (search for corporate, it's toward the end): http://www.carbonwind.net/blog/post/Random-SSLTLS-101%E2%80%93SSLTLS-version-rollbacks-and-browsers.aspx http://www.carbonwind.net/blog/post/Random-SSLTLS-101%E2%80%...
        tptacek 15y ago
        I have no idea how I might go about arguing with you; it's as if I were to argue "a brief search of the literature suggests that P is definitely NP". Give me something more specific and I'll give you the context behind it; right now, I don't know what you're talking about. (Sigh). Fiddler pops the browser certificate warning when you use it; it's not breaking TLS. You must just as productively say "my friend assures me AES is broken; maybe that's what Iran is doing." Just like your competent admin friend, there would be some reason for him to say that; it just wouldn't be relevant.
pyre 15y ago
And the solution is? Getting everyone on to PGP/GPG? Explaining to the general public what a web of trust is and actually get them to use it in the correct fashion (rather then clicking 'trust' the same way they click through all dialog boxes)?
- pointyhat 15y ago
  SSL leads them into that already but clicking the "trust" button automatically. We need a reputation based, distributed public key architecture.
- beaumartinez 15y ago
  DNSSEC is an alternative. (Edit: Well, not really—have a look at the thread below.)
  - tptacek 15y ago
    In what sense? DNSSEC is also a PKI which also has roots that can be compromised. Not only that, but it only works server-to-server (late in the game, we've decided "that's OK, everyone will just be a server!). And DNSSEC relies on HTTPS/TLS to actually protect content.
    - beaumartinez 15y ago
      With DNSSEC when you request google.com you can verify the answer is actually google.com. (Edit: You can verify the validity of the DNS answer.) No cryptographic system is perfect.
      - deleted 15y ago
        [deleted]
      - tptacek 15y ago
        This comment is tautological. The verification you're talking about works on the same principle as X.509 (SSL/TLS) does; all it does is attempt to give individual DNS zone holders the ability to sign their own names. But every zone has a parent zone upon whose security it depends. The reality is that DNSSEC is a lot more fragile than even that. Even on paper (DNSSEC hasn't been deployed in the large successfully) it has gaps. For instance, did you know that as conceived in the standards, your browser isn't even meant to speak DNSSEC? Your browser doesn't run a full recursive cache --- in other words, your browser isn't a full DNS name server, which is why your computer has to be configured with the address of a name server. DNSSEC doesn't secure the leg between your computer and its name server. "No cryptographic system is perfect" is a worthless sentiment. Only in the rarest instances do we know whether any system, from "hello world" to the Tacoma Narrows, is absolutely sound. Our job as engineers is to make determinations about which system is sounder. DNSSEC takes approximately the same architectural problems that X.509 has, rebuilds them from scratch in the context of a protocol that has for 20 years been riven with security flaws, and then still requires HTTPS/TLS to function. It is less sound than HTTPS/TLS.
tptacek 15y ago
So you don't like the way SSL/TLS is configured in your browser and therefore we should throw out 15+ years of intense study for whatever flavor-of-the-month protocol is most popular when everyone agrees with you? How about instead of "SSL sucks!", you propose things that will (from your vantage point) improve SSL/TLS? What, so you don't like that Mozilla gets to dictate what all the trust roots are? Neither do I. But that is not one of the worlds great compute or UX problems to solve. Propose a solution. It's a virulent misconception that the SSL/TLS security model depends on Verisign and Thawte. The only place in the whole model we have that dependency is your browser's configuration and that stupid dialog it shows when a cert doesn't check out. You can replace just those two parts and get virtually any other trust model you want.
- pointyhat 15y ago
  Yes I'd quite happily throw out 15+ years of intense study and research (inclusing SSL/TLS) as it occasionally breaks down and kicks you in the face (google for TLS MITM vulns). There should be an explicit trust model where the service vendor ships your keys via an alternative side channel -or- a decentralised model which works on reputation or trust. If it works, why do all the online banks use two-factor authentication these days? Oh wait, there is the solution!
  - tptacek 15y ago
    At the current rate of discovery, every vulnerability in TLS should make you more confident in the protocol. We're running an average of 3-5 years between protocol-level discoveries in TLS. Each one is the product of, literally, millions and millions of dollars of adversarial research. Psst. I've got news for you. adb56780a76686326612a1eb3c2b32053bbcf3d8. Ask a friendly vulnerability researcher what I probably meant by saying that. Guess what? More confident as a result of knowing it. The rest of your comment is just pique. "Why do online banks use two-factor auth?" Because the alternative is passwords. "There should be an explicit trust model!" Go ahead and build it. Because TLS is well-designed, your new scheme will work just fine with it.
    - 15y ago
burgerbrain 15y ago
As I understand it, SSL (or TLS more properly) is fine, it's the HTTPS system and it's trust model that are broken. </pedantic>
pnathan 15y ago
The idea of having a distributed certificate mechanism over a peer to peer net seems like it might be a good starting point. Essentially, you'd self-sign and serve out your certificate on your ports; possibly connecting to some sort of super-node. You get connections from other members of the net, and they'd send you some certificates; you'd cache the certs and their IP addresses. Then after a timeout, you'd broadcast your certificates to all the interested IPs. Part of the intrinsic concept is that there's no authoritative identity service. Without an authority, you can't crack the authority. Of course, this is just a sketch of an idea; it has the usual issues with peer to peer nets such as "evil majority wins". Plus, it has the potential to eat a good deal of bandwidth. Regardless, I think it'd be a good idea to explore, probably in an academic setting first.

ebiester 15y ago

Okay, so SSL dies. it's gone. Kaput. Now what? I get that a false sense of security is worse, but we haven't yet figured out a better way that is still decentralized and works with a wide variety of user skill levels. Because people who aren't expert users deserve security too. And they deserve functionality.

pointyhat 15y ago
SSL was never decentralised. It was always centralised with CA's which is the issue. We need a reputation based, distributed public key architecture.
- tptacek 15y ago
  So build one. Your preference actually has very little to do with the X509 CA architecture. Today we have a complex little forest of fiat CAs. No part of the TLS architecture prevents you from replacing that with an even more complex and more full-featured web of smaller CAs. I'm not being sarcastic. Your decentralized reputation scheme could very well be better than our severely compromised system of central CAs.
pnathan 15y ago
people who aren't expert users deserve security too. And they deserve functionality. Well, SSL certainly isn't giving serious security in the "My ISP has been intruded" attack model. You can't have both security and ignorance. If you really want to be secure, you're going to have to learn how to be secure, and then to know how to implement it.
- tptacek 15y ago
  Your ISP can be completely compromised and SSL/TLS will continue to work, even in its broken incarnation in your browser configuration.
  - pnathan 15y ago
    Umm. What do you mean by work? If my ISP injects certain proxies in my route, they can unwrap the encrypted communication.
    - tptacek 15y ago
      No they can't. That's not how TLS works. The problem we are talking about is not that SSL/TLS- the- protocol allows ISPs to decrypt traffic. It's that some browsers have been shipped with a certificate authority that is willing to sign Google CN's. Remove that CA's cert. What's your ISP going to do now?
      - pnathan 15y ago
        A brief search for TLS MITM suggests to my inexperienced eye that there are indeed TLS attacks via MITM cert-swapping that the ISP can assert. --- edit. Not looking for argument. Looking for facts. - This is my top hit for 'tls mitm proxy' http://www.delegate.org/delegate/mitm/ http://www.delegate.org/delegate/mitm/ It's dated as '06, however. - I can install Fiddler (Windows https debugger) on my machine and read https traffic in the clear. - A competent admin assures me that Websense can read https traffic. Couldn't really dig real detail up on the websense sites though. This chap suggests the admin is not wrong (search for corporate, it's toward the end): http://www.carbonwind.net/blog/post/Random-SSLTLS-101%E2%80%93SSLTLS-version-rollbacks-and-browsers.aspx http://www.carbonwind.net/blog/post/Random-SSLTLS-101%E2%80%...
        tptacek 15y ago
        I have no idea how I might go about arguing with you; it's as if I were to argue "a brief search of the literature suggests that P is definitely NP". Give me something more specific and I'll give you the context behind it; right now, I don't know what you're talking about. (Sigh). Fiddler pops the browser certificate warning when you use it; it's not breaking TLS. You must just as productively say "my friend assures me AES is broken; maybe that's what Iran is doing." Just like your competent admin friend, there would be some reason for him to say that; it just wouldn't be relevant.

pyre 15y ago

And the solution is? Getting everyone on to PGP/GPG? Explaining to the general public what a web of trust is and actually get them to use it in the correct fashion (rather then clicking 'trust' the same way they click through all dialog boxes)?

pointyhat 15y ago
SSL leads them into that already but clicking the "trust" button automatically. We need a reputation based, distributed public key architecture.
beaumartinez 15y ago
DNSSEC is an alternative. (Edit: Well, not really—have a look at the thread below.)
- tptacek 15y ago
  In what sense? DNSSEC is also a PKI which also has roots that can be compromised. Not only that, but it only works server-to-server (late in the game, we've decided "that's OK, everyone will just be a server!). And DNSSEC relies on HTTPS/TLS to actually protect content.
  - beaumartinez 15y ago
    With DNSSEC when you request google.com you can verify the answer is actually google.com. (Edit: You can verify the validity of the DNS answer.) No cryptographic system is perfect.
    - deleted 15y ago
      [deleted]
    - tptacek 15y ago
      This comment is tautological. The verification you're talking about works on the same principle as X.509 (SSL/TLS) does; all it does is attempt to give individual DNS zone holders the ability to sign their own names. But every zone has a parent zone upon whose security it depends. The reality is that DNSSEC is a lot more fragile than even that. Even on paper (DNSSEC hasn't been deployed in the large successfully) it has gaps. For instance, did you know that as conceived in the standards, your browser isn't even meant to speak DNSSEC? Your browser doesn't run a full recursive cache --- in other words, your browser isn't a full DNS name server, which is why your computer has to be configured with the address of a name server. DNSSEC doesn't secure the leg between your computer and its name server. "No cryptographic system is perfect" is a worthless sentiment. Only in the rarest instances do we know whether any system, from "hello world" to the Tacoma Narrows, is absolutely sound. Our job as engineers is to make determinations about which system is sounder. DNSSEC takes approximately the same architectural problems that X.509 has, rebuilds them from scratch in the context of a protocol that has for 20 years been riven with security flaws, and then still requires HTTPS/TLS to function. It is less sound than HTTPS/TLS.

tptacek 15y ago

So you don't like the way SSL/TLS is configured in your browser and therefore we should throw out 15+ years of intense study for whatever flavor-of-the-month protocol is most popular when everyone agrees with you? How about instead of "SSL sucks!", you propose things that will (from your vantage point) improve SSL/TLS? What, so you don't like that Mozilla gets to dictate what all the trust roots are? Neither do I. But that is not one of the worlds great compute or UX problems to solve. Propose a solution. It's a virulent misconception that the SSL/TLS security model depends on Verisign and Thawte. The only place in the whole model we have that dependency is your browser's configuration and that stupid dialog it shows when a cert doesn't check out. You can replace just those two parts and get virtually any other trust model you want.

pointyhat 15y ago
Yes I'd quite happily throw out 15+ years of intense study and research (inclusing SSL/TLS) as it occasionally breaks down and kicks you in the face (google for TLS MITM vulns). There should be an explicit trust model where the service vendor ships your keys via an alternative side channel -or- a decentralised model which works on reputation or trust. If it works, why do all the online banks use two-factor authentication these days? Oh wait, there is the solution!
- tptacek 15y ago
  At the current rate of discovery, every vulnerability in TLS should make you more confident in the protocol. We're running an average of 3-5 years between protocol-level discoveries in TLS. Each one is the product of, literally, millions and millions of dollars of adversarial research. Psst. I've got news for you. adb56780a76686326612a1eb3c2b32053bbcf3d8. Ask a friendly vulnerability researcher what I probably meant by saying that. Guess what? More confident as a result of knowing it. The rest of your comment is just pique. "Why do online banks use two-factor auth?" Because the alternative is passwords. "There should be an explicit trust model!" Go ahead and build it. Because TLS is well-designed, your new scheme will work just fine with it.
  - 15y ago

burgerbrain 15y ago

As I understand it, SSL (or TLS more properly) is fine, it's the HTTPS system and it's trust model that are broken. </pedantic>

pnathan 15y ago

The idea of having a distributed certificate mechanism over a peer to peer net seems like it might be a good starting point. Essentially, you'd self-sign and serve out your certificate on your ports; possibly connecting to some sort of super-node. You get connections from other members of the net, and they'd send you some certificates; you'd cache the certs and their IP addresses. Then after a timeout, you'd broadcast your certificates to all the interested IPs. Part of the intrinsic concept is that there's no authoritative identity service. Without an authority, you can't crack the authority. Of course, this is just a sketch of an idea; it has the usual issues with peer to peer nets such as "evil majority wins". Plus, it has the potential to eat a good deal of bandwidth. Regardless, I think it'd be a good idea to explore, probably in an academic setting first.