91–100 of 100 posts
What would happen if someone actually managed to move google.com to a non-google registrar account under their control? Would someone step in and just seize it back? Can you imagine the magnitude of client devices hitting the wrong server for gmail,android updates,chrome even for a few minutes?
http://www.spiegel.de/netzwelt/web/domain-gekapert-google-un...
What would happen if someone actually managed to move google.com to a non-google registrar account under their control? Would someone step in and just seize it back? Can you imagine the magnitude of client devices hitting the wrong server for gmail,android updates,chrome even for a few minutes?
Earlier quoted context omitted.
I can imagine that such an attack would be dealt with a mix of manual intervention and technical measures, something in between the Google.com search page outage that happens once in a blue moon, and the false routes for YouTube.com IPs that have been propagated several times during the past few years. Big companies that rely on Internet presence are quite pro-active, and there are teams of people whose job is to pre…
>there are teams of people whose job is to prevent something like this from happening in the first place. Reading that along with the rest of this thread reminds me just how bad it is to have so much of the internet rely on large sites like this. The amount of trust and dependency that rests on Google is very dangerous. The amount of damage to the world that could result in a failure of their service is beyond imagin…
What would happen if someone actually managed to move google.com to a non-google registrar account under their control? Would someone step in and just seize it back? Can you imagine the magnitude of client devices hitting the wrong server for gmail,android updates,chrome even for a few minutes?
This somehow reminds me about Gamil [0]
Earlier quoted context omitted.
>there are teams of people whose job is to prevent something like this from happening in the first place. Reading that along with the rest of this thread reminds me just how bad it is to have so much of the internet rely on large sites like this. The amount of trust and dependency that rests on Google is very dangerous. The amount of damage to the world that could result in a failure of their service is beyond imagin…
On the other hand, it lets them do things like certificate pinning for themselves in their own browser, no? So, good and bad.
Vertical integration just means that Chrome cooperates more with Google's webadmins than Twitter's.
Apparently this happened in 1999 with Microsoft's Passport.com as well [1], and again later with hotmail.co.uk [2]. While I understand that snafus like this can happen, I don't understand why the new owner would simply hand back the domain for essentially no compensation (especially in the case of hotmail.co.uk - this appeared to be a clean transfer of an expired domain). If they let the domain expire, it's fair game…
Earlier quoted context omitted.
Well if you control the domain you can easily get an SSL cert (except some clients might pin the CA for google.com).
IIRC, all Chrome users are pinned for *.google.com
It sucks because now your employee can MITM you for gmail/google chat/etc
Earlier quoted context omitted.
Well, the original post talks about him getting Google Webmaster tools for google.com, which while still not "owning" the domain itself, is interesting because it means more happened than just the domain buying app thinking he owned it.
He bought it using googles own domain buying app, Presumably it is connected to the rest of googles stuff and the other way around.
Earlier quoted context omitted.
Well, maybe second biggest. https://citizenlab.org/2015/04/chinas-great-cannon/
Come on dude. Google is far bigger than Baidu.
Earlier quoted context omitted.
That depends on the expiry time ("Time To Live / TTL") set for the particular record. Minimum TTL is 1s, and maximum is 2e32 -1 seconds, or slightly over 136 years[1]. Resolver libraries and daemons keep cached results in volatile memory, so in practical terms, if a high TTL is set, the spoofed result will continue to be used until the given machine is rebooted. For some middle boxes, this can be years. [1] RFC 1035…
I think the point is -- if the TTL is set low, most ISPs simply ignore it to a minimum setting of at least a few hours. So changing/pointing a Google hostname to a victim might not have that big an impact if done only for a few minutes.
I think what really tends to happen, and this gets the folks confused, is that the initial TTL is high (say, 3 days), then the sysadmin wants to do some changes, and because they want to be able to keep changing the IP quickly, while they're working on it, they set the TTL low (say, 1 minute). Only you cannot retroactively lower the TTL of the records that have been sent previously, they'll expire whenever during the following 3 days.
Your point still stands, mostly. The probability of the old record with a high TTL to be evicted from a resolver's cache during any given short period of time is low.