[Freeswitch-users] TLS key management (was FreeSWITCH Weekly News and Notes)

[Daniel Pocock]

On 28/08/12 23:07, Michael Collins wrote:

> Tomorrow we hope to have a discussion about
> TLS<http://wiki.freeswitch.org/wiki/Tls>.
> We have several community members who are experienced with key and
> certificate management and we will be calling upon them to share their
> experience with the rest of us. After that we will have an open discussion.


FYI, this came up at DebConf, some of us are thinking about similar
issues at a platform level:


http://penta.debconf.org/dc12_schedule/events/895.en.html

and notes from the session can be accessed with the gobby tool (sorry I
can't find this online somewhere, I've cut and pasted below for
convenience):

http://wiki.debian.org/gobby.debian.org

  look under debconf12/bof/X.509


As was emphasized at DebConf, it is a particular issue for VoIP
services, because different applications (e.g. a Jabber server and a SIP
server) can share the same key material (no need to waste money buying a
cert for each protocol), but sharing private keys between different
applications requires a more rigorous platform-wide effort to protect
the keys.






X.509 Certificate, Root CA, and Key best practices
==================================================

Confusing for packagers, admins, and users.  Let's fix!

Servers:
--------

 * where to store secret key material?  (/etc/ssl/private)
 * sharing key material across services?
 * locations for server certificates?
 * auto-creation of key/cert/certreq?
 * intermediate CA certificate storage
 * list of trusted root authorities for client certs -- shared?

Clients:
--------

 * list of trusted root authorities -- system store?  end-user override?
   -> Make all clients use the same store?
 * managing per-user certificates and secret keys -- p11-kit
 * how do we deal with root authorities for different contexts (web,
e-mail, code-signing, etc)
 * CRL/OCSP check?
   -> blacklist
   IIRC Microsoft now distributes blacklists via their update service
(chrome iirc too)
 * What can the cert be used for (email, website, software)
   -> mozilla has that information in it's store
   -> openssl can store it, but then uses a different header that others
might not be able to read

CSR process:
------------

(clients and servers) -- how can we make this less painful?

affected packages:
------------------

 * iceweasel/icedove (via nss and libckbi.so)
 * ca-certificates (potential split into ca-certificates,
ca-certificates-mozilla,
   ca-certificates-debconf, etc.)
 * ssl-cert
 * ca-certificates-java
 * kdelibs5-data: /usr/share/kde4/apps/kssl/ca-bundle.crt
 * nmap: /usr/share/ncat/ca-bundle.crt
 * ruby: /usr/lib/ruby/XXX/rubygems/ssl_certs/ca-bundle.pem
 * sympa: /usr/share/sympa/default/ca-bundle.crt
 * nutsurf-common: /usr/share/netsurf/ca-bundle.txt
 * abiword: /usr/share/abiword-2.9/certs/cacert.pem
 * acgvision-agent: /etc/acgvision/acgTrustStore.certs
 * apparmor: /etc/apparmor.d/abstractions/ssl_certs
 * gnupg2: /usr/share/gnupg2/com-certs.pem
 * libpurple0: /usr/share/purple/ca-certs/
 * linphone-common: /usr/share/linphone/rootca.pem
 * ntop-data: /usr/share/ntop/ntop-cert.pem
 * phoronix-test-suite
 * pidgin-microblog
 * burp
 * cpushare
 * acl2-books-certs
 * postgresql
 * openssl (embeds /etc/ssl/certs)
 * gnutls (no default authorities -- is this a good thing)
 * dovecot (and other IMAPs, POP3s servers)
 * exim4 and other MTAs (SMTPS, SMTP AUTH)
 * apache
 * vsftpd
 * resiprocate
 * XMPP servers
 * ...

normalizing and de-confusing names of directories:
--------------------------------------------------

 * /etc/ssl → /etc/x509 ?
 * .../certs → .../cas ?
 * /etc/ssl/public for non-ca certificates?

toolsmithing suggestions
------------------------

 * monitoring/review of sensitive directories (e.g. cronjob to review
these directories and report on changes,
   like many people do already with nagios/icinga)
 * tool to inspect/interrogate all open sockets that appear to support
TLS/SSL and report problems
 * something like db-config-common for X.509
 * ssl-cert and ca-certificates ca-certificates-java
 * per-machine root-authority that could be enabled by default?

Next steps:
-----------

 * best practices documentation: http://wiki.debian.org/X.509
 * what of this can or should be policy?
 * how can we get project-wide rough consensus
 * come up with a plan for how to file bugs; i.e. in the bug report,
   we need a suggested plan for what to do differently


Objectives:
-----------

 * make it easy for an administrator to configure his or her system for
X.509 certificates with a single easily auditable point of control
 * make it easy for a packager to rely on certificate creation,
management, expiry, etc. so that each package doesn't need to
reimplement these functions
 * make it easy for a user to use client-side certificates across tools
 * make it easy for a user to connect to public services predictably
with different tools

Other Distros Approaches
------------------------
 * Fedora's attempt to replace NSS
   http://fedoraproject.org/wiki/Nss_compat_ossl
   http://fedoraproject.org/wiki/FedoraCryptoConsolidation