[exim-dev] [Bug 2872] Unable to select ONLY TLSv1.3 CHACHA20-POLY1305 cipher
https://bugs.exim.org/show_bug.cgi?id=2872 --- Comment #11 from help@novo.media --- There is a fundamental philosophical difference between my understanding and the developers, in that, Exim tries to be consistent/compatible over different libraries, TLS versions, connection directions and settings. An attempt I consider futile. Nonetheless, my proposals were always listened to with an open mind, exemplary professionalism and formidable endurance. For that, I kindly thank everyone participating. I now proceed with disabling all my TLS settings in each daemon/config and set the appropriate configurations globally within openssl.cnf. This solution is somewhat limiting in regards to outgoing connections, but it is also nice to have all TLS settings within one file! Thanks again. -- 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 #10 from Jeremy Harris --- (In reply to help from comment #8) > > 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. > > With a single configuration? Yes. With a single configuration, no. It doesn't work (in a reasonable way). > Once a TLS 1.3 session is negotiated, there is no possibility for it to > become a TLS 1.2 session anymore. For good reasons! (Security) Misconception. A 1.3 connection is not negotiated, with the attempted matching of 1.3 configurations, even though there is a matching 1.2 cipher available. No TLS connection is successfully made. The server refuses the TLS connection. Result, for SMTP: either a) (when one end insists on TLS or nothing) no SMTP communication OR b) SMTP standard downgrade to in-clear communications. It's not a good situation. And making the facility in Exim config to restrict the 1.3 ciphersuites makes the occurrence of the problem combination more likely - because administrators of systems will make different choices - which will mean more support queries, and perception of Exim being unreliable. For what it's worth, OpenSSL and GnuTLS do the same here. -- 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 #9 from help@novo.media --- And apart from all of this, how does the (in)ability of a user to the define custom ciphersuites address any of the issues raised by you? Exim/TLS behaves still the same even if a user can not define custom ciphersuites. I am kind of baffled. What exactly is the issue here at all? -- 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 #8 from help@novo.media --- (In reply to Jeremy Harris from comment #7) > (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. I'd call that a selection rather than a downgrade. A downgrade would constitute the start of a TLS session in a certain version and the ending of that session with a different, lower version. But actually it does not matter how we call it. For the sake of the argument, it doesn't change anything. > 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. With a single configuration? Yes. Within a single connection/session? No. And that's a good thing. > 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. Once a TLS 1.3 session is negotiated, there is no possibility for it to become a TLS 1.2 session anymore. For good reasons! (Security) I do not understand where or what the opposition here exactly is. Nobody would expect a TLS 1.2 session to be downgraded to TLS 1.1 on a cipher-mismatch, so why the different standard for TLS 1.3 here? -- 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 #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 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 2872] Unable to select ONLY TLSv1.3 CHACHA20-POLY1305 cipher
https://bugs.exim.org/show_bug.cgi?id=2872 Jeremy Harris changed: What|Removed |Added Assignee|unalloca...@exim.org|jgh146...@wizmail.org Status|NEW |ASSIGNED -- 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 help@novo.media changed: What|Removed |Added CC||help@novo.media --- Comment #3 from help@novo.media --- Although I agree this is not a bug but a wishlist item, I also want to join this request. For me, it is the fact that I only want to enable 256bit encryption throughout my server - which with exim and TLSv1.3 enabled - I am currently unable to do so. Considering that TLSv1.3 is the future and here to stay (and a developer would consider an implementation) I kindly suggest the double settings route (like OpenSSL itself and every other major daemon by now) in form of cipher list and suites: dovecot example: ssl = yes ssl_cert = "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305", "Ciphersuites" => "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256", "Curves" => "secp384r1" ) } exim currently: tls_on_connect_ports = 465 tls_certificate = /srv/tls/full_chain tls_privatekey = /srv/tls/private_key tls_require_ciphers = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305 tls_eccurve = secp384r1 Possible exim implementation suggestion: +tls_require_suites = ... and +dane_require_tls_suites = ... Sadly I do not speak C, else I would gladly contribute. So all I am left with, is hoping that a developer might consider it. Thanks very much. -- 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 Jeremy Harris changed: What|Removed |Added Assignee|jgh146...@wizmail.org |unalloca...@exim.org Severity|bug |wishlist Priority|medium |low --- Comment #1 from Jeremy Harris --- The documentation says what it does for TLS1.3. Assuming that is what you are using (you didn't say), there is no way to force the use of that one cipher. At best this is a wishlist item, not a bug. -- 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/ ##