Ticket Change Details

Artifact ID: b5a633ec899a6e5df11388cb995fb02a3461cb6bef767259ebfbeaaf778a4ba1
Ticket: d0518a5645151339f345c259e25b512c2bf3d63f
tls::socket -cipher arg not working as expected when -tls1.3 is true
User & Date: anonymous 2019-04-15 21:26:20

  1. Change foundin to "1.7.17"
  2. Change icomment to:

    The "-cipher" switch in the tls::socket command should allow an explicit cipher to use for a session. It does not do this when the tls1.3 switch is set to true.

    Openssl version is 1.1.1b tcltls version 1.7.17

    When the socket is set up in the following fashion it functions correctly allowing the passed cipher to be used explicitly.

    Examples of individually passed ciphers include:

    DHE-RSA-AES256-GCM-SHA384 DHE-RSA-AES256-SHA256 AES256-GCM-SHA384 AES256-SHA256 DHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES128-SHA256 AES128-GCM-SHA256 AES128-SHA256 ...... and so on

    set server_channel [tls::socket \ -tls1.3 0 \ -tls1.2 1 -tls1 0 \ -tls1.1 0 \ -ssl2 0 \ -ssl3 0 \ -server EchoAccept \ -request 1 \ -require 1 \ -cafile $CA_CERTIFICATE \ -certfile $CERTFILE \ -keyfile $PRIVATE_KEY \ -password get_master_password \ -cipher $ENCRYPTION_CIPHER \ $LISTEN_SOCKET ]

    A similar setup is in place for the client.

    When the tls1.3 switch is set to true, the ability to individually select the explicit cipher goes away. In my setup, it always defaults to TLS_AES_256_GCM_SHA384.

    When tls1.2 is true and tls1.3 is false is works as expected. When tls1.3 is true, it does not function as expected (regarless of how tls1.2 is set).

    Correct and corresponding setup was done on the client side when investigated.

  3. Change login to "anonymous"
  4. Change mimetype to "text/x-fossil-plain"
  5. Change private_contact to "07dea8439aa410135bf1d5b46943118fd70e6703"
  6. Change severity to "Critical"
  7. Change status to "Open"
  8. Change title to:

    tls::socket -cipher arg not working as expected when -tls1.3 is true

  9. Change type to "Code Defect"