new cipher in OpenSSL, need to rebuild Postfix?
in [Postfix]
|
From: Wietse Venema on 25 Mar 2010 07:13 Gregory BELLIER: > > At this point, you really need to step back, take a deep breath, and > > use OpenSSL as-is. > > > As I said, it's to learn. If I do nothing then it's pointless. > > What I ask is not your point on if it's relevant to do it or not because > we all know it's not. With intense effort, the Postfix warranty and support cover the official OpenSSL API. A library or system API is like a contract. - If Postfix violates a library or system API, it's our bug and we fix Postfix. - If a library or system implementation violates the API, it is their bug and they fix it. We sometimes provide workarounds. I provide no Postfix warranty and support for unofficial modifications to system or library APIs. I encourage my developers to do the same. Wietse
From: Victor Duchovni on 25 Mar 2010 12:12 On Thu, Mar 25, 2010 at 10:31:40AM +0100, Gregory BELLIER wrote: >> At this point, you really need to step back, take a deep breath, and >> use OpenSSL as-is. >> > As I said, it's to learn. If I do nothing then it's pointless. No need to change the OpenSSL APIs to discover how Postfix handles new SSL ciphers, a quick look at the Postfix documentation: http://www.postfix.org/TLS_README.html#client_cipher http://www.postfix.org/TLS_README.html#server_cipher should make it clear that new ciphers are supported automatically, as soon as they become available in OpenSSL. Postfix code modifications would only become necessary if OpenSSL added a new key-exchange algorithm that required new server-side parameter settings. - To enable EDH ciphers, the server needs to specify DH parameters, a large prime and a generator (usually 2) of multicative group of non-zero residues modulo that prime. A pair of "parameters" is required, one for 512-bit EDH and another for 1024-bit EDH. http://www.postfix.org/postconf.5.html#smtpd_tls_dh1024_param_file http://www.postfix.org/postconf.5.html#smtpd_tls_dh512_param_file with OpenSSL 1.0.0 (any day now...), there is support for EECDH key-exchange, which requires the server to choose a suitable elliptic curve (I saw it called an "epileptic curve" recently, which has a certain irony). New code was added to Postfix (some time ago now) to allow users to specify a suitably sensible curve: http://www.postfix.org/postconf.5.html#smtpd_tls_eecdh_grade Postfix would also need new code if OpenSSL adds more public key types for X.509 certificates, and we want to allow users to install more than 3 different certificates for a single server---one for each desired public key type. It is not widely known that the parameter pairs: http://www.postfix.org/postconf.5.html#smtpd_tls_cert_file http://www.postfix.org/postconf.5.html#smtpd_tls_key_file http://www.postfix.org/postconf.5.html#smtpd_tls_dcert_file http://www.postfix.org/postconf.5.html#smtpd_tls_dkey_file http://www.postfix.org/postconf.5.html#smtpd_tls_eccert_file http://www.postfix.org/postconf.5.html#smtpd_tls_eckey_file are functionally equivalent, you can use any parameter pair to load any type of compatible certificate/key. So, you can associate up to 3 keys/certificates pairs using any public-key algorithm (supported by OpenSSL) so long as each of the three certificates uses a different algorithm. You can set "EC" certs via the "cert_file", "RSA" certs via the "dcert_file" and "GOST" keys via the "eccert_file", if that tickles your fancy. So, Postfix will continue to support many future versions of OpenSSL with no code change in Postfix. From time to time, there may be new capabilities in OpenSSL (not ciphers, which we handle transparently, but something more major) that may be of interest to Postfix users. For example, it may be interesting to support SNI at some point in the future, or to make the Postfix server-side session cache "session-ticket" aware. http://tools.ietf.org/html/rfc4507 so some future change in the Postfix TLS module is likely inevitable, but new ciphers are by far the least likely reason for new Postfix code, these are handled generically by Postfix, since they are handled generically by OpenSSL. -- Viktor. P.S. Morgan Stanley is looking for a New York City based, Senior Unix system/email administrator to architect and sustain our perimeter email environment. If you are interested, please drop me a note.
From: Gregory BELLIER on 25 Mar 2010 13:16 Victor Duchovni a e'crit: > On Thu, Mar 25, 2010 at 10:31:40AM +0100, Gregory BELLIER wrote: > > >>> At this point, you really need to step back, take a deep breath, and >>> use OpenSSL as-is. >>> >>> >> As I said, it's to learn. If I do nothing then it's pointless. >> > > No need to change the OpenSSL APIs to discover how Postfix handles new > SSL ciphers, a quick look at the Postfix documentation: > > http://www.postfix.org/TLS_README.html#client_cipher > http://www.postfix.org/TLS_README.html#server_cipher > > should make it clear that new ciphers are supported automatically, as > soon as they become available in OpenSSL. Postfix code modifications > would only become necessary if OpenSSL added a new key-exchange algorithm > that required new server-side parameter settings. > > - To enable EDH ciphers, the server needs to specify DH parameters, > a large prime and a generator (usually 2) of multicative group of > non-zero residues modulo that prime. A pair of "parameters" is required, > one for 512-bit EDH and another for 1024-bit EDH. > > http://www.postfix.org/postconf.5.html#smtpd_tls_dh1024_param_file > http://www.postfix.org/postconf.5.html#smtpd_tls_dh512_param_file > > with OpenSSL 1.0.0 (any day now...), there is support for EECDH > key-exchange, which requires the server to choose a suitable elliptic > curve (I saw it called an "epileptic curve" recently, which has a certain > irony). New code was added to Postfix (some time ago now) to allow users > to specify a suitably sensible curve: > > http://www.postfix.org/postconf.5.html#smtpd_tls_eecdh_grade > > Postfix would also need new code if OpenSSL adds more public key types > for X.509 certificates, and we want to allow users to install more > than 3 different certificates for a single server---one for each desired > public key type. > > It is not widely known that the parameter pairs: > > http://www.postfix.org/postconf.5.html#smtpd_tls_cert_file > http://www.postfix.org/postconf.5.html#smtpd_tls_key_file > > http://www.postfix.org/postconf.5.html#smtpd_tls_dcert_file > http://www.postfix.org/postconf.5.html#smtpd_tls_dkey_file > > http://www.postfix.org/postconf.5.html#smtpd_tls_eccert_file > http://www.postfix.org/postconf.5.html#smtpd_tls_eckey_file > > are functionally equivalent, you can use any parameter pair to load > any type of compatible certificate/key. So, you can associate up to > 3 keys/certificates pairs using any public-key algorithm (supported > by OpenSSL) so long as each of the three certificates uses a different > algorithm. > > You can set "EC" certs via the "cert_file", "RSA" certs via the > "dcert_file" and "GOST" keys via the "eccert_file", if that tickles > your fancy. > > So, Postfix will continue to support many future versions of OpenSSL > with no code change in Postfix. > > From time to time, there may be new capabilities in OpenSSL (not ciphers, > which we handle transparently, but something more major) that may be of > interest to Postfix users. For example, it may be interesting to support > SNI at some point in the future, or to make the Postfix server-side session > cache "session-ticket" aware. > > http://tools.ietf.org/html/rfc4507 > > so some future change in the Postfix TLS module is likely inevitable, > but new ciphers are by far the least likely reason for new Postfix > code, these are handled generically by Postfix, since they are handled > generically by OpenSSL. > > Thank you Victor for this complete response. Time was taken and I can only appreciate it. You're right, I don't need to change anything in OpenSSL to learn how Postfix does things. In fact, I did the other way. I tested in OpenSSL and then I wandered if Postfix could benefit from it. However, I didn't ask if new code was necessary in Postfix so it can be aware of a new cipher. As you said, it's automatical. I asked if, in your opinion, it would be necessary to build postfix (as is) against a new OpenSSL. In my opinon, the only need to build against a new OpenSSL would be if Postfix needs to call new encryption symbols which would be the new cipher. But I guess it's not Postfix's deal to call directly the OpenSSL encryption functions. But apparently, there is no need to do such a thing. I think I've been misunderstood because I didn't ask to change or support anything different from the tree. A simple yes/no response would have suffice. Thank you all for your time. Gregory.
From: Victor Duchovni on 16 Apr 2010 11:29 On Thu, Mar 25, 2010 at 06:16:22PM +0100, Gregory BELLIER wrote: > However, I didn't ask if new code was necessary in Postfix so it can be > aware of a new cipher. As you said, it's automatical. I asked if, in your > opinion, it would be necessary to build postfix (as is) against a new > OpenSSL. If you are using shared libraries, and modify OpenSSL without modifying the ABI, then Postfix can immediately use the new library without recompiling, provided the new library has the same "soname" as the old. With OpenSSL, past releases have changed the ABI from time to time, and upgrading 0.9.6 -> 0.9.7 -> 0.9.8 -> 1.0.0 (which is finally out, hooray!) requires recompiling and re-linking Postfix. Patchlevels within a particular release level which don't change the ABI, even if they introduce new ciphers, do not require re-compilation of a Postfix that uses shared libraries. -- Viktor. P.S. Morgan Stanley is looking for a New York City based, Senior Unix system/email administrator to architect and sustain our perimeter email environment. If you are interested, please drop me a note.
First
|
Prev
|
Pages: 1 2 Prev: redirect local(8) delivery to $local@$mydomain ? Next: Relayhost dependend on destination MX |