0

I have read these posts: https://www.cnet.com/news/fraudulent-google-certificate-points-to-internet-attack/

https://support.google.com/mail/forum/AAAAK7un8RU3J3r2JqFNTw/?hl=en&gpf=d/category-topic/gmail/share-and-discuss-with-others/3J3r2JqFNTw

As far as I know, a certificate should be installed on a server.

So I don't quite understand how issuing a fraudulent certificate for *.google.com (the spelling of the common name is correct - it is not phishing) could trigger these browser warnings without installing it on a server.

I understand that a private key is in their hands but how did they manage to throw this certificate from the official Google website to users?

Did they install it on a Gmail server?

Could you explain, please?

Screenshot of certificate error in Chrome

2
  • Using a fake certificate, someone between the user and the real server (e.g. and ISP) can execute a 'man in the middle' attack. See en.wikipedia.org/wiki/Man-in-the-middle_attack for more information.
    – mti2935
    Commented May 23, 2020 at 19:13
  • You're right, it makes no sense that Chome simultaneously says "invalid server certificate" and "This certificate is OK". It's either one or the other. I suspect this particular certificate authority was blacklisted after the 2011 security incident, even though the certificate itself is technically valid Commented May 23, 2020 at 19:19

1 Answer 1

2

Within a man in the middle attack the attacker is in the path between client and server and can thus sniff and manipulate the traffic. This is for example possible if the attacker is a government agency which has sufficient control over the traffic leaving and entering the country, as it was true with Iran in this specific case.

In the context of SSL this is used by terminating the connection from the client at the attackers system and then creating a new SSL connection between the attacker system and the server. I.e. the attacker decrypts the traffic from the client, analyzes and manipulates the unencrypted traffic and then encrypts it again when sending it to the server. And the same for traffic from server to client.

In order to terminate the SSL traffic the attacker needs to have a certificate which will be accepted by the victim (the client). Usually the attacker does not have such a certificate which was issued by a publicly trusted CA which causes the client to display a warning that the certificate is not trusted. But in this specific case the attacker could compromise a public CA and make it issue the necessary publicly trusted certificate. With no certificate or CA pinning the browser will simply trust this new certificate since it was issued by a CA trusted in the browser.

2
  • Is it necessary to have access to the victim's system or browser? (Session hijacking or something like that) Or is it done on the ISP level?
    – t7e
    Commented May 23, 2020 at 19:59
  • @t7e: If the attacker has a certificate which is already trusted by the client (as in this case - it was issued by a publicly trusted CA) and if the attacker is already in the path (as it is in the case here with government controlled ISP) then no access to the victims system is needed. Commented May 23, 2020 at 20:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .