Hacker News Reader

Comment by _uhtu | Hacker News Reader

Since it's HTTPS, a signature or checksum are pretty pointless, TLS will do the certificate checking and encryption for you.

Your assertion that "if your server gets hacked, so do your customers", also applies to a checksum, as the hackers would just change the checksum listed on the website.

If you have a problem with piping curl to bash, then you can just not do so, you can download the bash script, see what it does, and modify it before running it. It's only 140 lines and it's fairly simple.

Further to your point, the bash script also does checksums internally!

Putting releases up on github isn't a bad idea, but their github account credentials could also be hacked, so it's no more secure than this really.

View on HN

Since it's HTTPS, a signature or checksum are pretty pointless, TLS will do the certificate checking and encryption for you.

Serving the file over HTTPS is good because it means no one can do a man in the middle attack to change it, but it's not enough to be secure. If someone compromises the server itself the file could be altered at the source. The point of the checksum is to ensure that the file you're downloading is the file you're expecting. If you host the file in one place and the website in a different place it's harder for an attacker to change both the file and the website that reports the checksum, so you can be much more confident the file is correct. HTTPS on it's own doesn't give you that.

If someone compromises the server itself there's basically no form of security from that point that would help. The attacker could just put anything on the downloads page, including a new checksum for the compromised download. Nothing is safe if the server falls into malicious hands, but TLS is much easier for both the user and the website host when compared to a checksum, so that's probably the best decision for this kind of system.

The only time where I'd recommend a checksum over TLS is when you're dealing with a very large download, like a Linux ISO or something. The TLS encryption would cause a noticeable slowdown, so in that case a checksum may provide the best user experience.

> If you host the file in one place and the website in a different place it's harder for an attacker to change both the file and the website that reports the checksum, ...

That is not a practical solution at all. What do users find if they enter the "download" page? A link to an external site containing the checksum? Wouldn't an attacker just replace (or remove!) the link?

The reality of today's identity management is TLS and certificates. If your website is https://oya.sh, then obviously any attacker who has access to the web server can direct clients to their malware downloads. No extra servers will help against that.

Perhaps not practical, but I could see this as one actually useful example of how a blockchain-style distributed ledger could be used. Have two accounts, one posts the binaries, another posts the checksums. That way one account breach doesn't compromise the whole thing, and the ledger could prove the history, etc.

Agreed. There could be better solutions than the current reliance on X.509 certificates and TLS, for example a blockchain solution like you propose.

But the fact that these solutions do not exist or at least aren't commonplace, makes the criticism to Oya in this regard rather awkward. They are doing what everybody does for their downloads: Relying on the certificate chain.

A link to an external site containing the checksum? Wouldn't an attacker just replace (or remove!) the link?

It wouldn't need to be an external site. You can have more than one server running a domain, with a different set of keys (entirely different architecture if you want) to make hacking both harder.

I still don't really see how this makes hacking harder. An attacker needs to replace the information presented to the user in order to download the software. For instance, the "download" link, or the paragraph describing the download/checksum procedure.

This always originates from one spot for one user. You can spread among users, but you can not spread a single html snippet over machines in a way that a hacker couldn't replace the "root" html snippet.

I don't understand your first paragraph. Could you elaborate?

curl will error out if the chain of trust is invalid, unless you override it with the -k option.

Guess what, all you need to prove in order to get a new "valid" cert is that you control the server. And, if you control the server then you already have access to the original certificates, so you probably don't even need new certs.

Reply on news.ycombinator.com