OpenBSD Journal

Privilege Separated Key Handling added to relayd(8) and smtpd(8)

Contributed by tbert on from the don't want to bleed all over the keys dept.

In the space of only a few days Reyk Floeter (reyk@) added privilege separated private key handling for two important network-facing daemons, relayd(8) and smtpd(8).

The model was introduced to relayd(8) in this commit on April 18, 2014, and on April 29, 2014 the privilege separated key handling was added to smptd(8) too in this commit.

One more data point for why OpenBSD 5.6 will be, for lack of a better word, awesome.

Here is the relayd(8) commit:

Module name:	src
Changes by:	reyk@cvs.openbsd.org	2014/04/18 07:55:26

Modified files:
	usr.sbin/relayd: Makefile config.c relay.c relayd.c 
	                 relayd.conf.5 relayd.h ssl.c ssl_privsep.c 
Added files:
	usr.sbin/relayd: ca.c 

Log message:
Introduce privsep for private keys:

- Move RSA private keys to a new separate process instead of copying
them to the relays.  A custom RSA engine is used by the SSL/TLS code
of the relay processes to send RSA private key encryption/decryption
(also used for sign/verify) requests to the new "ca" processes instead
of operating on the private key directly.

- Each relay process gets its own related ca process.  Setting
"prefork 5" in the config file will spawn 10 processes (5 relay, 5
ca).  This diff also reduces the default number of relay processes
from 5 to 3 which should be suitable in most installations without a
very heavy load.

- Don't keep text versions of the keys in memory, parse them once and
keep the binary representation.  This might still be the case in
OpenSSL's internals but will be fixed in the library.

This diff doesn't prevent something like "heartbleed" but adds an
additional mitigation to prevent leakage of the private keys from the
processes doing SSL/TLS.

With feedback from many
ok benno@

The strongly related commit to smtpd(8) was accompanied by this message:

Module name:	src
Changes by:	reyk@cvs.openbsd.org	2014/04/29 13:13:14

Modified files:
	usr.sbin/smtpd : ca.c config.c lka.c mproc.c mta_session.c 
	                 pony.c smtp.c smtp_session.c smtpd.c smtpd.h 
	                 ssl.c ssl.h ssl_privsep.c ssl_smtpd.c 

Log message:
Implement RSA privilege separation for OpenSMTPD, based on my previous
implementation for relayd(8).  The smtpd(8) pony processes (mta
client, smtp server) don't keep the private keys in memory but send
their private key operations as imsgs to the "lookup"/mta process.
It's worth mentioning that this prevents acidental private key leakage
as it could have been caused by "Heartbleed".

ok gilles@

Combined with other fencing in and flensing activities, this looks like important steps toward making the next heartbleed a lot less likely to happen.

(Comments are closed)


  1. By Sebastian Rother () on

    Could this method get introduced into other projects as well where crypto is used?

    Of course it was easier to change OpenBSD-affilated projects but maybe other projects would be interested (nginx, dovecot, postfix) as well so maybe it's worth contacting upstream about it?


    Nice work btw.! :-)

    1. By phessler (phessler) on why in god's name am I wearing pants?

      > Could this method get introduced into other projects as well where crypto is used?
      >
      > Of course it was easier to change OpenBSD-affilated projects but maybe other projects would be interested (nginx, dovecot, postfix) as well so maybe it's worth contacting upstream about it?
      >
      >
      > Nice work btw.! :-)

      Yes, this could be used in other projects. As long as they are capable of using privilege separation, this technique will work just fine.

  2. By thomasw_ () thomas.wildeman@gmail.com on

    yes, this is awesome; reyk rocks!

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]