9 ms·

^"No major web browsers inform the user when DNSSEC validation fails, limiting its strength and enforceability" -- when DNSSEC validation fails, the domain is

by thedg 11y ago

^"No major web browsers inform the user when DNSSEC validation fails, limiting its strength and enforceability" -- when DNSSEC validation fails, the domain is unreachable: www.dnssec-failed.org. The browser doesn't have to warn the user, the resolver will fail to return the DNS answer altogether.

tptacek 11y ago
This is a bigger problem than I think people think it is.
peterwwillis 11y ago
With a non-validating stub resolver you'll have no idea if DNSSEC is being used at all, much less if DNSSEC fails and it falls back to plain DNS. And most OSes up to this point use non-validating stub resolvers. From a user's perspective, DNSSEC is merely the potential to be more secure; until they personally verify it is working for them, they have no idea if they are actually more secure or not. And you have to do this per device, per OS. I just pulled up http://www.dnssec-failed.org/ http://www.dnssec-failed.org/ on both my laptop and my Android phone, it loaded just fine. So DNSSEC failed to prevent either of these devices from loading an invalid domain. But I had no notification that DNSSEC failed; the page just worked! If the browser actually informed me that DNSSEC isn't being enforced at all, I would at least know i'm not as secure as I could be.
- jessaustin 11y ago
  On a [EDIT:] 2.5yo chromebook and on a moto e (total value, new, unsubsidized, of both devices: $250) that site doesn't load, with "ERR_NAME_NOT_RESOLVED". You can't hold dnssec responsible for your choice of broke-ass old-n-busted clients. What other security system would be held to that standard?
  - peterwwillis 11y ago
    I'm using Android 5.0 and Windows 7. If those are broke-ass old-n-busted clients, screw modern technology. Even if they were old-n-busted, your network must also use a DNS resolving server that supports DNSSEC. So even if your client has the right stub resolver, the network you connect to determines whether your client can make a secure connection or not. Assuming both the client and network were correct, you still have no idea if it worked or not! If you are a really smart user who thinks a site should be using DNSSEC and you try to go to that site, and your dns resolver supports DNSSEC properly, all you get back from trying a bad site is the domain wasn't resolved. Is DNSSEC broken? Was the domain name wrong? Do I not have an IP on the network? Did something else happen? Who the fuck knows? Not the user, who gets back a generic error message if DNSSEC is working, and gets no error message if DNSSEC is not working. So it only works reliably when it's broken. What a fantastic security system. None of that happens with HTTPS, of course. With HTTPS the only thing that determines the security of the connection is whether the client validates its certs (and all browsers do). If it fails, you get an error and a big scary warning page.
    - jessaustin 11y ago
      Even if they were old-n-busted, your network must also use a DNS resolving server that supports DNSSEC. So even if your client has the right stub resolver, the network you connect to determines whether your client can make a secure connection or not. Good point! I didn't know that. Perhaps that's what you're running into, since Android 5.0 seems to be working fine for me? For a long time we all just used whatever DNS server we got from DHCP, but I think the time for that has passed. At this point we should choose our own recursive DNS provider, and reconsider using networks that don't allow that.
      - peterwwillis 11y ago
        > At this point we should choose our own recursive DNS provider Assuming you control your device (non-corporate non-government users) and know how to configure your DNS server (elite users only) and wanted to do this extra step (privacy-conscious people?), this will break for hotels, airports, cafes/restaurants, corporate/government networks, anyone with an ISP that intercepts public DNS requests, and various home routers. Not to mention making surfing the web much slower and less reliable, since we distribute name servers specifically to rely on caching to lower latency and increase availability in case of various network failures. But otherwise, sure, that works.
        jessaustin 11y ago
        Assuming you control your device... If this isn't the case, then I know that the device operates not in my interest, but in that of whoever controls it. So, I probably won't be entering any sensitive information into it.
        peterwwillis 11y ago
        Like your work e-mail?
        jessaustin 11y ago

by thedg 11y ago

tptacek 11y ago

This is a bigger problem than I think people think it is.

peterwwillis 11y ago

With a non-validating stub resolver you'll have no idea if DNSSEC is being used at all, much less if DNSSEC fails and it falls back to plain DNS. And most OSes up to this point use non-validating stub resolvers. From a user's perspective, DNSSEC is merely the potential to be more secure; until they personally verify it is working for them, they have no idea if they are actually more secure or not. And you have to do this per device, per OS. I just pulled up http://www.dnssec-failed.org/ http://www.dnssec-failed.org/ on both my laptop and my Android phone, it loaded just fine. So DNSSEC failed to prevent either of these devices from loading an invalid domain. But I had no notification that DNSSEC failed; the page just worked! If the browser actually informed me that DNSSEC isn't being enforced at all, I would at least know i'm not as secure as I could be.

jessaustin 11y ago
On a [EDIT:] 2.5yo chromebook and on a moto e (total value, new, unsubsidized, of both devices: $250) that site doesn't load, with "ERR_NAME_NOT_RESOLVED". You can't hold dnssec responsible for your choice of broke-ass old-n-busted clients. What other security system would be held to that standard?
- peterwwillis 11y ago
  I'm using Android 5.0 and Windows 7. If those are broke-ass old-n-busted clients, screw modern technology. Even if they were old-n-busted, your network must also use a DNS resolving server that supports DNSSEC. So even if your client has the right stub resolver, the network you connect to determines whether your client can make a secure connection or not. Assuming both the client and network were correct, you still have no idea if it worked or not! If you are a really smart user who thinks a site should be using DNSSEC and you try to go to that site, and your dns resolver supports DNSSEC properly, all you get back from trying a bad site is the domain wasn't resolved. Is DNSSEC broken? Was the domain name wrong? Do I not have an IP on the network? Did something else happen? Who the fuck knows? Not the user, who gets back a generic error message if DNSSEC is working, and gets no error message if DNSSEC is not working. So it only works reliably when it's broken. What a fantastic security system. None of that happens with HTTPS, of course. With HTTPS the only thing that determines the security of the connection is whether the client validates its certs (and all browsers do). If it fails, you get an error and a big scary warning page.
  - jessaustin 11y ago
    Even if they were old-n-busted, your network must also use a DNS resolving server that supports DNSSEC. So even if your client has the right stub resolver, the network you connect to determines whether your client can make a secure connection or not. Good point! I didn't know that. Perhaps that's what you're running into, since Android 5.0 seems to be working fine for me? For a long time we all just used whatever DNS server we got from DHCP, but I think the time for that has passed. At this point we should choose our own recursive DNS provider, and reconsider using networks that don't allow that.
    - peterwwillis 11y ago
      > At this point we should choose our own recursive DNS provider Assuming you control your device (non-corporate non-government users) and know how to configure your DNS server (elite users only) and wanted to do this extra step (privacy-conscious people?), this will break for hotels, airports, cafes/restaurants, corporate/government networks, anyone with an ISP that intercepts public DNS requests, and various home routers. Not to mention making surfing the web much slower and less reliable, since we distribute name servers specifically to rely on caching to lower latency and increase availability in case of various network failures. But otherwise, sure, that works.
      - jessaustin 11y ago
        Assuming you control your device... If this isn't the case, then I know that the device operates not in my interest, but in that of whoever controls it. So, I probably won't be entering any sensitive information into it.
        peterwwillis 11y ago
        Like your work e-mail?
        jessaustin 11y ago