Live-capture forensics of a CIN injecting fake Chrome install

I manage SSL operations at Google and, as far I can tell, this is all nonsense.<p>It&#x27;s too long to deal with point-by-point, but I can do a few:<p>* It&#x27;s not odd that a cert for * .google.com would be served for google.fr. Check the SANs.<p>* Google does not use EV certificates.<p>* Google&#x27;s frontends have many IP addresses. Seeing differences at different times and places is normal.<p>* Our leaf certificates really are issued for only a few months.<p>* We will be off SHA-1 by the end of the year but, at the time the article was written, one certainly could have received a SHA-1 signed certificate from us.<p>* <a href="http:&#x2F;&#x2F;clients1.google.com&#x2F;ocsp" rel="nofollow">http:&#x2F;&#x2F;clients1.google.com&#x2F;ocsp</a> is our OCSP responder and, yes, you&#x27;ll get 404 unless you send a correct OCSP request with a Host header.

Lots of nonsense here. Google routinely generates new ssl certificates with low TTLs. Anycast DNS will yield changing IP addresses over time and also between networks. Netscape-remote sounds like something that hails back to the Netscape 4.x era where, I believe, there was a command line argument to open a web page in an existing browser session by specifying -remote and the URL. 1e100(.net) is the value for a &quot;googol&quot; and it&#x27;s pretty well known to be used in google&#x27;s reverse DNS. And I can totally see sha1 still in use to maximize browser support, especially for a web page that is likely set as browser homepage on millions of outdated computers and android 2.x era phones. Anyways, don&#x27;t use reverse DNS to try to determine IP ownership - looking up the netblock owners in WHOIS is much better.

This appears to be a conspiracy theory. As far as I can tell, they have no evidence the Chrome install has been maliciously modified, no evidence that the certificate or IP address is fake, and are spouting nonsense about faking SHA1 hashes (which as far as we know no-one can do, and would be easy to detect and prove).

Very long article that is worded vaguely (a Corruptor-Injector Network? Wtf.)<p>From what I understand:<p>TL;DR: CDNs often have certificates that are valid for a lot of domain names[1]. Getting a valid certificate for any of these would allow you -- or an intelligence agency -- to hijack the https connection via MITM, and in this case, serve an altered binary (e.g. malware) instead of the real Google Chrome browser.<p>[1] More info: <a href="http:&#x2F;&#x2F;security.stackexchange.com&#x2F;q&#x2F;23042&#x2F;10863" rel="nofollow">http:&#x2F;&#x2F;security.stackexchange.com&#x2F;q&#x2F;23042&#x2F;10863</a>

Might I ask why the title on this was changed from &quot;Live-Capture Forensics of Corrupt-Injector Network Injecting Fake Chrome&quot; to &quot;Live-Capture Forensics of Corrupt-Injector Network Installing Fake Chrome&quot;? There&#x27;s quite the difference between the two verbs in this context. The CIN doesn&#x27;t perform any install on the user&#x27;s machine. The original &quot;... injecting fake chrome install&quot; title from the thread makes most sense.

I&#x27;ve been trying to figure out that attack from the posting, which is months old. They have SSL certs for Google sites which they argue are bogus. They&#x27;re both signed by &quot;Google Internet Authority G2&quot;, using a certificate that expired on 04&#x2F;04&#x2F;2015.<p>Firefox has two pre-installed certs for &quot;Google Internet Authority G2&quot;, one of which is still valid, and the other (serial 02:3A:69) has expired. The expired one may have been compromised, allowing the creation of sites which can impersonate Google sites. It&#x27;s hard to tell from that article, though.