8 ms·

the reason TLS1.3 has been delayed so long is vendors and researchers that believe the dual-speek that TLS needs to be both secure, as well as readily intercept

the reason TLS1.3 has been delayed so long is vendors and researchers that believe the dual-speek that TLS needs to be both secure, as well as readily interceptable (and therefore insecure) in order for it to be "ready" to use. TLS and encryption arent going anywhere and theyre not always going to wait around for a concensus from industry. The sobering truth is that if not now, than in a decade or so the companies shilling TLS/SSL interception appliances and software will need to shift focus as the protocol will likely have been evolved by force over time to meet the needs of increasingly prevalent surveillance states. TLS interception or "proxying" started out as a graduate students parlour trick and eventually evolved into an entire shady industry where players like Bluecoat are routinely caught selling their products and services to repressive regimes. Heres hoping LibreSSL delivers the goods with or without the marketing teams say.

Buge 9y ago
>the protocol will likely have been evolved by force over time to meet the needs of increasingly prevalent surveillance states. Are you saying the protocol will be easier or harder to intercept in the future?
wmf 9y ago
To be clear, TLS 1.3 has no (or negative) support for interception. The delays are due to adding hacks to cleanly prevent interception, not to add it.
dictum 9y ago
I agree with regards to appliances like Bluecoat, but is TLS as a black box to keep users from seeing what the device is sending over the wire better?
- mhils 9y ago
  This needs to be highlighted more often. TLS interception can be a very effective tool to expose insecure APIs and blatant privacy violations. It's ultimately a tradeoff between security (no bad interception) and privacy (no idea what my device is sending).
  - Godel_unicode 9y ago
    I agree, I'm continually saddened by the zealotry of the anti-surveillance lobby and the seeming dismissal of the privacy focused hacker who wants to know when exactly does Uber send data, and what exactly do they send. Especially when it goes as far as encoding the philosophy that state actors are the only problem that matters into the very protocol.
    - wbl 9y ago
      TLS 1.3 still enables exactly that.
    - lox 9y ago
      Could you explain how TLS 1.3 in any way reduces your ability to intercept traffic on your own devices?
  - modeless 9y ago
    TLS doesn't prevent you from intercepting your end of the connection on a device you control. If you don't control your own device then the problem is with your device, not TLS. We shouldn't weaken TLS just because you chose to hand control of your device to someone else.
    - mhils 9y ago
      Well I agree. My main concern is that we're loosing that control in the name of security, in particular on mobile devices. Take Android as an example, which doesn't respect user-added CAs anymore for application traffic [1]. It's even worse with cert-pinned iOS apps where you cannot root easily, although Apple is at least trying to fix this with App Transport Security (which does respect user-added CAs). I definitely do not want to see a weaker TLS - 1.3 is great. At the same time, I do not want to have 'security improvements' that make it impossible for average developers to see their own device's traffic. That will ultimately enable insecure APIs and gross privacy violations behind TLS. [1] https://github.com/mitmproxy/mitmproxy/issues/2054 https://github.com/mitmproxy/mitmproxy/issues/2054
geofft 9y ago
I don't understand your reference to LibreSSL in the context of your comment—why would they be different from any of the other SSL implementations? Are they planning on implementing something else besides TLSv1.3 per spec, or intentionally implementing more or less than the spec requires?
Spooky23 9y ago
I should absolutely be able to intercept TLS traffic on my computers on my network. That's the distinction. Third party interception capability needs to be illegal and connections should be tamper evident. Frankly, I have a higher duty than user privacy. My users have access to data that's critically sensitive in various ways, in some cases they face criminal sanction. I need to both control and detect unauthorized software on the network and ensure that users are following the rules. More extreme privacy activists will make noises about things using endpoint based solutions or something similar. It's a bullshit position that will ultimately weaken security.
- marcosdumay 9y ago
  On your computers, yes. On your network, not so much. You have no right to intercept data just because you are moving it from one side to the other. And that's the thing. There is nothing stopping those companies from analyzing the data once it reached a managed computer. It is just that they want the capacity to do that on computers they don't manage.
  - closeparen 9y ago
    TLS interception is predicated on whitelisting your own CA on the endpoint. Can't really do that if you don't manage it. And in any case, you need to be resilient to a rogue or compromised device.
  - Spooky23 9y ago
    Yeah, no. The network is my property and the contract our employees or partners sign establishes terms for using the network. You cannot get out of the network unless the traffic is proxied. There are a few exceptions for identify based reverse proxies that companies like Google talk about. But most places aren't there yet for sensitive applications outside of collaboration. There's also the matter of trust. Some business partners are explicitly trusted, either by a private CA signed certificate or by a specific third party key that is independently validated. Public networks are completely different. I am not talking about an ISP here.

