9

Nowadays it is possible to inspect (unencrypt) TLS (HTTPS) traffic inside an organization. The mechanism consists in using a root CA that is configured in the web client and a network device that receives the HTTPS connections and forge a on-the-fly certificates for the destination using that root CA. So, for this TLS traffic inspection you need to control both the endpoints and the network. Some network devices such as IPSs, proxies and DLPs implement this.

Traffic inspection has a business case: organizations may want to protect themselves against information leaks and malware communicating using these encrypted channels. If traffic inspection was not possible, organization would have a hole that would be exploited by attackers.

However, I'm not sure about the future and what is the trend. I have read about certificate pinning for example that tries to avoid traffic inspection to some point.

Are future versions of TLS going to avoid traffic inspection?

Nowadays all HTTPS traffic could be inspected using this mechanism? Including Google, Apple, Microsoft...

Improve this question
4

3 Answers 3

Reset to default
12

No.

AFAIK there is nothing inside the TLS 1.3 Draft about that. And I don't think there's a technical solution to this either. If you allow somebody to install an additional root CA on your computer, then all bets are off.

Improve this answer
4
  • If an end user can received data, it can be inspected, nature of the beast
    – NeuroScr
    Dec 27, 2015 at 2:05
  • 9
    @NeuroScr Not if the user is in full control of their computer and doesn't want it to be inspected... If you don't install a fake root CA, today's TLS can't be inspected, assuming a reasonable cipher suite is negotiated.
    – reirab
    Dec 27, 2015 at 5:43
  • 1
    Such a lack of this ability provides people a false sense of security. The connection can NEVER then be consider confidential and the protocol has failed to meet the objective.
    – jwilleke
    Dec 27, 2015 at 10:57
  • @reirab you're never in full control of your computer is more of my point.
    – NeuroScr
    Dec 27, 2015 at 12:45
14

TLS by itself protects the sniffing and modification of traffic between two endpoints, i.e. client and server. TLS interception just makes two TLS connections where only one was, i.e. client to interception device and interception device to server. This will still work with future TLS versions.

TLS interception is only possible if the validation of the endpoints does not detect the interception (or explicitly allows it). How the validation of the endpoint is done is not part of the TLS protocol itself and thus changes to the TLS protocol will not affect this part. Thus the current mechanisms for SSL interception by using a trusted proxy CA will still work as does SSL pinning if interception should not be allowed. Note that today's browsers will ignore pinning if the certificate is signed by an explicitly added CA, which means that pinning will be ignored when legal TLS interception is used. But this again is an issue of validating the certificate and is unrelated to the TLS version.

Improve this answer
0

Some new research seems to indicate that 1.3 does successfully block traffic inspection: https://datatracker.ietf.org/doc/html/draft-camwinget-tls-use-cases-00. Maybe some things have changed in the spec since 2015?

Improve this answer
1
  • That specifically refers to the issue of changing certificate/key requirements to an ephemeral mode. By definition, such a key cannot be reused. However, a slight architectural change resolves that issue and is outlined from the reference you give.
    – Julian Knight
    Feb 8, 2018 at 13:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .