11–20 of 25 posts
"Secure \n\n The generated private key is passwordless by default." That's a bit concerning to me. One would hope that the default behavior would be to put a passphrase on the key.
A passphrase is mostly a hassle; someone will have to enter it after maintenance or (worse) a power outage.
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."
Earlier quoted context omitted.
For example, in this case any cert you blindly create with the example will have you located in Paris, France, which may not be accurate. So, never blindly pipe the web into your bash, kids.
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 yo…
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.
"Secure \n\n The generated private key is passwordless by default." That's a bit concerning to me. One would hope that the default behavior would be to put a passphrase on the key.
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 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.
"Secure \n\n The generated private key is passwordless by default." That's a bit concerning to me. One would hope that the default behavior would be to put a passphrase on the key.
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.
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.
Earlier quoted context omitted.
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 l…
Earlier quoted context omitted.
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 yo…
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 .i…
Earlier quoted context omitted.
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 .i…
Well, latest SSH vulnerabilities came from the official repos as well. Sure, those were bugs not evil modifications, but still.
Earlier quoted context omitted.
For example, in this case any cert you blindly create with the example will have you located in Paris, France, which may not be accurate. So, never blindly pipe the web into your bash, kids.
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 yo…
Earlier quoted context omitted.
Well, latest SSH vulnerabilities came from the official repos as well. Sure, those were bugs not evil modifications, but still.
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.