Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Adding in root certificates and performing HTTPS MITM even on your own network is a huge risk on its own. You're basically breaking many layers of security such as certificate pinning that just get disabled with any custom root certificate. Those middleboxes will always break client certificate authentication and you're trusting that they are checking the various revocation lists they should be (CRL/OSCP/various built-in blocklists).

For your basic premise to work, it also means that the MITM middleboxes will need to support the DoH protocols and support recording, and filtering those responses.

Additionally, custom roots certificates will only work on devices that you can actually set a custom root certificate for, a great example is IoT devices. Is your TV suddenly talking to a botnet or was that a legitimate update?

We can argue about whether those middleboxes are even sane to deploy (hint: they're not), but what is historically true is that they are known to update slowly to new protocols, if at all and are known to cause compatibility issues for traffic that is inherently expected to be unchanged. They're enough of a problem at the _TCP_ layer that QUIC was explicitly designed that minimal information is available in the protocol headers so middleboxes would have less to mess with.



oh don’t get me wrong, i’m not advocating for root certs and MITM boxes. i’m just saying DOH isn’t really going to challenge an enterprise’s ability to sniff and intercept DNS.

notwithstanding other technical issues, it’s just bad practice to create the sort of experience MITM creates.

when people are used to seeing compromised https when on the corp network or mitm boxes prompting for auth periodically it basically lowers people’s guard on that stuff and opens the door.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: