On 22 February 2018 at 17:00, Stefano Bagnara <mai...@bago.org> wrote: > We ignore certificate issues and lowered the cypher requirements as > much as possible. > We settled to 0.01% failures converting the socket to TLS: most common > domains involved in the failure are uni-kl.de and univie.ac.at
Just an update because Univie postmaster kindly contacted me offlist and we analyzed the issue. Turned out my MTA did not support EC* ciphers so when contacting uni-kl or univie servers the TLS handshake chose (server chosen) a DHE_ cipher. The issue is that both serve use a DH key length that is not "multiple of 64" (1453bits the uni-kl, 2236bits the univie) and Java fails with this error "DH key size must be multiple of 64, and can only range from 512 to 8192 (inclusive). The specific key size 2236 is not supported". I'm not a cripto expert so I don't know if this "multiple-of-64" constraint from Java is a java limit or a cipher specification. Now, enabling the ECDHE_ ciphers on my side worked around the issue. It seems the DHE_ cipher have a "limit" because when 2 parties choose to use it they don't know yet if they will be able to complete the handshake, while EC* expose the supported curves in the choice phase so you better know the handshake will work if you agree on that cipher. I found this article: https://groups.google.com/a/chromium.org/forum/m/#!topic/blink-dev/AAdv838-koo/discussion I found many receivers (microsoft, gmail, yahoo) only expose ECDHE_* and not DHE_* ciphers maybe because of this issue. Even if enabling ECDHE seems to have fixed most of the remaining issues, I'm evaluating removing DHE_* ciphers on my client side to avoid further issues similar to this. I found https://github.com/mozilla/cipherscan useful, while debugging the issue. Hope this helps, Stefano _______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
