Contributed by tbert on from the don't want to bleed all over the keys dept.
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: firstname.lastname@example.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: email@example.com 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)