Ticket Change Details

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

  1. foundin changed to: "1.7.17"
  2. icomment:
    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:
    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 \
    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. login: "anonymous"
  4. mimetype: "text/x-fossil-plain"
  5. private_contact changed to: "07dea8439aa410135bf1d5b46943118fd70e6703"
  6. severity changed to: "Critical"
  7. status changed to: "Open"
  8. title changed to:
    tls::socket -cipher arg not working as expected when -tls1.3 is true
  9. type changed to: "Code Defect"