Why does Google Chrome fail to provide a checksum

Question

Alright, I may be a bit uneducated when it comes to this subject but I have a genuine curiosity about why Google does not provide a checksum along with a gpg signature with their Google Chrome download. In fact I have never even seen a checksum anywhere on Google.com.

I understand the download is via an HTTPS connection, but correct me if I'm wrong it would still be possible to inject a malicious download right? I read somewhere that exit nodes for VPN's were found to have injected executables.

Then just recently, Linux Mint had their website hacked because of a faulty Wordpress configuration, and the linux mint ISO was swapped with one containing a backdoor for someones DDOS swarm.

Windows updates, apple updates, Ubuntu's apt-get all have signature signing and verification of packages.

But Google of all companies doesn't have even a checksum on their download page.

Why is this? Is there really any risk for end-users download Chrome?

Thanks =)

Answer 1

The Windows installers are signed using Authenticode (X.509), which is verified natively by Windows itself. Automatic updates (delivered using Omaha) are also signed using X.509.

The Linux repositories are signed using GPG – when you first download the google-chrome-current.deb over HTTPS, it automatically adds the updates repository to sources.list and installs its signing key to your apt configuration (see /opt/google/chrome/cron/).

(I wouldn't say that's very bad. Consider this: If you think an attacker can inject a fake download... Why couldn't they inject fake "checksums" as well? If you cannot trust that you downloaded the right .deb from https://google.com, then likewise you couldn't trust that you obtained the right PGP keys from https://google.com either.)

I understand the download is via an HTTPS connection, but correct me if I'm wrong it would still be possible to inject a malicious download right?

Generally no. That's... kind of what HTTPS is supposed to prevent.

There are two possibilities though:

• If you start with http://www.google.com/chrome and expect to be automatically redirected to HTTPS, an attacker can strip this redirect and force you to stay on the HTTP version.

  To avoid that, make sure you only visit the download pages over HTTPS; there might be some Tor configuration that you could use to block HTTP (tcp/80) entirely. (I know Tor has a port whitelist for exit nodes, but it would certainly be useful to have one for clients as well...)

• If you open a HTTPS website but the attacker intercepts your connection (MITM), the browser will warn you about a certificate error (since the attacker cannot get a "real" certificate for google.com), but many people will just blindly "click through" those warnings without even looking.

  To avoid that, don't bypass those browser security warnings.

The largest browsers (even IE, I think?) now come with google.com in their "HSTS preload" lists, which force the browser to always use HTTPS and prevent the user from bypassing certificate errors. So it should safeguard against such mistakes.