And yet they still tell people to install Meteor by piping to their shell. Incredible.
Except piping to shell is more convenient.
Worse: the people who are most likely to curl|sh are DevOps folks with the keys to their company's kingdom.
It's convenient and that does not mean it's a good practice but i doubt using an other method would minimize a risk when the meteor.com would actually get owned.
GPG signing, keep the private key offline, publish the public key in the blockchain and have a lot of high profile technologists sign it so it can be independently verified.
See also: PHPUnit. https://phpunit.de/manual/current/en/installation.html#insta...
(They provide an example shell script for quickly downloading and verifying the latest versions of their install)
But at the end it's about people ...your example with PHPUnit can be abused like this https://thejh.net/misc/website-terminal-copy-paste How many people do you think will bother to paste the script to a text editor and check for evil parts ?
https://github.com/paragonie/password_lock/blob/master/run-t...
^- For the record, I keep scripts like this in my Git repositories.
But the problem is anyone compromising the site can just change the line from "blahblahblahblahbalhMETEOR.COMkey" to "attackerchangedblahblahblahblahbalhMETEOR.COMkey" right on the web page, and people will copy the one verified against the wrong key. So that doesn't work.
Nor do clients have caches of PGP signatures, nor is there some totally obvious third-party that you can verify it with. You can't just go:
curl|{check_if_signed_with_www.this-site.com}|sh (which would pass visual inspection - the attacker would have to change www.this-site.com to something else) because there is no obvious mechanism to do that. Who will tell you whether https://install.meteor.com/ has signed it?
Well, HTTPS will kind of tell you. So "https://install.meteor.com/" is a lot better than nothing...
If you're going to entertain the idea of the HTTPS site being compromised to serve whatever they want, well, there is precious little you can do about it.
I want them to not use a one-liner. Step-by-step:
1. Download the files
2. Download the public key
2a. verify the public key if you've never seen it before (publish in the blockchain, have lots of high profile technologists sign it, etc)
3. If the verification matches, then proceed.
Teaching developers to value "clever one-liner hack" over "secure, dependable solution" will lead to bad habits.
1. Google "meteor.com compromised" and decide whether it's currently compromised. If it isn't:
2. Run curl https://install.meteor.com|sh
It saves a few steps and is equally secure - you know, since you're just going to go based on what other people think and include no programmatic check whatsoever. (your 2a).
There is no reason you couldn't automate your whole suggestion, except for that one, which makes it infeasible and open to all manner of social engineering.
In other words, compromising the server wouldn't be enough, because that doesn't give you the SSL key, so it would still fail "curl|is_signed_by site.com|sh", which they can only pass if they compromise the private key?
Better than the current system?
But it does. The server needs to have the SSL key to be able to serve requests over HTTPS.
It may be encrypted with a password, but at that point you're severely degrading your integrity assurances (compared to offline executable/archive signing). Might as well do it right with offline signing, right off the bat.
Personally I think curl of an https URL is not the worst thing in the world.
Basically, the separation between 'server serving the downloads' and 'machine signing the release' is intentional, and should be maintained. Consider it an 'airgap' of sorts, although it usually isn't one in the strictest sense of the word.
Making release signing depend on the SSL infrastructure (which is already rather broken in a number of ways) in any way, is a bad idea. Verification is a different story, but secure code delivery is a hard problem anyhow.
I thought maybe a single-line invocation might piggy-back on SSL as follows:
- get a server's public key that is not online or able to answer requests (because if it were it couldn't be airgapped)
- but still use the key to verify the script that's downloaded from the server that is online.
- only pass the code to sh if it was properly signed by the offline server.
Then the offline server could be "https://key.meteor.com" and the private key wouldn't have to be anywhere but an airgapped machine.
I don't know if there is more of the SSL infrastructure that I'm missing though (I'm not an expert) or if this could practically be reduced down to a tamper-evident one-liner (a la curl https://install.meteor.com | sh). It would be a marked improvement over just passing anything from a potentially compromised server straight to bash though!
You don't, really. Not currently anyway. Retrieving a binary/archive and doing out-of-band verification are two logically separate steps.
The problem with your suggestion is that SSL is about transport security. It verifies that you are talking to the right server, but does not provide any guarantees beyond that.
It's not really possible to shoehorn release signing into that, without additional infrastructure.
It doesn't matter how you combine things - the server and the signing system are (and should be!) two separate entities, and you cannot rely on the server to tell you who the signing system is (because that'd give you no better security than not having a signing system at all).
> It would be a marked improvement over just passing anything from a potentially compromised server straight to bash though!
It wouldn't, because as far as I can tell, you're still relying on the server to tell you what the correct release signing key is. How else would you obtain it?