2 ms·

When applications use a custom or nondefault configuration, most of the time the result is indeed less secure. The classic example is lazy developers doing thi

by comex 10y ago

When applications use a custom or nondefault configuration, most of the time the result is indeed less secure. The classic example is lazy developers doing things like turning off CURLOPT_SSL_VERIFYPEER, but it goes beyond that. Most application developers have no opinion on what ciphersuites are good, but OpenSSL forces you to choose, and chances are that choice will be hardcoded somewhere and never updated. (Other TLS libraries do this better.) Browsers lately have been imposing conditions on individual root CAs that are more complex than a binary trust/distrust. For example, they have added artificial TLD limits, certificate transparency requirements, or more complex stuff designed to address specific instances of bad behavior by CAs (take a look at mozilla.dev.security.policy). There's no good way to implement that systemwide if there are N different SSL libraries in use, often statically linked, with their own configurations. So you end up with the restrictions only being applied to the browser. Which is less secure. That's the situation today. Of course, any given issue can be solved many different ways, and there are less disruptive approaches to improving them than what I'm suggesting. My suggested approach is far from necessary, and indeed is unlikely to happen in reality. But you seem to have a gut distaste for it which doesn't resonate with me. As for server programs "coughing up" private credentials, it's quite the reverse: the administrator doesn't have to stick the credentials in some configuration file for a server that they may not trust particularly well. They don't have to ensure the permissions are correct in N places, but 1. Privilege separation is generally recognized as a good approach to security. (In fact, it could even be possible for unprivileged Unix users to start TLS-enabled servers on high ports without giving them the certs.)

pvg 10y ago
No, not servers. Like, say, the dropbox client that comes with its own cert. It would have to give it up to your 'tls service' thing. The server case already has pretty standard solutions in any but trivial deployments - something specialized terminates SSL (which is a bit like your idea but it already exists). But again, your solution to 'some app makers don't do TLS right' is 'hand over plaintext to the kernel'. The cure seems far, far worse than the disease. I don't think this is a 'gut distaste', it's just that most similar ideas of a generalized way to move encryption away from from the endpoints have failed and standard practice leans very much the other way for reasons that I think are pretty good. My argument isn't so much about anyone going off to implement or not implement this, it's that if you're going to think about this stuff (a perfectly fine thing), you have to meet the bar of the current accepted practice and then offer some, however hypothetical and thought-experimenty improvement. And I'm just not convinced that this idea does. Edit: You also mention (and I managed to skip over, sorry) the fact that browsers have complex certificate trust handling policies which other apps don't get to leverage. This is true but your example of an app is 'an app that pretends to be a browser'. I think this is a special, narrow case. Consider the dropbox client - it doesn't need or care about CAs, chains of trust, PKI or your system trusted cert store. That's browser stuff. Install mitmproxy and watch dropbox simply fail to work. So your solution is a sort of 'key escrow' demand for any app that just wants to talk TLS, not emulate the complex trust dance of a browser.
- comex 10y ago
  I'm mainly concerned with applications that follow standard protocols and allow the user to ask them to connect to arbitrary hosts. There are still a lot of those, even if these days standard protocols are dying out in favor of centralized proprietary services ;) That includes both non-HTTP TLS-wrapped protocols like email and IRC, and applications that access user-supplied HTTP URLs but aren't browsers, like media players, RSS clients, git, Matrix (chat), wget, apt-get, etc. Proprietary services are trickier because there's a question of "security for whom". As someone who mostly uses computers he owns, I would definitely like to be able to sniff Dropbox and see what it's sending. (Actually, Dropbox is a bad example because most Dropbox users already trust them with a lot of personal data, but there are many stories of, e.g., random mobile apps sending user data to servers with no justification.) That's not a security compromise from my perspective because it's my data. But Dropbox or whoever may not want people to get at their app's internal communications, and may see it as a compromise from their perspective. And if I'm using a system where someone else has root, I might agree with them. Of course, root can always attach with a debugger and try to extract the data anyway, but then there's the cat and mouse game of obfuscation...
  - pvg 10y ago
    ask them to connect to arbitrary hosts. There are still a lot of those Yep, I get that and I understand the problem you're describing is an actual problem. I just don't think 'endpoint hands over its plaintext' is the right solution. I would definitely like to be able to sniff Dropbox and see what it's sending Well, I'm sure you can, it's just not as easy as firing up tcpdump. But if you wanted to you could, it probably won't even take you long. 'It's not as convenient as firing up tcpdump' is still not a strong argument for 'just hand over the plaintext', in my mind. I'll wrap this up with a story you might have also seen play out over twitter the last couple of months. Tavis Ormandy, a security engineer currently working on Project Zero at Google has been dissecting various AV products and finding them riddled with pervasive and gross security holes up to and including intercepting TLS traffic and then screwing it up so badly as to make it highly vulnerable. The response from one vocal AV expert has been 'well, we wouldn't have to do that [and screw it up] if you gave us a tap/API into the plaintext so we can keep you all safe'. The predictable retort of security engineers has been 'LOL, NO'. I think ultimately, that 'LOL, NO' is what you're up against rather than some rando ranting at you on a message board. Enjoyable as it has been!

