[exim-dev] [Bug 2872] Unable to select ONLY TLSv1.3 CHACHA20-POLY1305 cipher
https://bugs.exim.org/show_bug.cgi?id=2872 --- Comment #6 from help@novo.media --- One has to think of TLS 1.3 as a completely new protocol. Apart from its name, it has nothing in common with TLS 1.2 anymore. Not only are the cipher names completely new, but also the entire handshake structure of TLS 1.3 is faster. At its conception, there were even discussions if it should be named TLS 2.0 instead of TLS 1.3 because the changes were so fundamental. In terms of ciphers, there are only generic names available anymore with a general description of what algorithm and its hashing strength. Gone are the days, where one has to define the type of DH exchange (DH, DHE or ECDHE) or type of certificate (DSA, RSA or ECDSA) within a cipher but instead one 'generic name' per cipher is defined and the library - in this case OpenSSL - handles the rest. There can't be any version downgrade-ability, simply because the information in a 'generic TLS 1.3 ciphersuite name' does not contain the information needed for a specific TLS 1.2 cipher. There is no such thing as "the same cipher" for TLS 1.2 and 1.3 or vice versa. And that is just on the cipher side. The handshake is different too, which makes the prospect a complete interchangeability even "more impossible". TLS 1.3 has 'nothing' to do with TLS 1.2 anymore. They are like siblings but from different parents, so to speak. A simple but great rule to help throughout this confusion is the question: Would this kind of outcome considered to be good/right/expected, if TLS 1.3 is the only version (ever) existing. If the answer is yes, then everything works as expected. Even if TLS 1.2 is around or beside. In case of the TLS 1.3 issue mentioned before: Would a TLS 1.3 connection termination because of a cipher-mismatch considered to be good/right/expected, if TLS 1.3 is the only version (ever) existing? Yes, absolutely. Therefore everything works as expected. TLS 1.2 has absolutely nothing to do with this anymore. I hope this could clear up some misconceptions. -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[exim-dev] [Bug 2872] Unable to select ONLY TLSv1.3 CHACHA20-POLY1305 cipher
https://bugs.exim.org/show_bug.cgi?id=2872 --- Comment #7 from Jeremy Harris --- (In reply to help from comment #6) > There can't be any version downgrade-ability I disagree. If you configure the sever for no-1.3 and hit it with an OpenSSL-default 1.3 + 1.2, you get a 1.2 connection. I call that a working downgrade, from the point-of-view of the client. -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[exim-dev] [Bug 2872] Unable to select ONLY TLSv1.3 CHACHA20-POLY1305 cipher
https://bugs.exim.org/show_bug.cgi?id=2872 --- Comment #4 from Jeremy Harris --- OpenSSL has separate API calls for TLSv1.3 and pre-1.3 ciphersuites. If you don't call either, you get a default set for that version of TLS. I'd expect it to, if a (set of) 1.3 ciphers was requested which did not match those selected by a peer, to fall back to using a cipher from the pre-1.3 set, on a 1.2 connection (assuming there was one). But it does not; the server rejects the Client Hello with a "Handshake faiied" alert. This is less than useful, it means a server cannot restrict the 1.3 ciphers it offers yet still offer both 1.3 and 1.2 service with a single configuration. -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[exim-dev] [Bug 2434] information about time from start of smtp connection exists only for some log messages
https://bugs.exim.org/show_bug.cgi?id=2434 Jeremy Harris changed: What|Removed |Added Status|ASSIGNED|WAIT_FIX_CONFIRMATION --- Comment #4 from Jeremy Harris --- aae673d7db4b addresses. -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[exim-dev] [Bug 2872] Unable to select ONLY TLSv1.3 CHACHA20-POLY1305 cipher
https://bugs.exim.org/show_bug.cgi?id=2872 --- Comment #5 from help@novo.media --- I think there is a misconception about OpenSSL/TLS 1.3 here. It is true, that - if a cipher-mismatch occurs - the connection gets rejected. But this is also true if the default ciphersuites are used. The RFC makes five ciphersuites in TLS 1.3 mandatory. All of them are supported by OpenSSL: TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 TLS_AES_128_CCM_8_SHA256 TLS_AES_128_CCM_SHA256 OpenSSL however is offering only the first three(*) as the default for TLS 1.3 connections: TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 So if we were to use one of the non-default ciphersuites of TLS_AES_128_CCM_8_SHA256 TLS_AES_128_CCM_SHA256 we are getting the exact same error+disconnect. And this is the current state of all Exim builds with OpenSSL and enabled TLS 1.3 in use right now: openssl s_client -ciphersuites TLS_AES_128_CCM_8_SHA256 -connect novo.media:465 CONNECTED(0003) 139795264054592:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../ssl/record/rec_layer_s3.c:1543:SSL alert number 40 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 298 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- echo $? 1 I do not see how allowing users to define their own set of custom ciphersuites would change anything in that regard. One is already able to produce a cipher-mismatch with a disconnect, even without the ability to define custom ciphersuites. In general; I do not understand where that misconception for version interoperability comes from. TLS 1.3 is built with a certain backwards compatibility in mind, in the sense that a only-TLS-1.2-speaking-server is able to handle a TLS-1.3-request-from-a-client without breakage. That does not imply a servers ability to switch protocol versions arbitrarily. Especially not on a cipher-mismatch and super-especially not with a version downgrade in response. Apart from its technical impracticality - due to the different handshake architecture - this would also have security implications on its own. In the HTTP world, virtually every daemon like Apache, NGINX or lighttpd is supporting custom ciphersuites. The same is true for the most popular IMAP daemon dovecot. And in SMTP terms (may absolution is granted by you, father) even Postfix. All of them are using OpenSSL. (*) https://wiki.openssl.org/index.php/TLS1.3#Ciphersuites -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[exim-dev] [Bug 2946] make max_rcpt expandable
https://bugs.exim.org/show_bug.cgi?id=2946 Jeremy Harris changed: What|Removed |Added Resolution|--- |FIXED Status|WAIT_FIX_CONFIRMATION |RESOLVED --- Comment #4 from Jeremy Harris --- Nobody commented -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##