On 14. mája 2025 11:29:08 UTC, Cyborg via Exim-users <exim-users@lists.exim.org> wrote:
>Means, when such an exchange wants a tls connection, it starts with the >weakest instead of the strongest chiper ending up with a SSLv3 connection. >That is nowadays not allowed anymore on linux systems, which means that this >example will most likely fail. luckily. That is not as TLS is supposed to work. The RFC (at least for TLS 1.2) says that client should send its highest supported TLS version and then server sends selected TLS version, that is what is lower, the client's version or highest server's version. If server choose something other, it doesn't supports TLS, but something strange. The client sends its ordered list of supported/preffered cipher suites. Server choose one of it, AFAIK RFC doesn't mandate how to choose it. OpenSSL eg. will select first common from client's list by default, or it can be configured to choose first common from server's ordered list. Another crypto libraries can use different way, thus yes, they can choose the weakest one, but i am not aware any (well known) of that. Despite of order, there is no way to change TLS version from cipher(suites) selection, as it is selected independly. If client doesn't ask SSL3 exactly and SSL3 is not server's highest version, there is no way how to negotiate it, if your crypto does it properly. And i believe, that if that will happen in OpenSSL/GnuTLS, the experts will complain loudly. I feel common mistake of "crypto experts" here, if selected cipher suite mentions SSL3 in openssl's cipher output, it means that that suite was introduced in SSL3, it has nothing to do with used TLS version. regards -- Slavko https://www.slavino.sk/ -- ## subscription configuration (requires account): ## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/ ## unsubscribe (doesn't require an account): ## exim-users-unsubscr...@lists.exim.org ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
