mkcert icon indicating copy to clipboard operation
mkcert copied to clipboard

Touch Bar and Keychain support

Open lgarron opened this issue 6 years ago • 6 comments

Since name-constrained certs don't work everywhere, leaving the signing key lying around still exposes you to risk of having all of your secure traffic intercepted.

My first thought was that it would be nice to be able to keep the key on a Yubikey, but putting it in the macOS keychain under password/Touch ID protection (or something similar like GNOME keyring) would also be a reasonable intermediate option.

Do you think that would fit in the scope of this project, or should it perhaps be something separate? (Is there already a PKCS#11 abstraction in Golang that would support this functionality?)

lgarron avatar Jul 06 '18 23:07 lgarron

The underlying implementation should definitely be a separate package. There is a commonly used PKCS#11 package but it's a pain to use. Somewhere on my TODO list there is a easy to use Touch Bar backed crypto.Signer, but no concrete plans.

The implementation in mkcert would have to be completely automated, but even then I'm not convinced it's worth it: what's an attacker that can read arbitrary 600 files from disk, but not inspect memory?

FiloSottile avatar Jul 06 '18 23:07 FiloSottile

Ah, I had the same concern. I love how streamlined this tool makes things, handling both the creation and the installation, but leaving a CA private key around that allows creating a trusted certificate for any domain is more liability than I wanted to sign up for in order to make a key that works for localhost (and maybe staging.mydomain).

I want to be very reserved about adding any extra complexity to this tool, since its strength is in its simple interface, but since we have Keychain already the standard mechanism for protecting secrets, I think that lgarron's suggestion makes a lot of sense.

keturn avatar Jul 24 '18 18:07 keturn

what's an attacker that can read arbitrary 600 files from disk, but not inspect memory?

I think, at least since OS X 10.11 (El Capitan), this is a common configuration, thanks to System Integrity Protection. For example, I can't use dtrace on a python process, even though I'm the user that owns the process. And that's a brew-installed python, not the system one.

keturn avatar Jul 24 '18 18:07 keturn

Ok, thought about it a bit more, and although I don't have time to implement it myself at the moment, I would welcome a seamless integration where the key is stored in the Touch Bar and used via Touch ID. Stretch goal, showing the hostname on the Touch Bar (but this might be extremely hard to do securely, and I'd rather not do it if not securely). And I guess a Keychain fallback (SIP is a good point).

No flag or option, and automatic migration of existing keys.

Possibly these building blocks would be in a separate package exposing simply New and crypto.Signer.

FiloSottile avatar Jul 25 '18 17:07 FiloSottile

(I still maintain that an attacker can modify the mkcert binary and do approximately what they want, modulo a very serious Touch Bar applet implementation, and that a compromised endpoint is a compromised endpoint, but I'll concede that a file disclosure vulnerability is somewhat more likely than full compromise on unsandboxed desktop systems.)

FiloSottile avatar Jul 25 '18 17:07 FiloSottile

// Disclaimer: this is not my area of expertise :)

I was considering writing a wrapper for mkcert that encrypts and decrypts the rootCA-key.pem and rootCA.pem files between usages using a standalone password.

mishawakerman avatar Jun 18 '20 23:06 mishawakerman