by comex 10y ago

pvg 10y ago

No, not servers. Like, say, the dropbox client that comes with its own cert. It would have to give it up to your 'tls service' thing. The server case already has pretty standard solutions in any but trivial deployments - something specialized terminates SSL (which is a bit like your idea but it already exists). But again, your solution to 'some app makers don't do TLS right' is 'hand over plaintext to the kernel'. The cure seems far, far worse than the disease. I don't think this is a 'gut distaste', it's just that most similar ideas of a generalized way to move encryption away from from the endpoints have failed and standard practice leans very much the other way for reasons that I think are pretty good. My argument isn't so much about anyone going off to implement or not implement this, it's that if you're going to think about this stuff (a perfectly fine thing), you have to meet the bar of the current accepted practice and then offer some, however hypothetical and thought-experimenty improvement. And I'm just not convinced that this idea does. Edit: You also mention (and I managed to skip over, sorry) the fact that browsers have complex certificate trust handling policies which other apps don't get to leverage. This is true but your example of an app is 'an app that pretends to be a browser'. I think this is a special, narrow case. Consider the dropbox client - it doesn't need or care about CAs, chains of trust, PKI or your system trusted cert store. That's browser stuff. Install mitmproxy and watch dropbox simply fail to work. So your solution is a sort of 'key escrow' demand for any app that just wants to talk TLS, not emulate the complex trust dance of a browser.

comex 10y ago
I'm mainly concerned with applications that follow standard protocols and allow the user to ask them to connect to arbitrary hosts. There are still a lot of those, even if these days standard protocols are dying out in favor of centralized proprietary services ;) That includes both non-HTTP TLS-wrapped protocols like email and IRC, and applications that access user-supplied HTTP URLs but aren't browsers, like media players, RSS clients, git, Matrix (chat), wget, apt-get, etc. Proprietary services are trickier because there's a question of "security for whom". As someone who mostly uses computers he owns, I would definitely like to be able to sniff Dropbox and see what it's sending. (Actually, Dropbox is a bad example because most Dropbox users already trust them with a lot of personal data, but there are many stories of, e.g., random mobile apps sending user data to servers with no justification.) That's not a security compromise from my perspective because it's my data. But Dropbox or whoever may not want people to get at their app's internal communications, and may see it as a compromise from their perspective. And if I'm using a system where someone else has root, I might agree with them. Of course, root can always attach with a debugger and try to extract the data anyway, but then there's the cat and mouse game of obfuscation...
- pvg 10y ago
  ask them to connect to arbitrary hosts. There are still a lot of those Yep, I get that and I understand the problem you're describing is an actual problem. I just don't think 'endpoint hands over its plaintext' is the right solution. I would definitely like to be able to sniff Dropbox and see what it's sending Well, I'm sure you can, it's just not as easy as firing up tcpdump. But if you wanted to you could, it probably won't even take you long. 'It's not as convenient as firing up tcpdump' is still not a strong argument for 'just hand over the plaintext', in my mind. I'll wrap this up with a story you might have also seen play out over twitter the last couple of months. Tavis Ormandy, a security engineer currently working on Project Zero at Google has been dissecting various AV products and finding them riddled with pervasive and gross security holes up to and including intercepting TLS traffic and then screwing it up so badly as to make it highly vulnerable. The response from one vocal AV expert has been 'well, we wouldn't have to do that [and screw it up] if you gave us a tap/API into the plaintext so we can keep you all safe'. The predictable retort of security engineers has been 'LOL, NO'. I think ultimately, that 'LOL, NO' is what you're up against rather than some rando ranting at you on a message board. Enjoyable as it has been!