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

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.