Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: Gregory BELLIER (gregory.belliergmail.com)
Date: Thu Mar 25 2010 - 12:16:22 CDT
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:
> 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.
> 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:
> 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:
> 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
> 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.
> 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
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
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
Thank you all for your time.