On Tue, 2016-01-26 at 10:01 +0100, Matthias Berndt wrote:
OTOH if she is keeping her cert deliberately secure on an encrypted USB storage device, and it gets copied to the unencrypted hard drive, she might not be able to connect tomorrow because she's been *fired* for this breach of security policy.
What kind of security policy requires you to encrypt your USB drives but not your hard drive? That seems contrived to me. Besides, we already copy certificates if they are stored as blobs inside the .ovpn file - I think it's better to be consistent here.
Arguably a daft one. But I've seen stupider :) It does even make a little bit of sense, if the most sensitive item on the computer in question *is* the VPN certificate (perhaps it's used *purely* for accessing web apps and there's no local storage of anything sensitive at all — or local storage *is* carefully managed by other means, and you blindly copying a cert to where *you* choose does not fit in with that solution. Fundamentally though, the principle is simple: You *don't* copy sensitive data from where it originally resides. Whoever created the OpenVPN blob already had a choice of whether to pass the certificate by value (embedded in the blob) or by reference (a filename or PKCS#11 URI). In the latter case, where they have chosen to pass it by reference, it seems entirely wrong to take a *copy* instead of just abiding by their choice.
And if her cert expires and she renews it, even if she is still employed, she's going to get very confused when NM is still using the *old* certificate that she's *deleted* from the USB stick and replaced with a new one.
Either she is technical enough to generate her own keys and certificates, in that case it'll be trivial for her to update her NetworkManager settings accordingly. Or she's not, in which case her administrator will give her a USB stick with the new configuration and she'll import it just as she did before. I think that from a "normal user" pov, copying is definitely what I'd expect. I certainly did.
In my case, we have scripts which talk to the corporate PKI infrastructure and obtain a certificate; placing it in a known location. We configure our VPN to use the certificate from there, and definitely *not* to use a copy of it. Then when the certificate is renewed, the VPN keeps working. Unless NetworkManager did something daft and took a *copy*...
If you do this, make it *optional* and make it clear that you're doing it.How to do that?
Actually, I take it back. It's *already* optional, as I noted above. If the blob contains it by value, then by all means store it where you like. If the blob has a *reference* to an existing file or PKCS#11 URI, then do not copy it ever.
And in fact, do *not* import it to a file elsewhere; import it into gnome-keyring and refer to it by its PKCS#11 URI.Yeah, except she may well not be using gnome. We might be able to come up with something based on the freedesktop secret service api, I'll look into it.
Yeah. Import it into "the default writeable token". Which might even be an NSS database ~/.pki/nssdb. I don't think the secret service API is relevant here; this is all through PKCS#11 and managed by p11-kit. -- dwmw2
Attachment:
smime.p7s
Description: S/MIME cryptographic signature