3 ms·

In TLS 1.3, the server’s certificate is encrypted, which means the firewall can’t do this anymore. ... The firewall will open a second connection and do a TLS 1

In TLS 1.3, the server’s certificate is encrypted, which means the firewall can’t do this anymore. ... The firewall will open a second connection and do a TLS 1.2 handshake to retrieve the certificate in plaintext. If the rules allow the connection, the firewall then allow the connection to proceed. Sounds like a cat & mouse game. How long before we get servers that respond with different certificates based on who"s asking or other cues from the connection, in efforts to bypass the firewall restrictions.

tialaramex 1y ago
Sure, this already happens today as in practice pre-standard ECH is deployed, so client says "Hi I'm calling some.boring.example [encrypted: Actually clown-porn.example]" and this useless middlebox cannot decrypt the inner message so it retrieves the some.boring.example certificate but the client's encrypted connection reaches clown-porn.example which may have a different certificate. For many years, long before TLS 1.3 the RFC explains how to do this properly, obviating the problem, but that's very expensive because you need to TLS proxy every single connection, you can impose oversight by - literally - adding an actual oversight layer, which your users can also see you did. The popular middlebox products say they're doing two things, they're cheaper (maybe you buy their $100k product instead of a $100M solution) and they're less "intrusive" (ie you needn't tell your users that you're spying on them) In reality they're ineffective, which is why the RFC says not to do this - but they can either outright lie or hide this fact in an asterisked disclaimer somewhere, and most of their customers don't care whether it actually works, they want to tick a box.
- fragmede 1y ago
  CISO is such a thankless job.
FuriouslyAdrift 1y ago
In the infosec space, I am seeing rumblings of moving to compliant devices where the network tap is at the OS level and/or application level using software agents, AV hooks, or fake virtual network devices.

tialaramex 1y ago

Sure, this already happens today as in practice pre-standard ECH is deployed, so client says "Hi I'm calling some.boring.example [encrypted: Actually clown-porn.example]" and this useless middlebox cannot decrypt the inner message so it retrieves the some.boring.example certificate but the client's encrypted connection reaches clown-porn.example which may have a different certificate. For many years, long before TLS 1.3 the RFC explains how to do this properly, obviating the problem, but that's very expensive because you need to TLS proxy every single connection, you can impose oversight by - literally - adding an actual oversight layer, which your users can also see you did. The popular middlebox products say they're doing two things, they're cheaper (maybe you buy their $100k product instead of a $100M solution) and they're less "intrusive" (ie you needn't tell your users that you're spying on them) In reality they're ineffective, which is why the RFC says not to do this - but they can either outright lie or hide this fact in an asterisked disclaimer somewhere, and most of their customers don't care whether it actually works, they want to tick a box.

fragmede 1y ago
CISO is such a thankless job.

FuriouslyAdrift 1y ago

In the infosec space, I am seeing rumblings of moving to compliant devices where the network tap is at the OS level and/or application level using software agents, AV hooks, or fake virtual network devices.