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