Buge 9y ago

>the protocol will likely have been evolved by force over time to meet the needs of increasingly prevalent surveillance states. Are you saying the protocol will be easier or harder to intercept in the future?

wmf 9y ago

To be clear, TLS 1.3 has no (or negative) support for interception. The delays are due to adding hacks to cleanly prevent interception, not to add it.

dictum 9y ago

I agree with regards to appliances like Bluecoat, but is TLS as a black box to keep users from seeing what the device is sending over the wire better?

mhils 9y ago
This needs to be highlighted more often. TLS interception can be a very effective tool to expose insecure APIs and blatant privacy violations. It's ultimately a tradeoff between security (no bad interception) and privacy (no idea what my device is sending).
- Godel_unicode 9y ago
  I agree, I'm continually saddened by the zealotry of the anti-surveillance lobby and the seeming dismissal of the privacy focused hacker who wants to know when exactly does Uber send data, and what exactly do they send. Especially when it goes as far as encoding the philosophy that state actors are the only problem that matters into the very protocol.
  - wbl 9y ago
    TLS 1.3 still enables exactly that.
  - lox 9y ago
    Could you explain how TLS 1.3 in any way reduces your ability to intercept traffic on your own devices?
- modeless 9y ago
  TLS doesn't prevent you from intercepting your end of the connection on a device you control. If you don't control your own device then the problem is with your device, not TLS. We shouldn't weaken TLS just because you chose to hand control of your device to someone else.
  - mhils 9y ago
    Well I agree. My main concern is that we're loosing that control in the name of security, in particular on mobile devices. Take Android as an example, which doesn't respect user-added CAs anymore for application traffic [1]. It's even worse with cert-pinned iOS apps where you cannot root easily, although Apple is at least trying to fix this with App Transport Security (which does respect user-added CAs). I definitely do not want to see a weaker TLS - 1.3 is great. At the same time, I do not want to have 'security improvements' that make it impossible for average developers to see their own device's traffic. That will ultimately enable insecure APIs and gross privacy violations behind TLS. [1] https://github.com/mitmproxy/mitmproxy/issues/2054 https://github.com/mitmproxy/mitmproxy/issues/2054

geofft 9y ago

I don't understand your reference to LibreSSL in the context of your comment—why would they be different from any of the other SSL implementations? Are they planning on implementing something else besides TLSv1.3 per spec, or intentionally implementing more or less than the spec requires?

Spooky23 9y ago

I should absolutely be able to intercept TLS traffic on my computers on my network. That's the distinction. Third party interception capability needs to be illegal and connections should be tamper evident. Frankly, I have a higher duty than user privacy. My users have access to data that's critically sensitive in various ways, in some cases they face criminal sanction. I need to both control and detect unauthorized software on the network and ensure that users are following the rules. More extreme privacy activists will make noises about things using endpoint based solutions or something similar. It's a bullshit position that will ultimately weaken security.

marcosdumay 9y ago
On your computers, yes. On your network, not so much. You have no right to intercept data just because you are moving it from one side to the other. And that's the thing. There is nothing stopping those companies from analyzing the data once it reached a managed computer. It is just that they want the capacity to do that on computers they don't manage.
- closeparen 9y ago
  TLS interception is predicated on whitelisting your own CA on the endpoint. Can't really do that if you don't manage it. And in any case, you need to be resilient to a rogue or compromised device.
- Spooky23 9y ago
  Yeah, no. The network is my property and the contract our employees or partners sign establishes terms for using the network. You cannot get out of the network unless the traffic is proxied. There are a few exceptions for identify based reverse proxies that companies like Google talk about. But most places aren't there yet for sensitive applications outside of collaboration. There's also the matter of trust. Some business partners are explicitly trusted, either by a private CA signed certificate or by a specific third party key that is independently validated. Public networks are completely different. I am not talking about an ISP here.