4 ms·

This makes sense, especially given that everyone should be already migrating to TLS 1.3 as fast as possible. However, as we see from past industry examples, mig

This makes sense, especially given that everyone should be already migrating to TLS 1.3 as fast as possible. However, as we see from past industry examples, migrations to every new standard often take decades.... Maybe the recent security incidents with AI will accelerate TLS 1.3 adoption everywhere.

MattPalmer1086 2mo ago
Except for those of us who have to do traffic inspection, which is blocked by TLS 1.3.
- tialaramex 2mo ago
  No. If you want to do "inspection" with TLS 1.3 you need to actually build the infrastructure these TLS specifications have always told you to use, rather than a cheap hack where too bad the users' security was destroyed but at least your "inspection" was cheaper.
  - MattPalmer1086 2mo ago
    We use standard inspection techniques, not "cheap hacks", whatever they are. What TLS 1.3 specifications for the required inspection infrastructure are you referring to?
    - tialaramex 2mo ago
      The TLS specifications have always told you that your options were 1. Retain each agreed session key for so long as you might wish to "inspect" that encrypted session. Now there's a signifier you're retaining for the specific session, which makes legal or moral considerations concrete in a way they were not for a vague "inspection" capability that applies for some undefined period over all traffic. The encrypted traffic itself can be retained arbitrarily because without those keys it's worthless. 2. Proxy all the traffic and decrypt/ encrypt at the proxy so that you can make transcripts of the plain traffic live. Everybody understands what these plain transcripts are now, if you're storing them, if some people have access, what that exactly means is obvious. What you're probably doing, which is much cheaper but is a hack, is to rely on RSA key agreement and then copy the RSA private key to an "inspection" tool which of course can then decrypt absolutely anything, forever. This is obviously a terrible idea even though it was cheaper, which is why it went away in TLS 1.3
      - MattPalmer1086 2mo ago
        The TLS specifications say nothing about different traffic inspection techniques, or the relative merits of each. What specifications are you talking about?
        khivp 2mo ago
        In your previous comment you said you were using "standard inspection techniques". Probably these standard inspection techniques you refer to have been updated to take TLS 1.3 into account, especially since TLS 1.3 has been out for a long time. Would you please be so nice as to point us to the standard you were referring to ?
- gdwatson 2mo ago
  Deliberately so, and for an Internet standard correctly so. I know there is a long tail of environments, so I am curious. What's your environment like that you need traffic inspection but don't have full control of the clients?
  - MattPalmer1086 2mo ago
    We operate Critical National Infrastucture for financial services. We have a lot of regulatory requirements that probably don't apply to most organisations.
- JackSlateur 2mo ago
  Well, for those of you who want to decrypt exchanges, plain-HTTP is best suited for you. Assume your stance :)
- orlp 2mo ago
  Isn't kind of the point of TLS that your communication doesn't get 'inspected'?
  - jeroenhd 2mo ago
    There are valid edge cases where you want traffic to be encrypted on the internet, but be readable by some intercepting device under your control. Parental control software has done that for decades, and there are (in my opinion misguided) regulations in some sensitive industries that suggest having to store a decrypted traffic log. Corporate MitM boxes are quite prevalent (they caused 5-10% of TLS 1.3 traffic to get dropped before they changed the protocol to fake TLS 1.2 session resumption) and when it comes to corporate-owned devices, that usually shouldn't pose too much of a privacy/security issue. These setups were a lot easier back in the day when TLS let you set static keys, but you can still dump TLS key files and/or reject all non-proxied traffic with your MitM proxy if you want to do such a setup. It'll break loads of apps thanks to certificate pinning, but that's probably a good thing for such corporate networks.

MattPalmer1086 2mo ago

Except for those of us who have to do traffic inspection, which is blocked by TLS 1.3.

tialaramex 2mo ago
No. If you want to do "inspection" with TLS 1.3 you need to actually build the infrastructure these TLS specifications have always told you to use, rather than a cheap hack where too bad the users' security was destroyed but at least your "inspection" was cheaper.
- MattPalmer1086 2mo ago
  We use standard inspection techniques, not "cheap hacks", whatever they are. What TLS 1.3 specifications for the required inspection infrastructure are you referring to?
  - tialaramex 2mo ago
    The TLS specifications have always told you that your options were 1. Retain each agreed session key for so long as you might wish to "inspect" that encrypted session. Now there's a signifier you're retaining for the specific session, which makes legal or moral considerations concrete in a way they were not for a vague "inspection" capability that applies for some undefined period over all traffic. The encrypted traffic itself can be retained arbitrarily because without those keys it's worthless. 2. Proxy all the traffic and decrypt/ encrypt at the proxy so that you can make transcripts of the plain traffic live. Everybody understands what these plain transcripts are now, if you're storing them, if some people have access, what that exactly means is obvious. What you're probably doing, which is much cheaper but is a hack, is to rely on RSA key agreement and then copy the RSA private key to an "inspection" tool which of course can then decrypt absolutely anything, forever. This is obviously a terrible idea even though it was cheaper, which is why it went away in TLS 1.3
    - MattPalmer1086 2mo ago
      The TLS specifications say nothing about different traffic inspection techniques, or the relative merits of each. What specifications are you talking about?
      - khivp 2mo ago
        In your previous comment you said you were using "standard inspection techniques". Probably these standard inspection techniques you refer to have been updated to take TLS 1.3 into account, especially since TLS 1.3 has been out for a long time. Would you please be so nice as to point us to the standard you were referring to ?
gdwatson 2mo ago
Deliberately so, and for an Internet standard correctly so. I know there is a long tail of environments, so I am curious. What's your environment like that you need traffic inspection but don't have full control of the clients?
- MattPalmer1086 2mo ago
  We operate Critical National Infrastucture for financial services. We have a lot of regulatory requirements that probably don't apply to most organisations.
JackSlateur 2mo ago
Well, for those of you who want to decrypt exchanges, plain-HTTP is best suited for you. Assume your stance :)
orlp 2mo ago
Isn't kind of the point of TLS that your communication doesn't get 'inspected'?
- jeroenhd 2mo ago
  There are valid edge cases where you want traffic to be encrypted on the internet, but be readable by some intercepting device under your control. Parental control software has done that for decades, and there are (in my opinion misguided) regulations in some sensitive industries that suggest having to store a decrypted traffic log. Corporate MitM boxes are quite prevalent (they caused 5-10% of TLS 1.3 traffic to get dropped before they changed the protocol to fake TLS 1.2 session resumption) and when it comes to corporate-owned devices, that usually shouldn't pose too much of a privacy/security issue. These setups were a lot easier back in the day when TLS let you set static keys, but you can still dump TLS key files and/or reject all non-proxied traffic with your MitM proxy if you want to do such a setup. It'll break loads of apps thanks to certificate pinning, but that's probably a good thing for such corporate networks.