3 ms·
This is an insanely flawed design and the responses to it are 100% factually correct in their assessment. loadbalancer.steampowered.com could still respond with
by folkhack 7y ago
This is an insanely flawed design and the responses to it are 100% factually correct in their assessment. loadbalancer.steampowered.com could still respond with a bad entry just as long as it fits the "https://*.steampowered.com" https://*.steampowered.com" pattern.
If the application does some sort of SSL pinning you may have to MITM the handshake but that's not outside of the realm of possibility for a sophisticated attacker.
I know it's just an example of how something COULD work but I strongly disagree that the following is correct:
> The worst the attacker can do in that scenario is cause the app to see network failures
Also - it's worth noting that all of this DNS talk really makes the whole SSL discussion moot. This is exactly why things like DNSSEC exist. If I'm able to point your traffic wherever you're done.
- tptacek 6y agoNo, not at all: the same LAN access that allows him to spoof DNS also allows him to spoof the authenticated-data bit in the DNS header to bypass DNSSEC. This is one of the great failings of DNSSEC. DoH: different story.
- folkhack 6y agoI'm prefacing this with I'm VERY new to DNSSEC (apologies). I guess I always assumed that DNSSEC would blow up when changing the destination of the point but have never really dealt with may DNSSEC rollouts outside of light maintenance. Thanks for a great response, I'm going to formally learn on DNSSEC because this is a good flag that I need better understanding. Also DoH is a new topic to me too so definitely going to "dig" on that as well ;)
- tptacek 6y agoThe right way to think of it is that DNSSEC is a server-to-server protocol. It makes it difficult for an upstream authority server to cache a spoofed record in your recursive server. It provides basically no on-the-wire security between your browser and your DNS server.