The outfit that manages Internet addresses for Ireland’s national .ie domain has temporarily taken some of its systems offline while officials investigate a security breach that temporarily hijacked the Irish websites for Google and Yahoo.

A short note on the homepage of the IE Domain Registry said the move followed a "security incident on Tuesday 9th October, involving two high profile .ie domains that has warranted further investigation and some precautionary actions on the part of the IEDR." Several independent Web posts, including those on Twitter and the site of a .ie domain registrar (Google cache here) identified the sites as Google.ie and Yahoo.ie. People trying to visit those addresses were briefly redirected to a fraudulent server as a result of "unauthorised access to one Registrar's account which resulted in the change to the DNS nameserver records for the two .ie domains," the latter blog post reported, citing IEDR CEO David Curtin.

Both of the affected sites, according to whois records, are managed by MarkMonitor, a company that protects the online brands of its customers. Sophos security expert Graham Cluley reported that the breach caused the IEDR to incorrectly point users to domain name system name servers at farahatz.net, which appear to be located in Indonesia.

There are no reports of people being redirected to websites that tried to install malicious software on their computers or trick visitors into divulging passwords or other personal information. Still, the incident is a reminder that a single misconfiguration to the Internet's routing system can have serious consequences for large numbers of people visiting brand-name sites.

The IEDR advisory said officials with the Garda Bureau of Fraud Investigation, Ireland's national police force, commenced an investigation on Wednesday. IEDR's Web interfaces aren't affected by the temporary suspension, allowing over two-thirds of its registrars to operate normally, the officials said, adding that public access to .ie websites and e-mail are also unaffected.

Might the moral of this story (for us users, at least) be to use the https versions of sites where possible?

Whatever site the DNS pointed to wouldn't have had Google's cert for google.ie, which in this day and age would have set off all sorts of browser alarm bells.

Would it? If the site appears to be located at google.ie (this was not a redirect, after all) and it just grabbed the certificate from the real Google site, I don't think a browser would be able to tell.

The only way I could see that working is if they'd managed to obtain a valid certificate for google.ie. They couldn't just "grab" the server-side cert from the real site (well, not without breaking in and making off with a copy of the private key and the cert).

Perhaps it's wrong of me to think that the checks in place for issuing a certificate at the CA level would catch an attempt to register a new cert for somewhere as popular as any Google site, given there were presumably checks in place at the DNS registrar that were obviously bypassed here.

Trustwave sold at least one "skeleton key" wildard certificate that would enable forging certificates. The Hong Kong Post office is a CA. Any CA could issue a certificate that would authenticate any website.

"Certificate Authority Trustwave has revoked a digital certificate that allowed one of its clients to issue valid certificates for any server, thereby allowing one of its customers to intercept their employees' private email communication."

Would it? If the site appears to be located at google.ie (this was not a redirect, after all) and it just grabbed the certificate from the real Google site, I don't think a browser would be able to tell.

I don't think you quite understand how the certification process works for https sites. In order to deliver a valid public certificate to the browser, which is what the browsers check, you need a separate, private, certificate. In this case, only Google (and the issuing entity) has the valid private cert, and you can be sure they keep a very tight lock around it.

You cannot use the public certificate (delivered by Google to your browser) to convince other browsers that your hijacked website is the correct one.

Would it? If the site appears to be located at google.ie (this was not a redirect, after all) and it just grabbed the certificate from the real Google site, I don't think a browser would be able to tell.

I don't think you quite understand how the certification process works for https sites. In order to deliver a valid public certificate to the browser, which is what the browsers check, you need a separate, private, certificate. In this case, only Google (and the issuing entity) has the valid private cert, and you can be sure they keep a very tight lock around it.

You cannot use the public certificate (delivered by Google to your browser) to convince other browsers that your hijacked website is the correct one.

You don't need Google's private cert. You just need a cert whose chain of trust the browser trusts. Any CA (several of whom have demonstrated themselves to be untrustworthy) can issue a cert that your browser will trust, and using that cert a new google.ie cert can be chained in that is different from Google's cert but will still be trusted by your browser.

