2

TLS 1.3 is a large departure from TLS 1.2 in many ways. Relevant to this question are the fact that all TLS 1.3 ciphers provide Forward Secrecy -- which means strategies used in TLS 1.2 and prior to decrypt TLS traffic passively must change. Gone are the days of simply throwing a Private Key file on an IDS/WAF/NMS device to let it passively decrypt any TLS traffic crossing your network.

That said, for compliance reasons, Corporations will likely still require the inspection of TLS traffic crossing their networks. Which means some mechanisms for TLS decryption must continue to exist.

I can think of only two strategies which will work for TLS 1.3:

  • Full proxy - terminate the TLS 1.3 sessions on the IDS/WAF/NMS and proxy the connection, inspect the clear text traffic "in between" the front-end and back-end connections.
  • Exporting Session Keys - let the TLS 1.3 sessions continue to terminate on web servers (as before), but use software on the web servers which export session keys for each connection to the IDS/WAF/NMS to allow inspection of TLS traffic

Other than these two above... are there any other mechanisms that will exist to decrypt TLS 1.3 traffic?

2
  • The whole point of TLS is to prevent inspection of traffic. The past mechanisms you mentioned were techniques to subvert the security. I suspect that the full proxy termination will remain the primary corporate mechanism. Forward Secrecy has been around for awhile now. The most common method used against Forward Secrecy is simply to capture the unencrypted traffic on the end-point devices. Authorized monitoring software does this, so too unauthorized malware. Commented Aug 3, 2021 at 19:23
  • @user10216038 The whole point of TLS is to prevent inspection of traffic. The past mechanisms you mentioned were techniques to subvert the security. Agreed 100%. I'm not trying to advocate for these strategies, I am simply contending that despite the goal of TLS being preventing snooping on protected traffic, it will still be done, just like it was in TLS 1.2 and prior. In trying to understand how it will be done, I'm asking this community if there is a mechanism that I'm missing.
    – jester
    Commented Aug 3, 2021 at 19:57

2 Answers 2

3

I think you don't miss any mechanism. There were some proposals like using static DH keys for data center interception or providing key material for trusted interceptors inside the TLS connection. But they did not made it into any standards because the necessary inherent weakening of the standard was not considered acceptable.

This means that the major implementation scenarios will likely be the "classic" TLS-MITM corporate proxy or antivirus product on the client side, and some IDS/WAF between a TLS terminating reverse proxy (or load balancer) and the origin server on the server side.

0

Another mechanism is to change chello/shello messages on the wire and forcefully downgrade TLS session to 1.2, so that TLS session is established using 1.2 protocol, and push back full 1.3 transition for as long as possible (like with IPv6)

4
  • That doesn't work; the Finished exchange fails and all connections are aborted, effectively shutting down your network (except for non-TLS traffic, if any) Commented Oct 31, 2022 at 2:23
  • @dave_thompson_085 this is in fact how some network appliances work, for example Fortinet: fortinet.com/blog/business-and-technology/… other more advanced appliances like PA support TLS1.3 decryption without TLS downgrade paloaltonetworks.com/blog/2020/08/… Commented Oct 31, 2022 at 18:33
  • That (F5) says the opposite "many network devices that do not support TLS 1.3 will [downgrade] ... [which] will no longer be an option. Network devices [now] must support TLS 1.3 [and F5 does]" If you can show a verifiable example of tamper-downgrade working (as opposed to the 'kill all 1.3 connections and hope the client falls back to lower like an eager browser') I'll pay you $500. Commented Nov 2, 2022 at 22:33
  • @dave_thompson tamper-downgrade works on my pc ( imgur.com/a/RRz2cxF ) the only exception is when the certificate is pinned by the website owner, in which case the whole decryption thing falls apart as browser will reject MitM'd certificate. the tls13.akamai.io established TLS 1.3 connection without decryption, but easily downgrades to 1.2 without any errors/warnings from browser Commented Nov 3, 2022 at 2:03

You must log in to answer this question.

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