My account at my domain name registrar was hacked and I am trying to understand how the hackers were able to steal my login credentials. Because the root certificate in the trust chain for the ssl certificate for the domain registrar's website is using a 1024-bit public key, could this mean that my login credentials were stolen via some type of Man-In-The-Middle attack?

Detailed version of my issue:

I am an expat living in China. Someone attempted to steal a domain name I have registered by breaking into my account at the domain's registrar. The individual(s) responsible for the break in were able to break into my account twice. After the first compromise (October 2014) I did my best to protect the account by setting strong passwords and strong account security questions. I updated my passwords and account security questions regularly.

I could not identify any malware on the PC (Linux OS) I was using to access my online accounts at the time of the first account compromise; however, in hopes of minimizing any chance that malware could infect my pc and steal login credentials going forward, I began using a Chromebook.

I also took steps to secure my Internet connection by proxying my Chromebook traffic through an ssh connection to a cloud server I set up on Digital Ocean. (I used the Secure Shell extension for Chrome to setup the ssh connection.) Since the Great Firewall of China throttles and resets ssh connections to servers outside the country, I connected to my ssh server through a VPN provided by a commercial VPN service provider. Despite all this, my account was compromised again around the end of March 2015.

After the second compromise, I began examining the ssl certificate information being displayed on my Chromebook for the websites I visited and found some issues which lead me to believe that Internet connections from my Chromebook were being subjected to some type of Man-In-The-Middle attack.

Firstly, for websites that made use of Extended Validation ssl certificates, my Chromebook would almost never display the green address bar (with padlock icon). I would only see a green padlock icon or a padlock icon with yellow warning triangle.

Also, the public key info for the root certificates shown in the certificate trust hierarchy for the domain registrar, my email provider and many other online sites I visited frequently showed a key size of 1024-bit. When visiting the same web sites from other PCs, I found the root certificates used in the certificate hierarchy to have a key size of 2048-bit.

From my Chromebook, I exported my domain registrar's ssl certificate using the 'Base64--encoded ASCII, certificate chain'.

The certificate chain information is here for your reference.


Opening this file in Ubuntu shows details of each certificate in the chain including the root certificate with the 1024-bit public key.

The certificate trust chain shows that the intermediary certificates in the trust chain are 2048-bit and the registrar's ssl certificate is 2048-bit. (I also verified that the domain registrar's ssl certificate's authentic fingerprint was correct via Steve Gibson's fingerprint service.)

I also found that the trust chain used when connecting to my email service (Fastmail) was using a GTE CyberTrust Global Root certificate. This root certificate seems off as I found that Fastmail uses a DigiCert High Asurance EV Root Certificate in the certificate chain when connecting from browsers that properly showed the full green address bar with padlock icon.

The 'Base64--encoded ASCII, certificate chain' for my Chromebooks connection to Fastmail is here for your reference.



Both chains are actually OK. The third certificate in both cases matches a real root CA (I checked against my machine's root, which fingerprints I then checked against the CA's sites via HTTPS on a separate iPad which is newly-purchased and should have proper certificates installed).

Here's what's happening: Certificates and public keys don't have a one-to-one relationship. A certificate binds a public key to an entity (the subject of the certificate); an entity might obtain several certificates for the same key, in case there's an issue with one of the certificates later (specifically, an issue not affecting the key).

That's what's going on here. Both chains have, as their third cert, a certificate with the same key (and subject) as the root ones on my machine (which are effectively known-good). But unlike the root CAs on my machine, they are signed by other (older, obviously) CA certificates; this is called cross-signing. This adds more options to trust the CA's cert; if you don't have it set up as a root, you can instead trust it because it's verified by a cert you do trust as a root.

In VeriSign's case, what's happening is they got a new root in the mid 2000s. They wanted to transition to the new root, but not all clients would have the new root installed. So, servers were given both the new root as self-signed (for new clients), and a chain from the new root to the old root (for old clients). In DigiCert's case, they have cross-signed certs with CyberTrust (which, incidentally, they recently bought) to give more options (I think the CyberTrust roots are older).

Because the chain has, somewhere along the line, a CA certificate with the same key and subject as a standard still-valid root CA cert, you don't actually have to worry about the rest of the chain after that point: even if a cert further down the chain is attacker-controlled, they can't be exploiting it at the moment.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.