So I would expected any organized crime group or Government worth their salt are in possession of one of these skeleton key certs, either through having bought it or stealing one.

Trustwave sold at least one "skeleton key" wildard certificate that would enable forging certificates. The Hong Kong Post office is a CA. Any CA could issue a certificate that would authenticate any website.

CA's are not trustworthy. SSL/HTTPS is not trustworthy.

The Trustwave thing was a mistake and they (correctly) revoked the certificate. If a trusted CA for SSL certificates started doing crazy things like that, you can bet all OS and browser makers would immediately patch their software to revoke those CA's trust as well.

Being a CA doesn't automatically grant them full trust on your computer. All browsers will show prominent warnings if the certificate doesn't chain up to a well-known trusted root CA. Also, not even all certificates are valid for SSL authentication. It's not like the Hong Kong post office can issue a certificate that lets some dude in Hong Kong to claim to be Google.

G1itch wrote:

Any CA (several of whom have demonstrated themselves to be untrustworthy) can issue a cert that your browser will trust, and using that cert a new google.ie cert can be chained in that is different from Google's cert but will still be trusted by your browser.

Oh really? Name one CA that your browser trusts by default, that will issue a certificate to a random bunch of people so they can impersonate Google.

You don't need Google's private cert. You just need a cert whose chain of trust the browser trusts. Any CA (several of whom have demonstrated themselves to be untrustworthy) can issue a cert that your browser will trust, and using that cert a new google.ie cert can be chained in that is different from Google's cert but will still be trusted by your browser.

So I would expected any organized crime group or Government worth their salt are in possession of one of these skeleton key certs, either through having bought it or stealing one.

While you're technically true, once you get to this level of paranoia, you're well into conspiracy theory territory. Additionally, at that point there's nothing an ordinary user can do to combat the forces arrayed against them.

My point was that the attackers who broke into a .ie registrar are unlikely to be able to forge a certificate that browsers will trust to impersonate Google. If they could, they'd have hit something more trafficked than what they did, and done so in a significantly more stealthy and lasting manner.

Trustwave sold at least one "skeleton key" wildard certificate that would enable forging certificates. The Hong Kong Post office is a CA. Any CA could issue a certificate that would authenticate any website.

CA's are not trustworthy. SSL/HTTPS is not trustworthy.

The Trustwave thing was a mistake and they (correctly) revoked the certificate. If a trusted CA for SSL certificates started doing crazy things like that, you can bet all OS and browser makers would immediately patch their software to revoke those CA's trust as well.

Being a CA doesn't automatically grant them full trust on your computer. All browsers will show prominent warnings if the certificate doesn't chain up to a well-known trusted root CA. Also, not even all certificates are valid for SSL authentication. It's not like the Hong Kong post office can issue a certificate that lets some dude in Hong Kong to claim to be Google.

G1itch wrote:

Any CA (several of whom have demonstrated themselves to be untrustworthy) can issue a cert that your browser will trust, and using that cert a new google.ie cert can be chained in that is different from Google's cert but will still be trusted by your browser.

Oh really? Name one CA that your browser trusts by default, that will issue a certificate to a random bunch of people so they can impersonate Google.

Lol, a mistake? As in an error? I don't think so. More like poor judgement. You're right, I can't imagine another for profit technology company making a business decision (selling a cert for a lot of money) at the expense of security concerns...

Real mistakes do happen though, and the fact that the reason you can't trust CA's is because they make mistakes does not all of a sudden mean they are trustworthy.

"VeriSign, Inc., recently advised Microsoft that on January 29 and 30, 2001, it issued two VeriSign Class 3 code-signing digital certificates to an individual who fraudulently claimed to be a Microsoft employee. The common name assigned to both certificates is "Microsoft Corporation." The ability to sign executable content by using keys that purport to belong to Microsoft would clearly be advantageous to a malicious user who wanted to convince users to allow the content to run."

If you're American it's bad because the Hongkong Post is on that list and I don't think anyone doubts that the Chinese Government could compel them to give up a skeleton key cert.

