
Live-capture forensics of a CIN injecting fake Chrome install - epsylon
https://cryptostorm.org/viewtopic.php?f=67&t=8713
======
agl
I manage SSL operations at Google and, as far I can tell, this is all
nonsense.

It's too long to deal with point-by-point, but I can do a few:

* It's not odd that a cert for * .google.com would be served for google.fr. Check the SANs.

* Google does not use EV certificates.

* Google's frontends have many IP addresses. Seeing differences at different times and places is normal.

* Our leaf certificates really are issued for only a few months.

* 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.

* [http://clients1.google.com/ocsp](http://clients1.google.com/ocsp) is our OCSP responder and, yes, you'll get 404 unless you send a correct OCSP request with a Host header.

~~~
dsl
I just came here to point out the same thing. This is just the ramblings of
someone with a medium level of technical experience and a high level of
paranoia drawing some very odd conclusions.

------
0x0
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 "googol" and it's pretty well known to be used
in google'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't use reverse DNS to try to determine IP ownership - looking up
the netblock owners in WHOIS is much better.

------
makomk
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).

~~~
m3talridl3y
Hah. I knew it was too juicy to be true.

------
lucb1e
Very long article that is worded vaguely (a Corruptor-Injector Network? Wtf.)

From what I understand:

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.

[1] More info:
[http://security.stackexchange.com/q/23042/10863](http://security.stackexchange.com/q/23042/10863)

~~~
Animats
That's a separate problem, the "Cloudflare MITM as a service" issue.

Seeing a multi-domain cert from Google is kind of strange. They certainly
don't need to share IP addresses or certs.

~~~
duskwuff
Google has a lot of domains, most of which support SSL. If they didn't use SAN
certificates, they'd have to allocate an IP address for every domain in each
of their locations, which could get pretty complicated. Much simplier to just
use one big certificate for everything!

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

------
Animats
I'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're
both signed by "Google Internet Authority G2", using a certificate that
expired on 04/04/2015.

Firefox has two pre-installed certs for "Google Internet Authority G2", 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's hard to tell from that article, though.

~~~
amag
An expired cert in the cert chain will not validate.

~~~
Animats
The attack reported in the original posting happened when that cert was valid.

