How is this SSL spoofing possible?

Question

Here is a description of a seemingly successful SSL certificate spoof:

https://cryptostorm.org/viewtopic.php?f=67&t=8713

The session is initiated by pointing a newly-opened icedove window manually at the following URL:

CODE: SELECT ALL https://google.com

This URL then redirects to the local google subsidiary for the exitnode cluster in question (Paris, France):

CODE: SELECT ALL

https:// google.fr

Immediately we notice that icedove is not happy with the certificate credentials... although the page still loads without any errors or overt warnings:

How is this possible? Why would browser not issue a security warning in this case, since the certificates are not trusted by any root certification authority it has locally in its cacerts?

Answer 1

The authors of the page you are referring to fail to understand some basic concepts and make otherwise false statements. Because of that I don't think that you should take any statements or conclusions from this article for real. Some examples:

This certificate identifies itself (via CN field) as *.google.com despite being served during a putative session with google.fr (again, this kind of obvious certificate misconfiguration is all but impossible to imagine google doing in production systems):

While the certificate they cite has *.google.com as the CN as they correctly state they fail to recognize that the certificate contains *.google.fr in the subject alternative names (SAN) section. And obviously the authors don't know that if this section is present and contains DNS names like in this case then the browsers should not even look at the CN but only at the SAN. This means the certificate is matching the server and the trust chain is also correct, so it is no wonder that the browser does not complain about it.

However, it's notable that the connection does not appear to represent an EV-class certificate. In other words, there's no 'green lock' as we see in any of google's other services. For example: ...

I don't know which "other services" they refer too but neither google.com nor youtube.com use EV certificates.

In summary: There are several obvious errors in this article. Therefore I recommend to simply ignore any statements and conclusions made in this article because the authors don't seem to understand what they are talking about.

Edit: I just found that this article is also heavily critized at https://news.ycombinator.com/item?id=10030820

Answer 2

I don't see anything particularly out of the ordinary.

IPv4 adresses move around. Google doesn't use EV-certification as EV doesn't allow wildcards. This person doesn't know that a certificate can contain multiple domain names in the subjectAlternativeName field, he only looks at the canonical name, which is indeed google.com for Google domains.