If you're not American it's bad because there are quite a few American companies on the list and the Patriot Act means that no American companies can be trusted with confidential data. They are required to disclose/cooperate with the US Government. It is possible that the US Government is required to get a warrant from one of those special secret federal courts before getting or using a skeleton cert, but we'll never know.

I have never even heard of half of the companies on that list, let alone be willing to trust that 100% of their employees would be unwilling to give up a cert for a sizable amount of money.

You don't need Google's private cert. You just need a cert whose chain of trust the browser trusts. Any CA (several of whom have demonstrated themselves to be untrustworthy) can issue a cert that your browser will trust, and using that cert a new google.ie cert can be chained in that is different from Google's cert but will still be trusted by your browser.

So I would expected any organized crime group or Government worth their salt are in possession of one of these skeleton key certs, either through having bought it or stealing one.

While you're technically true, once you get to this level of paranoia, you're well into conspiracy theory territory. Additionally, at that point there's nothing an ordinary user can do to combat the forces arrayed against them.

My point was that the attackers who broke into a .ie registrar are unlikely to be able to forge a certificate that browsers will trust to impersonate Google. If they could, they'd have hit something more trafficked than what they did, and done so in a significantly more stealthy and lasting manner.

Ever heard of Flame? It was the state-sponsored malware that used Microsoft certificates to successfully hijack Microsoft update. It's not paranoia.

Last year one CA was "ended" because they had private keys stolen that allowed Iran to read HTTPS related to gmail in order to monitor dissidents. Google "diginotar", or "comodo" - Ars Technica reported extensively on this.

I don't know if whoever hijacked the DNS entry for google.ie had a cert or not, but if their purpose was to read someone's email it makes sense.

How does it make sense to believe that a CA is safe but a DNS registrar isn't?

Ever heard of Flame? It was the state-sponsored malware that used Microsoft certificates to successfully hijack Microsoft update. It's not paranoia.

Last year one CA was "ended" because they had private keys stolen that allowed Iran to read HTTPS related to gmail in order to monitor dissidents. Google "diginotar", or "comodo" - Ars Technica reported extensively on this.

I don't know if whoever hijacked the DNS entry for google.ie had a cert or not, but if their purpose was to read someone's email it makes sense.

How does it make sense to believe that a CA is safe but a DNS registrar isn't?

Why yes, I have heard of Flame, and I'm familiar with that saga, as well as that of diginotar. Let's look at the intended targets of those, and the methods with which the attacks were performed:

Flame: Target was almost certainly specific industries in the Iranian scientific and military communities. IIRC, it used a number of 0 day exploits, along with a never published collision attack on MD5 to spread. It sat there and spied, for an unknown length of time, and used some of the most advanced methods yet used to avoid detection and prevent people from ever knowing it existed. Almost certainly state sponsored.

Diginotar: A multitude of certificates were fraudulently generated and used for at least a month and a half without anyone noticing, until someone noticed the Iranian government using one to spy on the entire country. No one knows for sure how long that had been happening. The CA is subsequently removed from every CA store within weeks. Assuming Iran hadn't done something that foolish, who knows how long it would have taken for the incident to be discovered.

These two incidents are on a completely separate level from someone hacking into a registrar and changing the DNS entries for a few hours. If someone has the capability to generate a fraudulent but technically valid certificate, they don't then go blunder into an Irish registrar and blow their cover to point a few million people (at an optimistic best) to an Indonesian server for a few hours.

These two incidents are on a completely separate level from someone hacking into a registrar and changing the DNS entries for a few hours. If someone has the capability to generate a fraudulent but technically valid certificate, they don't then go blunder into an Irish registrar and blow their cover to point a few million people (at an optimistic best) to an Indonesian server for a few hours.

The ability to change DNS records is clearly much more powerful than being able to write your own certs. I don't know what happened in this case and I'm not going to speculate. I'm just saying that HTTPS is not going to protect you from someone who can alter DNS records.

Most people just click through certificate errors anyway, the whole process is a joke.

