I'm working on advice on automated X.509 certificate generation during package installation.
One aspect is that these files obviously have to be generated on the system during installation (or first service start) and cannot be shipped in the package. Some existing RPMs just drop files into /etc/pki/certs and /etc/pki/tls/private, without marking them as ghost files or configuration files. (I'm not even sure if you can mark something for which no content is provided in the RPM as a configuration file.)
I wonder what an ideal RPM package would do in this case?
On Thu, 2014-04-24 at 15:47 +0200, Florian Weimer wrote:
I'm working on advice on automated X.509 certificate generation during package installation.
One aspect is that these files obviously have to be generated on the system during installation (or first service start) and cannot be shipped in the package. Some existing RPMs just drop files into /etc/pki/certs and /etc/pki/tls/private, without marking them as ghost files or configuration files. (I'm not even sure if you can mark something for which no content is provided in the RPM as a configuration file.)
I wonder what an ideal RPM package would do in this case?
If you know what service is going to require the cert, you might copy the pattern from openssh, where sshd-keygen.service runs as a prereq for sshd itself.
- ajax
On Thu, Apr 24, 2014 at 10:10:15AM -0400, Adam Jackson wrote:
On Thu, 2014-04-24 at 15:47 +0200, Florian Weimer wrote:
I'm working on advice on automated X.509 certificate generation during package installation.
One aspect is that these files obviously have to be generated on the system during installation (or first service start) and cannot be shipped in the package. Some existing RPMs just drop files into /etc/pki/certs and /etc/pki/tls/private, without marking them as ghost files or configuration files. (I'm not even sure if you can mark something for which no content is provided in the RPM as a configuration file.)
I wonder what an ideal RPM package would do in this case?
If you know what service is going to require the cert, you might copy the pattern from openssh, where sshd-keygen.service runs as a prereq for sshd itself.
This, or first service start, are good ideas. Remember that your package may not be getting installed on the system where it eventually runs -- livecd's, cloud images, etc. can be created in situations where the build host is totally different from the final target. eg. creating an image inside a mock running on a RHEL6 system.
On Thu, 24 Apr 2014, Florian Weimer wrote:
I'm working on advice on automated X.509 certificate generation during package installation.
I would strongly recommend doing it on first service start. I've lived through the FreeS/WAN times and my experience with it for 15+ years caused us (in libreswan) to completely refrain from geenrating raw RSA keys or certificates. (But we don't need to do OE/anon TLS)
Entropy was always a big issue. Even doing it automatically on first service start was problematic, as people would regularly kill processes of the service because it took too long. One big mistake we made back in those days was that the process was not atomic, so the file listing the available keys would be half written and corrupt.
One aspect is that these files obviously have to be generated on the system during installation (or first service start) and cannot be shipped in the package. Some existing RPMs just drop files into /etc/pki/certs and /etc/pki/tls/private, without marking them as ghost files or configuration files. (I'm not even sure if you can mark something for which no content is provided in the RPM as a configuration file.)
Those are global locations, right? While certs could go there, CAcerts should not just be dropped in there - especially not self-signed ones.
I wonder what an ideal RPM package would do in this case?
How many packages would actually perform any kind of "opportunistic encryption"? I know the mail servers prefer a selfsigned cert over no cert whatsoever, but what other applications have this issue of "better unknown certificate than plaintext" ?
For example, I dont think a jabber server package should generate and use a self-signed cert.
Paul (sorry, not really know the answer to your rpm question)
Paul Wouters paul@nohats.ca writes:
[...] How many packages would actually perform any kind of "opportunistic encryption"? I know the mail servers prefer a selfsigned cert over no cert whatsoever, but what other applications have this issue of "better unknown certificate than plaintext" ?
Probably all that listen on ssl/tls-capable sockets. (stap-server & pcp happen to be ones freshly in mind). In the absence of network-layer opportunistic encryption, it's the best we can do.
- FChE
On 04/24/2014 04:20 PM, Paul Wouters wrote:
On Thu, 24 Apr 2014, Florian Weimer wrote:
I'm working on advice on automated X.509 certificate generation during package installation.
I would strongly recommend doing it on first service start. I've lived through the FreeS/WAN times and my experience with it for 15+ years caused us (in libreswan) to completely refrain from geenrating raw RSA keys or certificates. (But we don't need to do OE/anon TLS)
I don't think "openssl genrsa 2048" has this issue on today's machines. (I know I saw it with GNUTLS.)
One aspect is that these files obviously have to be generated on the system during installation (or first service start) and cannot be shipped in the package. Some existing RPMs just drop files into /etc/pki/certs and /etc/pki/tls/private, without marking them as ghost files or configuration files. (I'm not even sure if you can mark something for which no content is provided in the RPM as a configuration file.)
Those are global locations, right? While certs could go there, CAcerts should not just be dropped in there - especially not self-signed ones.
It would be a self-signed non-CA certificate. A package-specific directory would work as well.
I wonder what an ideal RPM package would do in this case?
How many packages would actually perform any kind of "opportunistic encryption"? I know the mail servers prefer a selfsigned cert over no cert whatsoever, but what other applications have this issue of "better unknown certificate than plaintext" ?
It came up in the context of clustering software where the single certificate/key pair (shared across the cluster) would be used to secure cluster membership. The cluster nodes trust each other as a result of the protocol features, so they could access their private keys anyway, even if they were separate.
On Thu, 24 Apr 2014, Florian Weimer wrote:
I don't think "openssl genrsa 2048" has this issue on today's machines. (I know I saw it with GNUTLS.)
I was sceptical, so I tried this on a freshly booted VM:
root@bofh:~# virsh start north Domain north started root@bofh:~# ssh root@north Last login: Wed Apr 23 11:54:46 2014 [root@north ~]# time openssl genrsa 2048 [...] real 0m0.382s user 0m0.267s sys 0m0.003s
Call me very surprised! We finally have real entropy in VMs now. Good news!
It came up in the context of clustering software where the single certificate/key pair (shared across the cluster) would be used to secure cluster membership. The cluster nodes trust each other as a result of the protocol features, so they could access their private keys anyway, even if they were separate.
Ah.. understood.
Paul
On 04/24/2014 05:39 PM, Paul Wouters wrote:
On Thu, 24 Apr 2014, Florian Weimer wrote:
I don't think "openssl genrsa 2048" has this issue on today's machines. (I know I saw it with GNUTLS.)
I was sceptical, so I tried this on a freshly booted VM:
root@bofh:~# virsh start north Domain north started root@bofh:~# ssh root@north Last login: Wed Apr 23 11:54:46 2014 [root@north ~]# time openssl genrsa 2048 [...] real 0m0.382s user 0m0.267s sys 0m0.003s
Call me very surprised! We finally have real entropy in VMs now. Good news!
I'm afraid your conclusion does not follow from the facts. "openssl genrsa" simply does not ensure that actual physical entropy is available. I'll make this quite explicit in my advice.
Most of the "openssl" subcommands are tools for testing and debugging OpenSSL itself, and should not be used for other purposes.
On 04/24/2014 08:39 AM, Paul Wouters wrote:
On Thu, 24 Apr 2014, Florian Weimer wrote:
I don't think "openssl genrsa 2048" has this issue on today's machines. (I know I saw it with GNUTLS.)
I was sceptical, so I tried this on a freshly booted VM:
root@bofh:~# virsh start north Domain north started root@bofh:~# ssh root@north Last login: Wed Apr 23 11:54:46 2014 [root@north ~]# time openssl genrsa 2048 [...] real 0m0.382s user 0m0.267s sys 0m0.003s
Call me very surprised! We finally have real entropy in VMs now. Good news!
That is surprising, I wonder if it's using /dev/random or /dev/urandom. Twice I've done an install of freeipa on a freshly installed vm and both times it wouldn't start. I finally figured out that named needs to read from /dev/random when starting up the first time and it wasn't getting anything. The first time I ran the command manually telling it to use /dev/urandom. The second time I ran it manually and did a lot of filesystem and network access, hoping that it would generate entropy. Which it did seem to do as the command ran successfully.
On Thu, Apr 24, 2014 at 11:39:42AM -0400, Paul Wouters wrote:
On Thu, 24 Apr 2014, Florian Weimer wrote:
I don't think "openssl genrsa 2048" has this issue on today's machines. (I know I saw it with GNUTLS.)
I was sceptical, so I tried this on a freshly booted VM:
root@bofh:~# virsh start north Domain north started root@bofh:~# ssh root@north Last login: Wed Apr 23 11:54:46 2014 [root@north ~]# time openssl genrsa 2048 [...] real 0m0.382s user 0m0.267s sys 0m0.003s
Call me very surprised! We finally have real entropy in VMs now. Good news!
Some virtual machines will have virtio-rng (a virtio device that provides entropy to the guest from the host's /dev/urandom). This requires a driver, but it is commonly available in recent Linux guests.
Some may have been created with virt-sysprep/virt-builder which adds randomness directly to /var/lib/random-seed (or wherever systemd has moved that file to this week).
Rich.
devel@lists.stg.fedoraproject.org
-
Adam Jackson -
Brian C. Lane -
Florian Weimer -
Frank Ch. Eigler -
Paul Wouters -
Richard W.M. Jones -
Samuel Sieb