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.
