While helper scripts for OpenSSLs arcane syntax are highly appreciated, running some .sh file downloaded from the Internet is not the wisest of security ideas. The author (or somebody from GitHub) could just replace this script with one that actually uploads your freshly-generated private key to somewhere.
You know, I've struggled with this concept. I agree that we shouldn't pipe a URL into a bash script without knowing what it is.
But an unsigned software repository that calls post install scripts seems just as absolutely easy to modify, and we see those regularly.
My software is most easily installed with a piped bash script. In the script contents, I try to explain what's going on. I also at the top indicate that you shouldn't just trust what I am telling you. And then in the documentation, where you are told how to run the script, I tell you to be cautious there as well. (The script just installs the repository, and from there it's all signed and delivered over https).
I could never get over how easy it would be to whitewash a bash script with an rpm just to get some psychological credibility.
If it's not signed and/or delivered over https, it's completely hackable.
People who are serious about their security run something like Debian and only install from the official repositories, where all packages are signed with GPG and all package maintainers must be part of the web of trust (i.e. have had their identity vouched for by at least one other Debian maintainer).
Of course you have to make sure the original install is trustworthy; all you can really do for that is compare the .iso checksum on several different machines. If all those machines are compromised (or there's a hardware-level compromise of your machine) then you're doomed, but that at least makes attacking a lot more costly than it would otherwise be.
Yeah, I know. That was awful and should have resulted in policy changes; it hasn't, and I don't use Debian any more. But it makes a good example of the right approach to package infrastructure.
I wouldn't think stronger than Debian, but there are plenty of distros with equivalent policies. At the moment I'm running FreeBSD (not especially for security reasons).
How does this differ from any other software? Either you trust the author, or you don't. I assume you haven't reviewed your entire stack to prevent it from including evil code?
It's apparently a requirement for various cloud platforms that the private key doesn't use a passphrase (probably due to automated scripts where the passphrase cannot be provided).
Yea, for things where you're giving the private key to somebody, there's a whole corpus of debate on how useful a passphrase would be even if you could give it to them.
For that reason, I'm OK with the default being to passphrase and there being a section of the docs that says "hey, if you need to not have a passphrase for your use case, here's how to strip it off"
If an attacker can get access to your (encrypted) private key file, you have other things to worry about. And the passphrase doesn't help against memory-based attacks (e.g. Heartbleed) anyway.
A passphrase is mostly a hassle; someone will have to enter it after maintenance or (worse) a power outage.
I agree, I find passwords on certificates useful in some circumstances and bothersome in others.
I think putting a password on a root CA certificate is just a bother without any REAL security advantages. First off you'll need to enter it on every restart, secondary the raw private key will need to be in memory after that (which is trivial to extract), and lastly if the machine is completely owned anyway, this seems like "rearrange the deck chairs on the Titanic."
Now putting a password on your SSH keys? Heck yeah. Otherwise if you forget to lock your machine just once, someone can sit down, open your SSH client of choice and have access to a remote session as "you" without the need for a single password. It might not be unbreakable but it is a nice extra layer of security that buys you time if your laptop gets stolen or similar.
if you use that CA to issue a leaf certificate for your server then you don't need the root CA's password or decrypted private key to be in memory all the time, but then
of course you make generating self-signed certs more complicate (generate self-signed root CA protected with password, and use that to issue a passworddless leaf certificate).
We should also notify the differences :
I have compared both and have noticed your oneliner generates a CA certificate (which may not be what we want).
Also the oneliner rely on the /etc/ssl/openssl.conf file which can change over the time, so the generated certificate may be affected too
Fair warning: Firefox specifically won't accept a certificate for an IP address at all ever. It will treat the "domain" like it is mismatching the CN even when they're identical.
It will work fine for self-signed otherwise, you just have to install the root CA into the Firefox trusted store (it doesn't share the operating system's store like other browsers do).
There are a few bugs open about the issue, but they often date back over five years so don't expect this to get fixed. They claim it is a security "feature."
24 comments
[ 2.1 ms ] story [ 68.4 ms ] threadSo, never blindly pipe the web into your bash, kids.
But an unsigned software repository that calls post install scripts seems just as absolutely easy to modify, and we see those regularly.
My software is most easily installed with a piped bash script. In the script contents, I try to explain what's going on. I also at the top indicate that you shouldn't just trust what I am telling you. And then in the documentation, where you are told how to run the script, I tell you to be cautious there as well. (The script just installs the repository, and from there it's all signed and delivered over https).
I could never get over how easy it would be to whitewash a bash script with an rpm just to get some psychological credibility.
If it's not signed and/or delivered over https, it's completely hackable.
That first step of trust, how?
Of course you have to make sure the original install is trustworthy; all you can really do for that is compare the .iso checksum on several different machines. If all those machines are compromised (or there's a hardware-level compromise of your machine) then you're doomed, but that at least makes attacking a lot more costly than it would otherwise be.
[0] https://github.com/docker/notary
That's a bit concerning to me. One would hope that the default behavior would be to put a passphrase on the key.
See Engine Yard for example (not an exception as far I know): https://support.cloud.engineyard.com/hc/en-us/articles/20541...
Now I am not saying the situation is ideal or that I condone it, just passing the information along.
For that reason, I'm OK with the default being to passphrase and there being a section of the docs that says "hey, if you need to not have a passphrase for your use case, here's how to strip it off"
A passphrase is mostly a hassle; someone will have to enter it after maintenance or (worse) a power outage.
I think putting a password on a root CA certificate is just a bother without any REAL security advantages. First off you'll need to enter it on every restart, secondary the raw private key will need to be in memory after that (which is trivial to extract), and lastly if the machine is completely owned anyway, this seems like "rearrange the deck chairs on the Titanic."
Now putting a password on your SSH keys? Heck yeah. Otherwise if you forget to lock your machine just once, someone can sit down, open your SSH client of choice and have access to a remote session as "you" without the need for a single password. It might not be unbreakable but it is a nice extra layer of security that buys you time if your laptop gets stolen or similar.
Yes, there are attack vectors which having a passphrase doesn't protect against.
Yes, passphrases require additional considerations when starting services.
No, this doesn't mean they're "mostly a hassle".
No, you probably shouldn't default to passphraseless keys.
Would having a default that's the opposite of what nearly all users want be sensible?
We should also notify the differences : I have compared both and have noticed your oneliner generates a CA certificate (which may not be what we want). Also the oneliner rely on the /etc/ssl/openssl.conf file which can change over the time, so the generated certificate may be affected too
It will work fine for self-signed otherwise, you just have to install the root CA into the Firefox trusted store (it doesn't share the operating system's store like other browsers do).
There are a few bugs open about the issue, but they often date back over five years so don't expect this to get fixed. They claim it is a security "feature."