5 ms·
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 serve
by coltonv 7y ago
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.
- aerovistae 7y agoI don't understand your first paragraph. Could you elaborate?
- athenot 7y agocurl will error out if the chain of trust is invalid, unless you override it with the -k option.
- jforberg 7y agoGuess 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.
- onion2k 7y agoSince 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.
- tomtomtom777 7y ago> 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 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.
- marzell 7y agoPerhaps 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.
- tomtomtom777 7y agoAgreed. 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.
- onion2k 7y agoA 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.
- tomtomtom777 7y ago