5 ms·
> The problem is that the mechanics used for corporate monitoring are almost exactly the same mechanics used for your ISP spy on you or censor things. I disagr
by pilif 8y ago
> The problem is that the mechanics used for corporate monitoring are almost exactly the same mechanics used for your ISP spy on you or censor things.
I disagree. With SSL getting more and more widely deployed, corporate monitoring has no choice but to add re-encrypting proxies.
In that case, all SSL sites you are visiting are signed by a company internal certificate which is more or less obvious depending on the browser (if you ask me, browsers don't make this nearly as obvious as they should)
However, this kind of monitoring absolutely continues to work fine even if the browser is using DNS over HTTPS.
What DoH does break though, is internal DNS resolution of internal intranet hosts. Those would obviously be corporate owned as they would obviously have a corporation specific domain anyways, so no MitM is needed anyways because the admin can just look at the traffic on the server side.
This means that as DoH becomes more widely used, a corporation has only two options to continue to be able to allow users to connect to internal sites, both of which are worse from a security standpoint than the status-quo:
* they could assign publicly resolvable names to all of their internal hosts. This is likely to cause issues with IDS systems which assume that to be a DNS reflection attack and it of course also means that they now have to leak internal names to the public which obviously isn't desirable.
* they could deploy browsers with a modified configuration. Now most corporation already do that anyways to deploy their internal monitoring cert, but some smaller companies might not be interested in monitoring their users and right now they can ship original browser installers from their original source with their original config whereas in the future they will need to use group policies or custom installers, both of which are less trustworthy for a user than the default installers with the default config (who knows what that group policy / custom installer is doing alongside of configuring DoH).
So while option 1 is worse for overall corporate security, option 2 is worse for security and trust for individual users when the corporation is not currently doing any monitoring.
This security downgrade hurts even more in light of the fact that real SSL interception is not at all stopped by this, so already malicious actors can continue to be malicious, but good faith actors have to accept a significant downgrade in either user-trustworthiness or security.
I do not think this is a fair trade-off.
- yjftsjthsd-h 8y ago> real SSL interception is not at all stopped by this I wasn't aware that SSL interception was possible without a CA trusted by the victim, which is trivial in Enterprise and nigh-impossible elsewhere.
- geocar 8y agoIf you control the IP address (or close enough), or DNS (or close enough) you simply ask letsencrypt to give you a new certificate.
- megous 8y agoYou don't control either from the POV of LE verification infrastructure.
- geocar 8y agoI certainly can. These kinds of takeovers occur all the time. https://www.internetsociety.org/blog/2018/04/amazons-route-53-bgp-hijack/ https://www.internetsociety.org/blog/2018/04/amazons-route-5... https://www.itnews.com.au/news/china-systematically-hijacks-internet-traffic-researchers-514537 https://www.itnews.com.au/news/china-systematically-hijacks-... https://www.theregister.co.uk/2018/11/13/google_russia_routing/ https://www.theregister.co.uk/2018/11/13/google_russia_routi... My first experience with BGP hijacking was accidental and not malicious - and over twenty years ago now: I dropped Sprintlink off the East Coast US for several hours. If LE had been active, I could've taken over any Sprintlink-hosted (or downstream) SSL cert simply by performing challenges to LE. If people aren't doing this out of China and Russia I'd be surprised. LE might mitigate this with multiple checks (across multiple private links) but it currently doesn't do this: LE checks my challenge only once.
- everdrive 8y ago>What DoH does break though, is internal DNS resolution of internal intranet hosts. Those would obviously be corporate owned as they would obviously have a corporation specific domain anyways, so no MitM is needed anyways because the admin can just look at the traffic on the server side. >This means that as DoH becomes more widely used, a corporation has only two options to continue to be able to allow users to connect to internal sites, both of which are worse from a security standpoint than the status-quo: Why not just have an internal forwarder that does DNS-over-HTTPS? Browsers would send traditional DNS to the forwarder, and the forwarder would do DoH from there.
- LinuxBender 8y agoThis would also assume all the users would know how to configure this specific endpoint, or that IT staff do this for all the users. Today there isn't a good story around automating this process in heterogeneous shops. (windows, mac, linux, misc api tools) If a browser has a default option to use CloudFlare, Google, Amazon or Microsoft, then the user will click the button to "secure their DNS" and suddenly their internal applications may break or do odd things and companies start leaking even more internal records. Some IT departments may try to fix this by deploying configurations for 80% of the use cases and some may just block the public DoH servers. I can think of many ways this could be solved. The point I was trying to convey is that people have not thought this through and implemented this in browsers before corporate infrastructure was ready to accommodate the need. This creates contention and friction that could have been avoided, in my opinion. Adoption is likely to be embraced more widely if more use cases are accommodated.