6 ms·

Bypassing a DNS man-in-the-middle attack against Google Drive

56 points by chimeracoder 13y ago

romeo88 13y ago
dns "hijacking"? hosts entry as solution? booooooooooooring.
dsl 13y ago
First of all, this isn't a MITM attack, it is simply policy enforcement at the DNS layer. Secondly, imagine sharing a bus with someone pulling down tens of gigs of files from Google Drive over a shared cellular or satellite connection. They are watching out for everyones experience, not just yours. If you need to get work done, they don't prevent you from bringing your own dedicated connectivity.
- chimeracoder 13y ago
  > First of all, this isn't a MITM attack, it is simply policy enforcement at the DNS layer. The way it seems to me, they are intercepting outgoing DNS requests that should be queried against Google's DNS servers, since I had "8.8.8.8" and "8.8.4.4" in my /etc/resolv.conf. Is that not correct? > Secondly, imagine sharing a bus with someone pulling down tens of gigs of files from Google Drive over a shared cellular or satellite connection. The solution to that would be to throttle speeds or bandwidth for each connected device, rather than block all access to specific domains. In my case, I just needed to read a static text document (a "Google Doc").
  - dsl 13y ago
    > Is that not correct? Calling it an "attack" is disingenuous and sensationalist. > The solution to that would be to throttle speeds or bandwidth for each connected device That is a pretty slippery slope. You are escalating from blocking some DNS records to doing deep packet inspection of all traffic. You also have no idea what the operating requirements are (maybe they don't have {financial,computational,power} budget to do it your way?). Again, bring your own connectivity and you get to make the rules. Use someone else's bandwidth, and they make the rules.
    - magicalist 13y ago
      > That is a pretty slippery slope. You are escalating from blocking some DNS records to doing deep packet inspection of all traffic. You also have no idea what the operating requirements are (maybe they don't have {financial,computational,power} budget to do it your way?). Wait, what? If they have cheaper hardware and can't invest in more now, that certainly is an issue, but traffic shaping per device does not require deep packet inspection.
    - ploxiln 13y ago
      You, sir, are quite wrong. Traffic shaping, counting packets per user in the bus, is not deep packet inpection. Intercepting port 53 and replying on behalf of the real owner of the destination ip is seep packet inspection. Also, blocking a site that sometimes does and sometimes doesn't use a lot of bandwidth, instead of just blocking all uses of lots of bandwidth by measuring it in a destination-agnostic way, is clearly the worse option. Finally, rules and restrictions on technological devices and connectivity are retarded world-round. Your personal gadgets, your home internet connection, your phone's internet connection, all have ridiculous restrictions that no self-respecting technically savvy person follows (although most don't realize all the things they do that are against the "terms of service"). I don't get too worked up about them anymore, just systematically work around any I run into, just like any sane technically proficient person.
      - dsl 13y ago
        You are correct. I misread his suggestion as rate limiting specific flows, not flat per device rate limiting.
        Dylan16807 13y ago
        Even then, looking at the TCP/UDP headers to balance traffic is not deep inspection. Pretending to be a server and injecting yourself is both deep inspection and MITM.
        ploxiln 13y ago
        your reasonable response reminds me that my tone is excessively harsh... sorry :)
  - FireBeyond 13y ago
    No. That's -your- solution. Not their solution. They -choose- to block access, which is their right. Perhaps they should have managed that process better / more transparently. But you should dial back the entitlement. This "I just needed"..., and then there's the "Well, I'm going to get around it anyway, since it's obviously blocked".
    - deathanatos 13y ago
      > But you should dial back the entitlement. Not that you're completely wrong, but he is most likely paying to be there. If the company advertised the WiFi as part of the deal, and he paid for it, I'd say he is at least a little entitled to it.
- pocketheyman 13y ago
  Seems like a general way to reduce bandwidth consumption, but there are probably better ways then a fake 404 page?
jwise0 13y ago
(expanding on my response on Twitter...) I generally don't find /etc/hosts to be a sustainable answer against DNS hijacking, at least on hostile networks. For one thing, one-off hosts entries can cause you quite a lot of grief if Google chooses to change up what machines they host various services on; it may well also result in degraded performance if they use geoDNS to give you a lower-latency machine based on where you are accessing from. But, more than that, even though "most" of my applications are SSL, if I know a network to be hostile, I would rather have absolutely none of my traffic passing through them unencrypted. If you have a machine somewhere to run OpenVPN on, that's probably the safest thing to do; I've mine listening on TCP port 443, as well as the standard UDP port 1194. There are times when /etc/hosts is your best workaround -- such as a network that you generally trust, but which has some filtering that you need to work around. (Work networks often qualify for this.) But in the case of a truly hostile network, OpenVPN is probably your friend.
- chimeracoder 13y ago
  > I generally don't find /etc/hosts to be a sustainable answer against DNS hijacking, at least on hostile networks. Completely agreed. Unfortunately, this requires preparation in advance. Thankfully, this was just for a short bus ride - I actually changed it back immediately after loading the Drive homepage. How much overhead does OpenVPN add? I've used it a bit on reasonably fast networks, but I'm curious if it would be too slow to use here.
  - jwise0 13y ago
    I think in TCP mode, the big pain point is that packet loss on one wrapped session is lethal to your whole connection (i.e., all streams stop if just one stream stops). In UDP mode, I think you lose only 70-ish bytes per packet, which isn't too bad. (Another win that you get is roaming: if your local IP keeps changing, perhaps because your bus's cell modem keeps dropping out, then you don't lose your SSH sessions.)
    - mct 13y ago
      Another win that you get is roaming: if your local IP keeps changing, perhaps because your bus's cell modem keeps dropping out, then you don't lose your SSH sessions As a random aside, mosh (http://mosh.mit.edu/ http://mosh.mit.edu/) is incredibly good at IP mobility. One of my favorite examples: I circumnavigated the globe in November of 2012, and used the same mosh session in San Francisco, Hong Kong, Singapore, Kuala Lumpur, Penang, Bangkok, and Istanbul. :-) mosh also provides predictive local echo, which has made working over high-latency links so much more pleasant.
chippy 13y ago
If this was a MITM attack what would have been the correct route of action? Use a VPN?
- atmosx 13y ago
  Unbound + DNSSEC should be able to counter-measure this. That said, I'm not sure you'll be able to connect to a given IP if it's blocked. In this case you'll need a proxy/VPN/Anonymizer (Tor/I2P)
codeka 13y ago
Note that 74.125.228.1 is an IP address for drive.google.com. You'll get a different answer depending on where you are in the world when you issue the query (it will return an IP address for the datacenter nearest you).
muppetman 13y ago
They are probably doing this to stop people using DNS tunnelling to bypass sites/blocks/paywalls setup. Doing this can end up biting you in the butt in a few months time when Google move the service to a different place and you've forgotten to change the IP in hosts. Certainly works as temporary solution - this is how I test some of my websites before I push them into production via DNS.
coenhyde 13y ago
VPN. Always VPN. Don't trust the local network. A Digital Ocean droplet is only $5 a month so for most of the readers here there's no excuse for not using a VPN. Even my home network can't be trusted. Comcast hijacks DNS request to third party DNS servers.
- nwh 13y ago
  If you can't trust Comcast, can you trust Digital Ocean?
  - coenhyde 13y ago
    I trust Digital Ocean more than Comcast. And when I say trust, the trust part is that I trust Digital Ocean to deliver a service without playing silly games. Not that I trust Digital Ocean to keep my data private because at the end of the day you can't hide from agencies.
- barrkel 13y ago
  lowendbox.com - you can do much better than $5/month - try $8/year.
  - dictum 13y ago
    I've FUD'd myself regarding lowendbox. Using a Digital Ocean droplet as a VPN is probably the same as driving to Fort Meade monthly and handing them a hard drive with your full upload and download streams for the month, but using an unknown provider from LEB feels like handing out 2 drives: one for no such agency, another for some guy with a lot less data to sift through, thus a greater disposition to look at my data.
regecks 13y ago
If you have problems with your ISP hijacking DNS traffic, consider something like http://www.opendns.com/technology/dnscrypt http://www.opendns.com/technology/dnscrypt. They could stick hijack/block the traffic to the end server, but I suppose at that point you may as well give up and use a VPN.
- philip1209 13y ago
  Encrypting DNS should be standard policy on all roaming computers.
deleted 13y ago
[deleted]
guelo 13y ago
Would it be possible to use a local BIND server with a large cache? I guess it needs to do zone transfers with root servers.
- sehrope 13y ago
  Not if you respect the TTL on the DNS records. For example for drive.google.com it's 300 seconds: $ dig drive.google.com ; <<>> DiG 9.8.3-P1 <<>> drive.google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62437 ;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;drive.google.com. IN A ;; ANSWER SECTION: drive.google.com. 300 IN A 74.125.226.225 drive.google.com. 300 IN A 74.125.226.238 drive.google.com. 300 IN A 74.125.226.231 drive.google.com. 300 IN A 74.125.226.228 drive.google.com. 300 IN A 74.125.226.224 drive.google.com. 300 IN A 74.125.226.227 drive.google.com. 300 IN A 74.125.226.232 drive.google.com. 300 IN A 74.125.226.226 drive.google.com. 300 IN A 74.125.226.229 drive.google.com. 300 IN A 74.125.226.233 drive.google.com. 300 IN A 74.125.226.230 ;; Query time: 32 msec ;; SERVER: 192.169.1.1#53(192.169.1.1) ;; WHEN: Sun Jan 12 18:37:40 2014 ;; MSG SIZE rcvd: 210
bschlinker 13y ago
> However, entering that IP address into your browser will give you the Google homepage, because unlike most sites, their servers check the hostname I'm pretty sure that name-based hosting is fairly common, especially for smaller websites...
- MatthewWilkes 13y ago
  It's only uncommon when it comes to sites running under TLS.
- deleted 13y ago
  [deleted]
revelation 13y ago
This is a situation ripe for regulation. Feel free to filter by port or ip subnet, maybe we can talk about DPI, but modifying clearly needs to be a crime. There may not be an expectation of privacy, but there is certainly one that the integrity of the technical systems we use is not violated.
atmosx 13y ago
A couple of notes: * This was not a MITM attempt * When traveling laptops, it's more secure to use DNSSEC + Unbound * The author trusts Google with his data, which uses DNSSEC[1], but not DNSSEC because @tptacek said so - fair enough, I trust Dr Bernstein even more than tptacek - but it's a bit contradictory. He should be using OpenDNS which is the only major DNS provider of DNSCurve[2], instead of Google (8.8.8.8 and 8.8.8.4). Also, note, all major DNS providers are collecting data: OpenDNS (also adds a few suspicious redirects when the URL doesn't exist), Google is the leader of world-data mining, etc. The most trustworthy DNS, according to the a research I did some time ago, was/is OpenNIC. At home I run a dnsmasq + unbound (DNSSEC) + OpenNIC DNS's. On my laptop I have a similar configuration which uses by default a local unbound installation when joins every other network except mine. [1] http://googleonlinesecurity.blogspot.cz/2013/03/google-public-dns-now-supports-dnssec.html http://googleonlinesecurity.blogspot.cz/2013/03/google-publi... [2] http://en.wikipedia.org/wiki/DNSCurve#Deployment http://en.wikipedia.org/wiki/DNSCurve#Deployment [3] http://www.opennicproject.org/ http://www.opennicproject.org/
- chimeracoder 13y ago
  > This was not a MITM attempt I've heard captive portals on here eferred to as MITM attacks, and I think it's an accurate description of what's happening, regardless of the intent of the captor. In this case, they were hijacking DNS requests that were explicitly being made to another provider (first OpenDNS, then Google), and returning their own results instead of OpenDNS's or Google's. From a cryptographic perspective, I certainly would say that it fits the description of an MITM: https://en.wikipedia.org/wiki/Man-in-the-middle_attack https://en.wikipedia.org/wiki/Man-in-the-middle_attack > He should be using OpenDNS which is the only major DNS provider of DNSCurve[2], instead of Google (8.8.8.8 and 8.8.8.4). Actually, I was using OpenDNS initially - I switched to Google because I thought that might be the source of the OpenDNS error I was getting (the very first screenshot - admittedly a bit small to read in the picture). But it doesn't matter which DNS provider you use if they're hijacking traffic on port 53, which is what was happening here. > The author trusts Google with his data, which uses DNSSEC[1], but not DNSSEC because @tptacek said so It's not just "because tptacek says so" - it's because tptacek wrote a detailed critique comparing both services which I found convincing. I updated the post to link to tptackek's post that explains the issue in more detail; that's what I was referring to, but I couldn't find it at first when I wrote the post.
garthdog 13y ago
Is this even a problem with Google's certificate pinning? Chrome would prevent the user from accessing Drive if it was MITM'd.
tytso 13y ago
Why not just set up an http proxy on a linode box which only listens to localhost. Then use ssh -L to set up a port forwarding from your local host port 3128 to your linode host's port 3128, and then configure your browser to use localhost:3128 as your http proxy. Easy! (Alternatively, I just pull out my Nexus 7 with LTE support, and either turn on the portable wifi hotspot feature, or plug it into my laptop, and turn on USB tethering. Problem solved. :-P)
- twinge 13y ago
  You don't even need to run a proxy on the linode host: just use ssh's SOCKS proxy (the -D flag). https://mikeash.com/ssh_socks.html https://mikeash.com/ssh_socks.html Though this might require some more work to avoid DNS MITM, because it only tunnels TCP.
  - eru 13y ago
    You can tunnel DNS via socks, too.
TempleOSV2 13y ago
nigger

56 points by chimeracoder 13y ago

dns "hijacking"? hosts entry as solution? booooooooooooring.

dsl 13y ago

First of all, this isn't a MITM attack, it is simply policy enforcement at the DNS layer. Secondly, imagine sharing a bus with someone pulling down tens of gigs of files from Google Drive over a shared cellular or satellite connection. They are watching out for everyones experience, not just yours. If you need to get work done, they don't prevent you from bringing your own dedicated connectivity.

chimeracoder 13y ago
> First of all, this isn't a MITM attack, it is simply policy enforcement at the DNS layer. The way it seems to me, they are intercepting outgoing DNS requests that should be queried against Google's DNS servers, since I had "8.8.8.8" and "8.8.4.4" in my /etc/resolv.conf. Is that not correct? > Secondly, imagine sharing a bus with someone pulling down tens of gigs of files from Google Drive over a shared cellular or satellite connection. The solution to that would be to throttle speeds or bandwidth for each connected device, rather than block all access to specific domains. In my case, I just needed to read a static text document (a "Google Doc").
- dsl 13y ago
  > Is that not correct? Calling it an "attack" is disingenuous and sensationalist. > The solution to that would be to throttle speeds or bandwidth for each connected device That is a pretty slippery slope. You are escalating from blocking some DNS records to doing deep packet inspection of all traffic. You also have no idea what the operating requirements are (maybe they don't have {financial,computational,power} budget to do it your way?). Again, bring your own connectivity and you get to make the rules. Use someone else's bandwidth, and they make the rules.
  - magicalist 13y ago
    > That is a pretty slippery slope. You are escalating from blocking some DNS records to doing deep packet inspection of all traffic. You also have no idea what the operating requirements are (maybe they don't have {financial,computational,power} budget to do it your way?). Wait, what? If they have cheaper hardware and can't invest in more now, that certainly is an issue, but traffic shaping per device does not require deep packet inspection.
  - ploxiln 13y ago
    You, sir, are quite wrong. Traffic shaping, counting packets per user in the bus, is not deep packet inpection. Intercepting port 53 and replying on behalf of the real owner of the destination ip is seep packet inspection. Also, blocking a site that sometimes does and sometimes doesn't use a lot of bandwidth, instead of just blocking all uses of lots of bandwidth by measuring it in a destination-agnostic way, is clearly the worse option. Finally, rules and restrictions on technological devices and connectivity are retarded world-round. Your personal gadgets, your home internet connection, your phone's internet connection, all have ridiculous restrictions that no self-respecting technically savvy person follows (although most don't realize all the things they do that are against the "terms of service"). I don't get too worked up about them anymore, just systematically work around any I run into, just like any sane technically proficient person.
    - dsl 13y ago
      You are correct. I misread his suggestion as rate limiting specific flows, not flat per device rate limiting.
      - Dylan16807 13y ago
        Even then, looking at the TCP/UDP headers to balance traffic is not deep inspection. Pretending to be a server and injecting yourself is both deep inspection and MITM.
      - ploxiln 13y ago
        your reasonable response reminds me that my tone is excessively harsh... sorry :)
- FireBeyond 13y ago
  No. That's -your- solution. Not their solution. They -choose- to block access, which is their right. Perhaps they should have managed that process better / more transparently. But you should dial back the entitlement. This "I just needed"..., and then there's the "Well, I'm going to get around it anyway, since it's obviously blocked".
  - deathanatos 13y ago
    > But you should dial back the entitlement. Not that you're completely wrong, but he is most likely paying to be there. If the company advertised the WiFi as part of the deal, and he paid for it, I'd say he is at least a little entitled to it.
pocketheyman 13y ago
Seems like a general way to reduce bandwidth consumption, but there are probably better ways then a fake 404 page?

jwise0 13y ago

(expanding on my response on Twitter...) I generally don't find /etc/hosts to be a sustainable answer against DNS hijacking, at least on hostile networks. For one thing, one-off hosts entries can cause you quite a lot of grief if Google chooses to change up what machines they host various services on; it may well also result in degraded performance if they use geoDNS to give you a lower-latency machine based on where you are accessing from. But, more than that, even though "most" of my applications are SSL, if I know a network to be hostile, I would rather have absolutely none of my traffic passing through them unencrypted. If you have a machine somewhere to run OpenVPN on, that's probably the safest thing to do; I've mine listening on TCP port 443, as well as the standard UDP port 1194. There are times when /etc/hosts is your best workaround -- such as a network that you generally trust, but which has some filtering that you need to work around. (Work networks often qualify for this.) But in the case of a truly hostile network, OpenVPN is probably your friend.

chimeracoder 13y ago
> I generally don't find /etc/hosts to be a sustainable answer against DNS hijacking, at least on hostile networks. Completely agreed. Unfortunately, this requires preparation in advance. Thankfully, this was just for a short bus ride - I actually changed it back immediately after loading the Drive homepage. How much overhead does OpenVPN add? I've used it a bit on reasonably fast networks, but I'm curious if it would be too slow to use here.
- jwise0 13y ago
  I think in TCP mode, the big pain point is that packet loss on one wrapped session is lethal to your whole connection (i.e., all streams stop if just one stream stops). In UDP mode, I think you lose only 70-ish bytes per packet, which isn't too bad. (Another win that you get is roaming: if your local IP keeps changing, perhaps because your bus's cell modem keeps dropping out, then you don't lose your SSH sessions.)
  - mct 13y ago
    Another win that you get is roaming: if your local IP keeps changing, perhaps because your bus's cell modem keeps dropping out, then you don't lose your SSH sessions As a random aside, mosh (http://mosh.mit.edu/ http://mosh.mit.edu/) is incredibly good at IP mobility. One of my favorite examples: I circumnavigated the globe in November of 2012, and used the same mosh session in San Francisco, Hong Kong, Singapore, Kuala Lumpur, Penang, Bangkok, and Istanbul. :-) mosh also provides predictive local echo, which has made working over high-latency links so much more pleasant.

chippy 13y ago

If this was a MITM attack what would have been the correct route of action? Use a VPN?

atmosx 13y ago
Unbound + DNSSEC should be able to counter-measure this. That said, I'm not sure you'll be able to connect to a given IP if it's blocked. In this case you'll need a proxy/VPN/Anonymizer (Tor/I2P)

codeka 13y ago

Note that 74.125.228.1 is an IP address for drive.google.com. You'll get a different answer depending on where you are in the world when you issue the query (it will return an IP address for the datacenter nearest you).

muppetman 13y ago

They are probably doing this to stop people using DNS tunnelling to bypass sites/blocks/paywalls setup. Doing this can end up biting you in the butt in a few months time when Google move the service to a different place and you've forgotten to change the IP in hosts. Certainly works as temporary solution - this is how I test some of my websites before I push them into production via DNS.

coenhyde 13y ago

VPN. Always VPN. Don't trust the local network. A Digital Ocean droplet is only $5 a month so for most of the readers here there's no excuse for not using a VPN. Even my home network can't be trusted. Comcast hijacks DNS request to third party DNS servers.

nwh 13y ago
If you can't trust Comcast, can you trust Digital Ocean?
- coenhyde 13y ago
  I trust Digital Ocean more than Comcast. And when I say trust, the trust part is that I trust Digital Ocean to deliver a service without playing silly games. Not that I trust Digital Ocean to keep my data private because at the end of the day you can't hide from agencies.
barrkel 13y ago
lowendbox.com - you can do much better than $5/month - try $8/year.
- dictum 13y ago
  I've FUD'd myself regarding lowendbox. Using a Digital Ocean droplet as a VPN is probably the same as driving to Fort Meade monthly and handing them a hard drive with your full upload and download streams for the month, but using an unknown provider from LEB feels like handing out 2 drives: one for no such agency, another for some guy with a lot less data to sift through, thus a greater disposition to look at my data.

regecks 13y ago

If you have problems with your ISP hijacking DNS traffic, consider something like http://www.opendns.com/technology/dnscrypt http://www.opendns.com/technology/dnscrypt. They could stick hijack/block the traffic to the end server, but I suppose at that point you may as well give up and use a VPN.

philip1209 13y ago
Encrypting DNS should be standard policy on all roaming computers.

deleted 13y ago

[deleted]

guelo 13y ago

Would it be possible to use a local BIND server with a large cache? I guess it needs to do zone transfers with root servers.

sehrope 13y ago
Not if you respect the TTL on the DNS records. For example for drive.google.com it's 300 seconds: $ dig drive.google.com ; <<>> DiG 9.8.3-P1 <<>> drive.google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62437 ;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;drive.google.com. IN A ;; ANSWER SECTION: drive.google.com. 300 IN A 74.125.226.225 drive.google.com. 300 IN A 74.125.226.238 drive.google.com. 300 IN A 74.125.226.231 drive.google.com. 300 IN A 74.125.226.228 drive.google.com. 300 IN A 74.125.226.224 drive.google.com. 300 IN A 74.125.226.227 drive.google.com. 300 IN A 74.125.226.232 drive.google.com. 300 IN A 74.125.226.226 drive.google.com. 300 IN A 74.125.226.229 drive.google.com. 300 IN A 74.125.226.233 drive.google.com. 300 IN A 74.125.226.230 ;; Query time: 32 msec ;; SERVER: 192.169.1.1#53(192.169.1.1) ;; WHEN: Sun Jan 12 18:37:40 2014 ;; MSG SIZE rcvd: 210

bschlinker 13y ago

> However, entering that IP address into your browser will give you the Google homepage, because unlike most sites, their servers check the hostname I'm pretty sure that name-based hosting is fairly common, especially for smaller websites...

MatthewWilkes 13y ago
It's only uncommon when it comes to sites running under TLS.
deleted 13y ago
[deleted]

revelation 13y ago

This is a situation ripe for regulation. Feel free to filter by port or ip subnet, maybe we can talk about DPI, but modifying clearly needs to be a crime. There may not be an expectation of privacy, but there is certainly one that the integrity of the technical systems we use is not violated.

atmosx 13y ago

A couple of notes: * This was not a MITM attempt * When traveling laptops, it's more secure to use DNSSEC + Unbound * The author trusts Google with his data, which uses DNSSEC[1], but not DNSSEC because @tptacek said so - fair enough, I trust Dr Bernstein even more than tptacek - but it's a bit contradictory. He should be using OpenDNS which is the only major DNS provider of DNSCurve[2], instead of Google (8.8.8.8 and 8.8.8.4). Also, note, all major DNS providers are collecting data: OpenDNS (also adds a few suspicious redirects when the URL doesn't exist), Google is the leader of world-data mining, etc. The most trustworthy DNS, according to the a research I did some time ago, was/is OpenNIC. At home I run a dnsmasq + unbound (DNSSEC) + OpenNIC DNS's. On my laptop I have a similar configuration which uses by default a local unbound installation when joins every other network except mine. [1] http://googleonlinesecurity.blogspot.cz/2013/03/google-public-dns-now-supports-dnssec.html http://googleonlinesecurity.blogspot.cz/2013/03/google-publi... [2] http://en.wikipedia.org/wiki/DNSCurve#Deployment http://en.wikipedia.org/wiki/DNSCurve#Deployment [3] http://www.opennicproject.org/ http://www.opennicproject.org/

chimeracoder 13y ago
> This was not a MITM attempt I've heard captive portals on here eferred to as MITM attacks, and I think it's an accurate description of what's happening, regardless of the intent of the captor. In this case, they were hijacking DNS requests that were explicitly being made to another provider (first OpenDNS, then Google), and returning their own results instead of OpenDNS's or Google's. From a cryptographic perspective, I certainly would say that it fits the description of an MITM: https://en.wikipedia.org/wiki/Man-in-the-middle_attack https://en.wikipedia.org/wiki/Man-in-the-middle_attack > He should be using OpenDNS which is the only major DNS provider of DNSCurve[2], instead of Google (8.8.8.8 and 8.8.8.4). Actually, I was using OpenDNS initially - I switched to Google because I thought that might be the source of the OpenDNS error I was getting (the very first screenshot - admittedly a bit small to read in the picture). But it doesn't matter which DNS provider you use if they're hijacking traffic on port 53, which is what was happening here. > The author trusts Google with his data, which uses DNSSEC[1], but not DNSSEC because @tptacek said so It's not just "because tptacek says so" - it's because tptacek wrote a detailed critique comparing both services which I found convincing. I updated the post to link to tptackek's post that explains the issue in more detail; that's what I was referring to, but I couldn't find it at first when I wrote the post.

garthdog 13y ago

Is this even a problem with Google's certificate pinning? Chrome would prevent the user from accessing Drive if it was MITM'd.

tytso 13y ago

Why not just set up an http proxy on a linode box which only listens to localhost. Then use ssh -L to set up a port forwarding from your local host port 3128 to your linode host's port 3128, and then configure your browser to use localhost:3128 as your http proxy. Easy! (Alternatively, I just pull out my Nexus 7 with LTE support, and either turn on the portable wifi hotspot feature, or plug it into my laptop, and turn on USB tethering. Problem solved. :-P)

twinge 13y ago
You don't even need to run a proxy on the linode host: just use ssh's SOCKS proxy (the -D flag). https://mikeash.com/ssh_socks.html https://mikeash.com/ssh_socks.html Though this might require some more work to avoid DNS MITM, because it only tunnels TCP.
- eru 13y ago
  You can tunnel DNS via socks, too.

TempleOSV2 13y ago

nigger