Google’s Kenyan web site was reportedly inaccessible yesterday due to a hijacking of the company’s local domain name.
Google.co.ke briefly redirected users to a site bearing the slogan “hacked” on a black background, according to the Daily Nation. A change of DNS was blamed.
Google Kenya reportedly said:
Google services in Kenya were not hacked. For a short period, some users visiting www.google.co.ke and a few other website were re-directed to a different website. We are in contact with the organisation responsible for managing domain names in Kenya.
Google is of course a high-profile target; hackers often exploit weaknesses at third-party providers such as domain name registries in order to take down its satellite sites.
Its Irish site was taken down in October last year, after attackers broke in through a vulnerability in IEDR’s Joomla content management system.
Potential security vulnerabilities recently disclosed by Verisign and PayPal are well in hand and not a reason to delay the launch of new gTLDs, according to the chair of ICANN’s security committee.
Patrick Falstrom, chair of the Security and Stability Advisory Committee, said today that the risk of disastrous clashes between new gTLDs and corporate security certificates has been taken care of.
Talking to the GNSO Council at the ICANN public meeting in Beijing, he gave a definitive “no” when asked directly if the SSAC would advise ICANN to delay the delegation of new gTLDs for security reasons.
Falstrom had given a presentation on “internal name certificates”, one of the security risks raised by Verisign in a paper last week.
These are the same kinds of digital certificates given out by Certificate Authorities for use in SSL transactions on the web, but to companies for their own internal network use instead.
The SSAC, judging by Falstrom’s presentation, had a bit of an ‘oh-shit’ moment late last year when a member raised the possibility of new gTLDs clashing with the domain names on these certificates.
Consider the scenario:
A company has a private namespace on its LAN called .corp, for example, where it stores all of its sensitive corporate data. It uses a digital certificate, issued by a reputable CA, to encrypt this data in transit.
But today we have more than a few applicants for .corp that would use it as a gTLD accessible to the whole internet.
Should .corp get delegated by ICANN — which of course is by no means assured — then there could be the risk of CAs issuing certificates for public domains that clash with private domains.
That might enable, for example, a hacker on a Starbucks wifi network to present his evil laptop as a secured, green-padlocked, corporate server to an unlucky road warrior sitting in the same cafe.
According to Falstrom, at least 157 CAs have issued certificates that clash with applied-for new gTLDs. The actual number is probably much higher.
This risk was outlined in Verisign’s controversial security report to ICANN, which recommended delay to the new gTLD program until security problems were resolved, two weeks ago.
But Falstrom told the GNSO Council today that recent secretive work by the SSAC, along with ICANN security staff and the CA/Browser Forum, a certificate industry authority, has mitigated this risk to the point that delay is not needed.
Falstrom said that after the SSAC realized that there was a potential vulnerability, it got it touch with the CA/Browser Forum to share its concerns. But as it turned out, the Forum was already on the case.
The Forum decided in February, a couple of weeks after an SSAC briefing, that member CAs should stop issuing internal name certificates that clash with new gTLDs within 30 days of ICANN signing a registry contract for that gTLD.
It has also decided to revoke any already-issued internal domain certificate that clashes with a new gTLD within 120 days of contract signing.
This means that the vulnerability window will be much shorter, should the vulnerability start getting exploited in wild.
But only if all CAs conform to the CA/Browser Forum’s guidelines.
Google has started fully supporting DNSSEC, the domain name security standard, on its Public DNS service.
According to a blog post from the company, while the free-to-use DNS resolution service has always passed on DNSSEC requests, now its resolvers will also validate DNSSEC signatures.
What does this mean?
Well, users of Public DNS will get protected from DNS cache poisoning attacks, but only for the small number of domains (such as domainincite.com) that are DNSSEC-signed.
It also means that if a company borks its DNSSEC implementation or key rollover, it’s likely to cause problems for Public DNS users. Comcast, an even earlier adopter, sees such problems pretty regularly.
But the big-picture story is that a whole bunch of new validating resolvers have been added to the internet, providing a boost to DNSSEC’s protracted global roll-out.
Currently Google Public DNS is serving more than 130 billion DNS queries on average (peaking at 150 billion) from more than 70 million unique IP addresses each day. However, only 7% of queries from the client side are DNSSEC-enabled (about 3% requesting validation and 4% requesting DNSSEC data but no validation) and about 1% of DNS responses from the name server side are signed. Overall, DNSSEC is still at an early stage and we hope that our support will help expedite its deployment.
One has to wonder whether Google’s participation in the ICANN new gTLD program — with its mandatory DNSSEC at the registry level — encouraged the company to adopt the technology.
The world’s most-popular web browsers are still failing to recognize new top-level domains, many months after they go live on the internet.
The version of the Safari browser that ships with the Mountain Lion iteration of Apple’s OS X appears to have even gone backwards, removing support for at least one TLD.
The most recent versions of Google’s Chrome and Microsoft’s Internet Explorer also both fail to recognize at least two of the internet’s most recently added TLDs.
According to informal tests on multiple computers this week, Safari 6 on Mountain Lion and the Windows 7 versions of Internet Explorer 9 and Chrome v24 all don’t understand .post and .cw addresses.
Remarkably, it appears that Safari 6 also no longer supports .sx domains, despite the fact that version 5 does.
Typing affected domain names into the address bars of these browsers will result in surfers being taken to a search page (usually Google) instead of their intended destination.
If you want to test your own browser, registry.sx, una.cw and ems.post are all valid, resolving domain names you can try.
The ccTLDs .sx and .cw are for Sint Maarten (Dutch part) and Curacao respectively, two of three countries formed by the breakup of the Netherlands Antilles in 2010.
Safari v5 on Windows and OS X recognizes .sx as a TLD, but v6 on Mountain Lion does not.
The problems faced by .post and .cw on Chrome appear to be mostly due to the fact that neither TLD is included on the Public Suffix List, which Google uses to figure out what a TLD looks like.
A few days after we reported last May that .sx didn’t work on Chrome, SX Registry submitted its details to the PSL, which appears to have solved its problems with that browser.
It’s not at all clear to me why .sx is borked on newer versions of Safari but not the older ones.
If the problem sounds trivial, believe me: it’s not.
The blurring of the lines between search and direct navigation is one of the biggest threats to the long-term relevance of domain names, so it’s vital to the industry’s interests that the problem of universal acceptance is sorted out sooner rather than later.
While most new gTLD applicants were focused on delays to the program revealed during last Friday’s ICANN webinar, another bit of news may also be a cause for concern for .home applicants.
As Rubens Kuhl of Nic.br spotted, ICANN revealed that 11 applications have not yet passed their DNS Stability check.
That’s a reversal from November, when ICANN said that all new gTLD applications had passed the stability review.
As I noted at the time, that was good news for .home, which some say may cause security problems if it is delegated.
As Kuhl observed, there are exactly 11 applications for .home, the same as the number of applications that now appear to have un-passed the DNS Stability check.
So is ICANN taking a closer look at .home, or is it just a numerical coincidence?
The string is considered risky by many because .home already receives a substantial amount of DNS traffic at the root servers, which will be inherited by whichever company wins the contention set.
It’s on a list of frequently requested invalid TLDs produced by ICANN’s Security and Stability Advisory Committee which was incorporated by reference in the new gTLD Applicant Guidebook.
Some major ISPs, notably BT in the UK, use .home as a pseudo-TLD in their residential routers.