Would it? If the site appears to be located at google.ie (this was not a redirect, after all) and it just grabbed the certificate from the real Google site, I don't think a browser would be able to tell.

I don't think you quite understand how the certification process works for https sites. In order to deliver a valid public certificate to the browser, which is what the browsers check, you need a separate, private, certificate. In this case, only Google (and the issuing entity) has the valid private cert, and you can be sure they keep a very tight lock around it.

You cannot use the public certificate (delivered by Google to your browser) to convince other browsers that your hijacked website is the correct one.

Okay, thanks. That makes sense. You're right, I'm a bit murky on how the HTTPS process works and didn't think this through exactly. I thought that the cert would be bound to the domain, so that would make it harder to just grab one from somewhere. But the public/private thing makes a lot of sense.

Public key cryptography involves a pair of keys that are cryptographic inverses of each other. Something encrypted with one key can be decrypted only by using the other. In general, one is guarded carefully, and called the private key. The other, the public key, is made available to anyone.

The "certificate" one's browser receives from, e.g., Google contains Google's public key. If something is encrypted with that public key, only the holder of the corresponding private key, namely Google, can decrypt it. If I can misdirect DNS, but provide a copy of the real Google certificate snarfed from a browser session, I won't be able to decrypt what the victim sends because I don't have the corresponding private key. The SSL/TLS handshake will fail.

The certificate itself contains an identifier (Google, in this example), the public key, identification of the certificate authority, some other info, and a cryptographic hash computed over all the information in the certificate. The cryptographic hash is digitally signed by encrypting it with the private key of the certificate authority. Anyone can get the CA's public key and use it to decrypt that hash code. One then validates the hash code by recomputing it and comparing the computed value with the decrypted value. If they're equal, the presumption is that the certificate hasn't been tampered with.

The upshot of having digital certificates signed with an encrypted hash code means I can't just snarf Google's certificate and replace their public key with my own. The digital signature on the certificate would no longer validate, and the browser would reject the certificate. (Unless the user just clicks OK to bypass the validation error.)

One more thing: The attacker doesn't need to compromise the particular CA selected by, say, Google. Any CA that is on the browser's "trust chain" can sign a rogue certificate. There may be other mechanisms, like the collision attack that was part of Flame, for producing a rogue certificate.

To stage a successful SSL/TLS man-in-the-middle attack, one needs two things: the ability to compromise DNS and possession of a valid but bogus digital certificate with the corresponding private key. The prior comments show that both of those things are possible. We'd like to believe that doing both at once is difficult, but if you live in a country where the government runs the DNS and the CA, they can absolutely, positively mount such an attack.

If I can get my hands on Google's private key, then I only need to compromise DNS to stage the attack. You can bet that Google is careful with that private key. That bet might not be so safe in other cases.

Conclusion: SSL/TLS, at least in most countries, is probably safe enough to let me send a credit card number to Amazon. It is not safe enough to let me plan the overthrow of governments. For that, use GPG and be very certain no one can beat the private keys out of your co-conspirators.

-----------Edit: added the first paragraph and fixed a mangled point of view in the second. Maybe.Another edit: added "with the corresponding private key" to paragraph 6.

Would it? If the site appears to be located at google.ie (this was not a redirect, after all) and it just grabbed the certificate from the real Google site, I don't think a browser would be able to tell.

I don't think you quite understand how the certification process works for https sites. In order to deliver a valid public certificate to the browser, which is what the browsers check, you need a separate, private, certificate. In this case, only Google (and the issuing entity) has the valid private cert, and you can be sure they keep a very tight lock around it.

You cannot use the public certificate (delivered by Google to your browser) to convince other browsers that your hijacked website is the correct one.

No, the server needs the private keys that correspond to the public key in the certificate. You need the certificate to be signed by any one of the hundreds of certificate authorities. SSL ultimately depends on every single CA, and all of their staff, in the world being trustworthy.

So, generate key pair. Bribe a CA staffer or if you are a state actor, request your governmental CA to sign the certificate generated as part of the key pair generation process. Place on server. You are now in business, every browser will validate the connection.