--001a11447608411b0a054928d3c2 Content-Type: text/plain; charset=UTF-8 I completely agree that this doesn't add any security when running slapd. However, when I originally wrote this patch, I was more targeting API usage, and in particular, client-side API usage. My goal was to allow a user to present an encrypted key (stored on disk) and a password (only held in memory), and use these to query a secure LDAP server. The issue of how the password got into memory is certainly beyond the scope of OpenLDAP in this case, but it certainly could be done securely in a way that wouldn't leave it exposed to a third-party with file-system access.
For example (in the use case that motivated me originally), an sysadmin could input the password through an online form, submit said form to a Python webserver over HTTPS, the Python code could pass the password to OpenLDAP through a Python interface like python-ldap ( https://www.python-ldap.org/), and then use the LDAPS or STARTTLS connection to talk securely to some LDAP server elsewhere. All without an unencrypted keyfile or a password ever existing on disk, hence the added security. If you feel that supporting encrypted keyfiles in slapd is a bad design choice, I'm willing to rework the patch to drop that part and only keep the API-level support. Personally, I would argue that it doesn't hurt to support the feature, although perhaps my documentation changes could do a better job emphasizing the inherent security limitations. Let me know what you think (or if this discussion should take place on a list, let me know which/where). On Wed, Feb 22, 2017 at 1:11 PM, Howard Chu <[email protected]> wrote: > [email protected] wrote: > >> Full_Name: Alec Cooper >> Version: HEAD of master branch >> OS: Ubuntu Linux 16.04 >> URL: ftp://ftp.openldap.org/incoming/Alec-Cooper-160827.patch >> Submission from: (NULL) (73.134.243.211) >> >> >> Adding support for encrypted server private keys. >> > > Thank you for your submission. I must compliment you on providing such a > comprehensive and well-written contribution. Unfortunately the feature > itself is clearly not useful. Perhaps you should have raised this topic on > the openldap-devel list for discussion before spending your time writing it. > > All your feature does is embed the encryption key in the filesystem, so an > encrypted private key is still no more secure than an unencrypted one. It > still just depends on setting proper file access permissions, and the > current documentation already makes that point. > > Indeed, all it does is give the false illusion of enhancing security, and > followups like [email protected]'s shows that people will easily > fall for such illusions. > > I regret having to reject such a well written contribution, but we cannot > in good conscience accept a security feature that doesn't actually improve > security. > >> >> The meat of this patch is changes to tls2.c, tls_g.c, tls_m.c, and >> tls_o.c to >> send a password to the underlying TLS library. >> >> Changes to ldap.h, init.c and ldap-int.h expose the new >> LDAP_OPT_X_TLS_KEYPASSWORD in the main API. >> >> Changes in the contrib/ldapc++ directory expose the corresponding >> TlsOptions::KEYPASSWORD option in the C++ API. >> >> Changes in the servers directory expose equivalent options for servers as >> configuration file entries or environment variables. >> >> Changes in the doc directory add documentation about the new options and >> remove >> statements that indicated that encrypted keyfiles are not supported. >> >> New files in the test directory are for testing TLS connections, both in >> general >> and with encrypted keyfiles. Tests pass for OpenSSL and GnuTLS using PEM >> formatted certs and keys, and for MozNSS using cert/key databases. The >> new unit >> test (test065-tls) has been written to detect when using NSS, and use the >> cert/key databases in this case. I have been unable to get a working >> version of >> libnsspem, so I cannot test MozNSS with (or without) encrypted keyfiles - >> testing for this case would be welcome! >> >> Notice of origin: The attached patch file is derived from OpenLDAP >> Software. All >> of the modifications to OpenLDAP Software represented in the following >> patch >> were developed by Alec Cooper [email protected]. I have not assigned >> rights >> and/or interest in this work to any party. >> Rights statement: I, Alec Cooper, hereby place the following >> modifications to >> OpenLDAP Software (and only these modifications) into the public domain. >> Hence, >> these modifications may be freely used and/or redistributed for any >> purpose with >> or without attribution and/or other notice. >> >> The patch has been uploaded to the OpenLDAP FTP server and can be found at >> ftp://ftp.openldap.org/incoming/Alec-Cooper-160827.patch >> >> >> > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --001a11447608411b0a054928d3c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I completely agree that this doesn't add any security = when running slapd. However, when I originally wrote this patch, I was more= targeting API usage, and in particular, client-side API usage. My goal was= to allow a user to present an encrypted key (stored on disk) and a passwor= d (only held in memory), and use these to query a secure LDAP server. The i= ssue of how the password got into memory is certainly beyond the scope of O= penLDAP in this case, but it certainly could be done securely in a way that= wouldn't leave it exposed to a third-party with file-system access.<di= v><br></div><div>For example (in the use case that motivated me originally)= , an sysadmin could input the password through an online form, submit said = form to a Python webserver over HTTPS, the Python code could pass the passw= ord to OpenLDAP through a Python interface like python-ldap (<a href=3D"htt= ps://www.python-ldap.org/">https://www.python-ldap.org/</a>), and then use = the LDAPS or STARTTLS connection to talk securely to some LDAP server elsew= here. All without an unencrypted keyfile or a password ever existing on dis= k, hence the added security.<div><br></div><div>If you feel that supporting= encrypted keyfiles in slapd is a bad design choice, I'm willing to rew= ork the patch to drop that part and only keep the API-level support. Person= ally, I would argue that it doesn't hurt to support the feature, althou= gh perhaps my documentation changes could do a better job emphasizing the i= nherent security limitations. Let me know what you think (or if this discus= sion should take place on a list, let me know which/where).=C2=A0</div></di= v><div><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_q= uote">On Wed, Feb 22, 2017 at 1:11 PM, Howard Chu <span dir=3D"ltr"><<a = href=3D"mailto:[email protected]"; target=3D"_blank">[email protected]</a>></span= > wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo= rder-left:1px #ccc solid;padding-left:1ex"><a href=3D"mailto:ahnolds@gmail.= com" target=3D"_blank">[email protected]</a> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Alec Cooper<br> Version: HEAD of master branch<br> OS: Ubuntu Linux 16.04<br> URL: <a href=3D"ftp://ftp.openldap.org/incoming/Alec-Cooper-160827.patch"; r= el=3D"noreferrer" target=3D"_blank">ftp://ftp.openldap.org/incomin<wbr>g/Al= ec-Cooper-160827.patch</a><br> Submission from: (NULL) (73.134.243.211)<br> <br> <br> Adding support for encrypted server private keys.<br> </blockquote> <br> Thank you for your submission. I must compliment you on providing such a co= mprehensive and well-written contribution. Unfortunately the feature itself= is clearly not useful. Perhaps you should have raised this topic on the op= enldap-devel list for discussion before spending your time writing it.<br> <br> All your feature does is embed the encryption key in the filesystem, so an = encrypted private key is still no more secure than an unencrypted one. It s= till just depends on setting proper file access permissions, and the curren= t documentation already makes that point.<br> <br> Indeed, all it does is give the false illusion of enhancing security, and f= ollowups like <a href=3D"mailto:[email protected]"; target=3D"_blank">b= [email protected]</a>'s shows that people will easily fall for such= illusions.<br> <br> I regret having to reject such a well written contribution, but we cannot i= n good conscience accept a security feature that doesn't actually impro= ve security.<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> The meat of this patch is changes to tls2.c, tls_g.c, tls_m.c, and tls_o.c = to<br> send a password to the underlying TLS library.<br> <br> Changes to ldap.h, init.c and ldap-int.h expose the new<br> LDAP_OPT_X_TLS_KEYPASSWORD in the main API.<br> <br> Changes in the contrib/ldapc++ directory expose the corresponding<br> TlsOptions::KEYPASSWORD option in the C++ API.<br> <br> Changes in the servers directory expose equivalent options for servers as<b= r> configuration file entries or environment variables.<br> <br> Changes in the doc directory add documentation about the new options and re= move<br> statements that indicated that encrypted keyfiles are not supported.<br> <br> New files in the test directory are for testing TLS connections, both in ge= neral<br> and with encrypted keyfiles. Tests pass for OpenSSL and GnuTLS using PEM<br= > formatted certs and keys, and for MozNSS using cert/key databases. The new = unit<br> test (test065-tls) has been written to detect when using NSS, and use the<b= r> cert/key databases in this case. I have been unable to get a working versio= n of<br> libnsspem, so I cannot test MozNSS with (or without) encrypted keyfiles -<b= r> testing for this case would be welcome!<br> <br> Notice of origin: The attached patch file is derived from OpenLDAP Software= . All<br> of the modifications to OpenLDAP Software represented in the following patc= h<br> were developed by Alec Cooper <a href=3D"mailto:[email protected]"; target= =3D"_blank">[email protected]</a>. I have not assigned rights<br> and/or interest in this work to any party.<br> Rights statement: I, Alec Cooper, hereby place the following modifications = to<br> OpenLDAP Software (and only these modifications) into the public domain. He= nce,<br> these modifications may be freely used and/or redistributed for any purpose= with<br> or without attribution and/or other notice.<br> <br> The patch has been uploaded to the OpenLDAP FTP server and can be found at<= br> <a href=3D"ftp://ftp.openldap.org/incoming/Alec-Cooper-160827.patch"; rel=3D= "noreferrer" target=3D"_blank">ftp://ftp.openldap.org/incomin<wbr>g/Alec-Co= oper-160827.patch</a><br> <br> <br><span class=3D"HOEnZb"><font color=3D"#888888"> </font></span></blockquote><span class=3D"HOEnZb"><font color=3D"#888888"> <br> <br> -- <br> =C2=A0 -- Howard Chu<br> =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com"; rel=3D"noreferrer" target=3D"_blank">http://www.symas= .com</a><br> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" rel=3D"noreferrer" target=3D"_blank">http://highlandsun.com/h= yc/</a><br> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" rel=3D"noreferrer" target=3D"_blank">http://www.openldap.org/proje= c<wbr>t/</a><br> </font></span></blockquote></div><br></div> --001a11447608411b0a054928d3c2--
