Hello David,

Thank you for your very detailed response. As far as I understand, it should primarily support PFS and choose that kind of ciphers with higher priority. Ciphers with a higher encryption should in general always be priorized. Older ciphers don't have to be banned, unless they are considered insecure (because of outdated/depricated) or flawed.

I did some online testing with a online smtp ssl checker: it showed PFS were not supported, but after enabling mercurys session logging I've seen that:

ECDHE-RSA-AES256-SHA, SSLv3, Kx=ECDH, Au=RSA, Enc=AES(256), Mac=SHA1

DHE-RSA-AES256-GCM-SHA384, TLSv1.2, Kx=DH, Au=RSA, Enc=AESGCM(256), Mac=AEAD

ECDHE-RSA-AES256-SHA384, TLSv1.2, Kx=ECDH, Au=RSA, Enc=AES(256), Mac=SHA384

are often negotiated for encrypted communication. These are PFS ciphers. So the online testing doesn't seem to be reliable.

The person of the Data Protection Authority we are in contact with is an IT-Professional. I've heard from him that he had already contact with other mail server developers to help them out with all these issues. I've heard also that they have their own software for testing purposes. My suggestion: I will get in touch with him, show him this thread and ask him to get in direct contact with you. I think that would make more sense. 

Thanky you very much in advance.

Claudio

Dear Mercury Development-Team,

The German Data Protection

Authority is enforcing mail server administrators to use SSL/TLS with

Perfect Forward Secrecy here in Germany since 2014 (see

http://www.heise.de/security/meldung/Datenschuetzer-mahnen-Mail-Server-Betreiber-wegen-fehlender-Verschluesselung-2390692.html).

They are authorized to execute it by law and the are doing so already.

We had to do a mayor OS-Upgrade because of them and right now we are

stuck with the mailing issue. We are still evaluating Mercury 4.8 and

before we buy the license we need to know if Perfect Forward Secrecy is

planned in Mercury, and if so, we would need estimated time of

implementation.

A possiblity would be to add an input-text-field

cipherlist that could override default openSSLs ciphers for incoming

SMTP and SMTP-Client . That would also allow administrators to change

cipherlists, just in case ciphers get deprecated or flawed. 

We

need an answer soon because evaluating time of mercury license is

ending soon, and the Data Protection Authority gave is time until end of

June 2016 to answer. 

We would appreciate your help a lot.

Thanks

I have been working on this recently, in fact. Supporting forward secrecy requires some extra initialization steps in OpenSSL that are not particularly well-documented, but I believe I have completed them (in particular, you have to pre-initialize the Diffie-Hellman library with code for generating ephemeral keys, and perform some elliptic curve setup). The biggest problem I have is performing any kind of meaningful testing, because in my experience, so few clients currently support forward secrecy.

The real issue you may have to deal with here is in determining what the German authority actually expects you to do: forward secrecy is a choice done at negotiation time in TLS, and both parties have to agree to it: unless you cripple your implementation badly by limiting it to use ONLY the cipher suites that support forward secrecy, it is always going to be possible for the client and the server to negotiate a cipher suite that does not support it.

Mercury has specifically supported only strong cipher suites since I moved it to OpenSSL, but it *is* possible to specify the specific cipher suites you want it to use via an initialization file, although this ability is not currently documented.

If anyone can provide completely reliable forward secrecy testing, I'd appreciate them getting in touch with me - I'm willing to make pre-release versions of Mercury with this support added available to them for validation. Please contact me at my normal e-mail address, David.Harris@pmail.gen.nz, if you can assist with this.

-- David --