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...

Sergio Tulentsev
  • 105
  • 3
Eloy Roldán Paredes
  • 1,507
  • 12
  • 25
  • You seem to feel packet inspection is a flaw while I suspect it is viewed by many as a positive feature. – Neil Smithline Dec 26 '15 at 17:01
  • 1
    Note that software is not obliged to care about root CAs, or indeed use TLS at all. Malware certainly doesn't play so nice! – whitequark Dec 26 '15 at 18:26
  • HTTPS interception is *already* broken under both Firefox and Chrome (and probably all browsers other than IE and Edge) [when the remote site is using an EV certificate](https://www.grc.com/ssl/ev.htm) or [the user is sufficiently paranoid](https://www.grc.com/fingerprints.htm). – Kevin Dec 26 '15 at 23:37
  • 2
    Relevant: [RFC 7258 / BCP 188, *Pervasive Monitoring Is an Attack*](https://www.rfc-editor.org/rfc/rfc7258.txt) – user Dec 27 '15 at 12:46

3 Answers3

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.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
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.

Community
  • 1
StackzOfZtuff
  • 17,783
  • 1
  • 50
  • 86
  • If an end user can received data, it can be inspected, nature of the beast – NeuroScr Dec 27 '15 at 02: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 '15 at 05: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 '15 at 10:57
  • @reirab you're never in full control of your computer is more of my point. – NeuroScr Dec 27 '15 at 12:45
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?

Community
  • 1
RussM
  • 51
  • 1
  • 2
  • 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 08 '18 at 13:41