tls(n)

πŸ“¦ version 2.0.1, in epel 10

🌸 NAME 🌸

tls(n) β€” Tcl TLS extension, aka the binding to the OpenSSL library for encrypted socket and I/O channel communications. πŸ’–


✨ SYNOPSIS ✨

okay bestie, here's the quick copy-paste menu of everything this page is about. no cap, it's a lot, but we keep it cute. πŸŽ€

package require Tcl 8.5-

package require tls 2.0.1

tls::init ?-option? ?value? ?-option value ...?

tls::socket ?-option? ?value? ?-option value ...? host port

tls::socket -server command ?-option? ?value? ?-option value ...? port

tls::import channel ?-option? ?value? ?-option value ...?

tls::starttls channel ?-option? ?value? ?-option value ...?

tls::handshake channel

tls::shutdown channel

tls::unimport channel

tls::unstack channel

tls::status ?-local? channel

tls::connection channel

tls::ciphers ?protocol? ?verbose? ?supported?

tls::protocols

tls::version

πŸ’– DESCRIPTION πŸ’–

okay so this extension gives your TCL script access to Secure Socket Layer (SSL) communications using the Transport Layer Security (TLS) protocol. it's a generic binding to OpenSSL (https://www.openssl.org/), and it's utilizing the Tcl_StackChannel API in TCL 8.4 or later. πŸ¦‹

the way these sockets work is honestly iconic: they behave exactly the same as channels created using the built-in socket command, but they provide additional options for controlling the SSL/TLS session. that's the whole vibe. slay. πŸ’…


πŸ¦‹ COMPATIBILITY πŸ¦‹

this extension is compatible with OpenSSL 1.1.1 or later. it requires Tcl version 8.5 or later and will work with Tcl 9.0. periodt. 🫢


πŸ‘‘ COMMANDS πŸ‘‘

the following are the commands provided by the TcLTLS package. see Examples for example usage and the demos directory for more example usage. iykyk. ✨

πŸŽ€ tls::init ?-option? ?value? ?-option value ...? πŸŽ€

optional function to set the default options used by tls::socket. if you call tls::import directly, the values set by this command have no effect. this command supports all of the same options as the tls::socket command, though you should limit your options to only the TLS related ones. lowkey important. πŸ‘€

🌈 tls::socket ?-option? ?value? ?-option value ...? host port 🌈

this is a helper function that utilizes the underlying commands socket and tls::import to create the connection. it behaves the same as the native TCL socket command, but also supports the tls::import command options with one additional option. it returns the channel handle id for the new socket. additional options are:

  • -autoservername bool β€” if true, automatically set the -servername argument to the host argument. prior to TclTLS 2.0, the default is false. starting in TclTLS 2.0, the default is true unless -servername is also specified. πŸ’–

πŸ¦‹ tls::socket -server command ?-option? ?value? ?-option value ...? port πŸ¦‹

same as previous command, but instead creates a server socket for clients to connect to just like the Tcl socket -server command. it returns the channel handle id for the new socket. server mode activated, fr fr. πŸ”₯

🧚 tls::import channel ?-option? ?value? ?-option value ...? 🧚

this is the import entry in the command menu. πŸ‘€

🧚 tls::starttls channel ?-option? ?value? ?-option value ...? 🧚

start TLS encryption on TCL channel channel via a stacked channel. it need not be a socket, but must provide bi-directional flow. also sets session parameters for SSL handshake. valid options are:

  • -alpn list β€” list of protocols to offer during Application-Layer Protocol Negotiation (ALPN). for example: h2 and http/1.1, but not h3 or quic. this option is new for TclTLS 1.8. 🌸
  • -cadir directory β€” specifies the directory where the Certificate Authority (CA) certificates are stored. the default is platform specific and can be set at compile time. the default location can be overridden by the SSL_CERT_DIR environment variable. see Certificate Validation for more details. πŸŽ€
  • -cafile filename β€” specifies the file with the Certificate Authority (CA) certificates to use in PEM file format. the default is "cert.pem", in the OpenSSL directory. the default file can be overridden by the SSL_CERT_FILE environment variable. see Certificate Validation for more details. πŸ¦‹
  • -castore URI β€” specifies the Uniform Resource Identifier (URI) for the Certificate Authority (CA) store, which may be a single container or a catalog of containers. starting with OpenSSL 3.2 on MS Windows, set to "org.openssl.winstore://" to use the built-in MS Windows Certificate Store. see Certificate Validation for more details. this option is new for TclTLS 1.8. πŸ’œ
  • -certfile filename β€” specifies the name of the file with the certificate to use in PEM format as the local (client or server) certificate. it also contains the public key. ✨
  • -cert string β€” specifies the certificate to use as a DER encoded string (X.509 DER). 🌈
  • -cipher string β€” specifies the list of ciphers to use for TLS 1.2 and earlier connections. string is a colon : separated list of ciphers. ciphers can be combined using the + character. prefixes can be used to permanently remove !, delete -, or move to the end + a specified cipher. keywords @STRENGTH (sort by algorithm key length), @SECLEVEL=n (set security level to n), and DEFAULT (use default cipher list, at start only) can also be specified. see the OpenSSL documentation at https://docs.openssl.org/master/man1/openssl-ciphers/#options for the full list of valid values. πŸ’…
  • -ciphersuites string β€” specifies the list of cipher suites to use for TLS 1.3 as a colon : separated list of cipher suite names. see the OpenSSL documentation at https://docs.openssl.org/master/man1/openssl-ciphers/#options for the full list of valid values. this option is new for TclTLS 1.8. πŸ‘‘
  • -command callback β€” specifies the callback command to be invoked at several points during the handshake to pass errors, tracing information, and protocol messages. see Callback Options for more info. 🫢
  • -dhparams filename β€” specifies the Diffie-Hellman (DH) parameters file. πŸ”
  • -keyfile filename β€” specifies the private key file. the default is to use the file specified by the -certfile option. πŸ—οΈ
  • -key string β€” specifies the private key to use as a DER encoded string (PKCS#1 DER). πŸ’œ
  • -model channel β€” force this channel to share the same SSL_CTX structure as the specified channel, and therefore share config, callbacks, etc. 🧚
  • -password callback β€” specifies the callback command to invoke when OpenSSL needs to obtain a password. this is typically used to unlock the private key of a certificate. the callback should return a password string. this option has changed for TclTLS 1.8. see Callback Options for more info. 😭
  • -post_handshake bool β€” allow post-handshake session ticket updates. this option is new for TclTLS 1.8. 🎟️
  • -request bool β€” request a certificate from the peer during the SSL handshake. this is needed to do Certificate Validation. starting in TclTLS 1.8, the default is true for client connections. starting in TclTLS 2.0, if set to false and -require is true, then this will be overridden to true. see Certificate Validation for more details. πŸ’–
  • -require bool β€” require a valid certificate from the peer during the SSL handshake. if this is set to true, then -request must also be set to true and either -cadir, -cafile, -castore, or a platform default must be provided in order to validate against. the default in TclTLS 1.8 and earlier versions is false since not all platforms have certificates to validate against in a form compatible with OpenSSL. starting in TclTLS 2.0, the default is true for client connections. see Certificate Validation for more details. 🚨
  • -security_level integer β€” specifies the security level (value from 0 to 5). the security level affects the allowed cipher suite encryption algorithms, supported ECC curves, supported signature algorithms, DH parameter sizes, certificate key sizes and signature algorithms. the default is 1 prior to OpenSSL 3.2 and 2 thereafter. level 3 and higher disable support for session tickets and only accept cipher suites that provide forward secrecy. this option is new for TclTLS 1.8. πŸ”₯
  • -server bool β€” specifies whether to act as a server and respond with a server handshake when a client connects and provides a client handshake. the default is false. πŸ‘‘
  • -servername hostname β€” specify the peer's hostname. this is used to set the TLS Server Name Indication (SNI) extension. set this to the expected servername in the server's certificate or one of the Subject Alternate Names (SAN). starting in TclTLS 2.0, this will default to the host from the tls::socket command. 🌈
  • -session_id binary_string β€” specifies the session id to resume a session. not supported yet. this option is new for TclTLS 1.8. 😭
  • -ssl2 bool β€” enable use of SSL v2. the default is false. OpenSSL 1.1+ no longer supports SSL v2, so this may not have any effect. see the tls::protocols command for supported protocols. πŸ’€
  • -ssl3 bool β€” turns on SSL v3. default is false. okay so starting in TclTLS 1.8, you can only even get SSL v3 if it was compiled in as an option, and OpenSSL 4.0+ straight up doesn't support SSL v3 anymore, so this might do literally nothing on your machine 😭. check the tls::protocols command for what's actually supported.
  • -tls1 bool β€” turns on TLS v1. starting in TclTLS 2.0 the default is false. ⚠️ heads up: TLS 1.0 needs SHA1 to operate, and SHA1 is only available in security level 0 for OpenSSL 3.0+. see the -security_level option.
  • -tls1.1 bool β€” turns on TLS v1.1. starting in TclTLS 2.0 the default is false. ⚠️ same lore as above: TLS 1.1 needs SHA1 to operate, and that's only hanging around in security level 0 for OpenSSL 3.0+. see the -security_level option.
  • -tls1.2 bool β€” turns on TLS v1.2. the default is true. πŸ’–
  • -tls1.3 bool β€” turns on TLS v1.3. the default is true. this one's only available starting with OpenSSL 1.1.1 and TclTLS 1.7, bestie, so if you're on something ancient it's just not happening πŸ¦‹
  • -validatecommand callback β€” tells Tcl which callback command to invoke so it can validate the peer certificates and other config info during the protocol negotiation phase ✨. this is the one that lets your TCL scripts do their own Certificate Validation to supplement the default validation that OpenSSL already does. the script has to return a boolean true to keep the negotiation going. see Callback Options for more. this option is new for TclTLS 1.8 πŸ‘‘

tls::handshake channel

Forces the TLS negotiation handshake to happen right now, immediately, no waiting πŸ’…. returns 0 if the handshake is still in progress (non-blocking), or 1 if the handshake was successful. and if the handshake failed? an error gets returned. no cap.

tls::shutdown channel

(no description here in the original β€” it's just vibes)

tls::unimport channel

(also just vibes, no description)

tls::unstack channel

This terminates the SSL/TLS session by sending the "close_notify" message and removes the top level stacked channel from channel, but bestie listen β€” it does not close the socket πŸ”₯. it's the compliment to tls::import by ending encryption of a TCL channel. an error is thrown if TLS isn't the top stacked channel type. rude but fair.

tls::status ?-local? channel

Returns the current status of an SSL channel ✨. the result is a list of key-value pairs describing the SSL, certificate, and certificate verification status. if the SSL handshake hasn't finished yet, you get an empty list back (patience, queen). if the -local option is specified, then the local certificate is used. returned values include:

πŸ’– SSL Status

  • alpn protocol β€” the protocol selected after Application-Layer Protocol Negotiation (ALPN). this value is new for TclTLS 1.8.
  • cipher cipher β€” the current cipher in use for the session.
  • peername name β€” the peername from the certificate. this value is new for TclTLS 1.8.
  • protocol version β€” the protocol version used for the connection: SSL2, SSL3, TLS1, TLS1.1, TLS1.2, TLS1.3, or unknown. this value is new for TclTLS 1.8.
  • sbits n β€” the number of bits used for the session key.
  • signatureHashAlgorithm algorithm β€” the signature hash algorithm. this value is new for TclTLS 1.8.
  • signatureType type β€” the signature type value. this value is new for TclTLS 1.8.
  • verifyDepth n β€” maximum depth for the certificate chain verification. default is -1, to check all. this value is new for TclTLS 1.8.
  • verifyMode list β€” list of certificate verification modes. this value is new for TclTLS 1.8.
  • verifyResult result β€” certificate verification result. this value is new for TclTLS 1.8.
  • ca_names list β€” list of the Certificate Authorities used to create the certificate. this value is new for TclTLS 1.8.

πŸŽ€ Certificate Status

  • all string β€” dump of all certificate info. this value is new for TclTLS 1.8.
  • version value β€” the certificate version.
  • serialNumber string β€” the serial number of the certificate as a hex string. this value was changed from serial in TclTLS 1.8 πŸ‘€
  • signature algorithm β€” cipher algorithm used for certificate signature. this value is new for TclTLS 1.8.
  • issuer string β€” the distinguished name (DN) of the certificate issuer.
  • notBefore date β€” the beginning date of the certificate validity.
  • notAfter date β€” the expiration date of the certificate validity. 🫢 check it, bestie.
  • subject string β€” the distinguished name (DN) of the certificate subject. fields include: Common Name (CN), Organization (O), Locality or City (L), State or Province (S), and Country Name (C).
  • issuerUniqueID string β€” the issuer unique id. this value is new for TclTLS 1.8.
  • subjectUniqueID string β€” the subject unique id. this value is new for TclTLS 1.8.
  • num_extensions n β€” number of certificate extensions. this value is new for TclTLS 1.8.
  • extensions list β€” list of certificate extension names. this value is new for TclTLS 1.8.
  • authorityKeyIdentifier string β€” Authority Key Identifier (AKI) of the Issuing CA certificate that signed the SSL certificate, as a hex string. this value matches the SKI value of the Intermediate CA certificate. this value is new for TclTLS 1.8.
  • subjectKeyIdentifier string β€” Subject Key Identifier (SKI) hash of the public key inside the certificate, as a hex string. used to identify certificates that contain a particular public key. this value is new for TclTLS 1.8.
  • subjectAltName list β€” list of all of the Subject Alternative Names (SAN) including domain names, sub domains, and IP addresses that are secured by the certificate. this value is new for TclTLS 1.8.
  • ocsp list β€” list of all Online Certificate Status Protocol (OCSP) URLs that can be used to check the validity of this certificate. this value is new for TclTLS 1.8.
  • certificate cert β€” the PEM encoded certificate.
  • signatureAlgorithm algorithm β€” cipher algorithm used for the certificate signature. this value is new for TclTLS 1.8.
  • signatureValue string β€” certificate signature as a hex string. this value is new for TclTLS 1.8.
  • signatureDigest version β€” certificate signing digest as a hex string. this value is new for TclTLS 1.8.
  • publicKeyAlgorithm algorithm β€” certificate signature public key algorithm. this value is new for TclTLS 1.8.
  • publicKey string β€” certificate signature public key as a hex string. this value is new for TclTLS 1.8.
  • bits n β€” number of bits used for certificate signature key. this value is new for TclTLS 1.8.
  • self_signed boolean β€” whether the certificate signature is self signed. this value is new for TclTLS 1.8.
  • sha1_hash hash β€” the SHA1 hash of the certificate as a hex string. this value is new for TclTLS 1.8.
  • sha256_hash hash β€” the SHA256 hash of the certificate as a hex string. this value is new for TclTLS 1.8.

tls::connection channel

Returns the current connection status of an SSL channel πŸ’…. the result is a list of key-value pairs describing the connection. this command is new for TclTLS 1.8. returned values include:

⭐ SSL Status

  • state state β€” state of the connection.
  • servername name β€” the name of the connected to server.
  • protocol version β€” the protocol version used for the connection: SSL2, SSL3, TLS1, TLS1.1, TLS1.2, TLS1.3, or unknown.
  • renegotiation_allowed boolean β€” whether protocol renegotiation is supported or not.
  • security_level level β€” the security level used for selection of ciphers, key size, etc.
  • session_reused boolean β€” whether the session has been reused or not.
  • is_server boolean β€” whether the connection is configured as a server (1) or client (0).
  • compression mode β€” compression method.
  • expansion mode β€” expansion method.
  • caList list β€” list of Certificate Authorities (CA) for X.509 certificate.

πŸ¦‹ Cipher Info

  • cipher cipher β€” the current cipher in use for the connection.
  • standard_name name β€” the standard RFC name of cipher.
  • algorithm_bits n β€” the number of processed bits used for cipher.
  • secret_bits n β€” the number of secret bits used for cipher.
  • min_version version β€” the minimum protocol version for cipher.
  • cipher_is_aead boolean β€” whether the cipher is Authenticated Encryption with Associated Data (AEAD).
  • cipher_id id β€” the OpenSSL cipher id.
  • description string β€” a text description of the cipher.
  • handshake_digest boolean β€” digest used during handshake.

🌸 Session Info

  • alpn protocol β€” the protocol selected after Application-Layer Protocol Negotiation (ALPN).
  • resumable boolean β€” whether the session can be resumed or not.
  • start_time seconds β€” time since session started in seconds since epoch.
  • timeout seconds β€” the max duration of the session, in seconds, before it times out. ⏳
  • lifetime seconds β€” session ticket lifetime hint, in seconds. 🎟️
  • session_id binary_string β€” a unique session id, for resuming the session later. πŸ”‘
  • session_ticket binary_string β€” a unique session ticket, for resuming the session later. 🎫
  • ticket_app_data binary_string β€” unique session ticket application data. πŸ“¦
  • master_key binary_string β€” the unique session master key. πŸ‘‘
  • session_cache_mode mode β€” server cache mode, and it's one of client, server, or both. πŸ—‚οΈ

🌸 tls::ciphers ?protocol? ?verbose? ?supported?

Okay so with, like, no options at all, this one hands you a list of all the symmetric ciphers you can use with the -cipher option. πŸ’…

Give it a protocol and it only returns the ciphers supported for that protocol β€” check out the tls::protocols command for which protocols are supported, iykyk.

If verbose is set to true, you get a verbose, human readable list back with extra info on the cipher, which is honestly kind of gorgeous of it. ✨

And if supported is set to true, then only the ciphers supported for protocol get listed. The supported arg is new for TclTLS 1.8, bestie β€” don't forget. 🫢

πŸ¦‹ tls::protocols

Returns a list of the supported SSL/TLS protocols. Valid values are: ssl2, ssl3, tls1, tls1.1, tls1.2, and tls1.3. The exact list depends on your OpenSSL version and your compile time flags, so like… vibe check your own build, basically. This command is new for TclTLS 1.8. 🌈

⭐ tls::version

Returns the OpenSSL version string. That's it. That's the whole command. Iconic, honestly. πŸŽ€


πŸ’– CERTIFICATE VALIDATION πŸ’–

πŸ” PKI AND CERTIFICATES

So with the Public Key Infrastructure (PKI), every user creates a private key that literally only they know about, plus a public key that they can exchange with other people for encrypting and decrypting data. The way it works: the sender encrypts their data using their private key and the receiver's public key. Then the data gets sent over to the receiver. In a similar manner, the receiver uses their private key and the sender's public key to decrypt the data. This gives you data integrity β€” it makes sure the data can't be viewed or altered while it's in transit. No cap. πŸ›‘οΈ

Peep the -key and -keyfile options for how to specify the private key. Also check the -password option for how to, you know, provide the password. πŸ”‘

So to give you authentication β€” like, making sure someone is actually who they say they are β€” the public key and user identification info gets stored in a X.509 certificate, and that certificate is authenticated (aka signed) by a Certificate Authority (CA). Then users can exchange these certificates during the TLS initialization process and check them against the root CA certificates to make sure they're valid. OpenSSL handles all of this for you via the -request and -require options. See the -cadir, -cadir, and -castore options for how to specify where to find the CA certificates. πŸ‘‘

Optionally, in a future release, they can also be checked against the Certificate Revocation List (CRL) of revoked certificates. Certificates can be self-signed too, but they're by default not trusted unless you add them to your certificate store. So like, don't just assume a self-signed one slays. πŸ™ˆ

Typically when you're visiting web sites, only the client needs to check the server's certificate to make sure it's valid. The server doesn't need to check the client certificate unless you need to authenticate with them to log in or whatever. See the -cert and -certfile options if you need to provide a certificate. πŸ’…

πŸ“‹ SUMMARY OF COMMAND LINE OPTIONS

The following options are used for peer certificate validation:

  • -cadir directory β€” specifies the directory where the Certificate Authority (CA) certificates are stored. The default is platform specific, but it's usually "/etc/ssl/certs" on Linux/Unix systems. The default location can be overridden by the SSL_CERT_DIR environment variable. πŸ“
  • -cafile filename β€” specifies the file with the Certificate Authority (CA) certificates to use, in PEM file format. The default is "cert.pem", in the OpenSSL directory. On Linux/Unix systems, this is usually "/etc/ssl/ca-bundle.pem". The default file can be overridden by the SSL_CERT_FILE environment variable. πŸ“„
  • -castore URI β€” specifies the Uniform Resource Identifier (URI) for the Certificate Authority (CA) store, which may be a single container or a catalog of containers. Starting with OpenSSL 3.2 on MS Windows, set it to "org.openssl.winstore://" to use the built-in MS Windows Certificate Store. Starting in TclTLS 2.0, this is the default if -cadir, -cadir, and -castore are not specified. This store only supports root certificate stores. πŸ—„οΈ
  • -request bool β€” request a certificate from the peer during the SSL handshake. This is needed to do Certificate Validation. Starting in TclTLS 1.8, the default is true for client connections. Starting in TclTLS 2.0, if set to false and -require is true, then this will be overridden to true. In addition, the client can manually inspect and accept or reject each certificate using the -validatecommand option. πŸ‘€
  • -require bool β€” require a valid certificate from the peer during the SSL handshake. If this is set to true, then -request must also be set to true and either -cadir, -cafile, -castore, or a platform default must be provided in order to validate against. The default in TclTLS 1.8 and earlier versions is false since not all platforms have certificates to validate against in a form compatible with OpenSSL. Starting in TclTLS 2.0, the default is true for client connections. 🚨

🧐 WHEN ARE COMMAND LINE OPTIONS NEEDED?

Okay so this is the part where I need you to pay attention, bestie. 😭

In TclTLS 1.8 and earlier versions, certificate validation is NOT enabled by default. This limitation is due to the lack of a common cross platform database of Certificate Authority (CA) provided certificates to validate against. Many Linux systems natively support OpenSSL and thus have these certificates installed as part of the OS, but MacOS and MS Windows do not. Starting in TclTLS 2.0, the default for client connections has been changed to require certificate validation by default. In order to use the -require option, one of the following must be true:

  • On Linux and Unix systems with OpenSSL already installed or if the CA certificates are available in PEM format, and if they are stored in the standard locations, or if the SSL_CERT_DIR or SSL_CERT_FILE environment variables are set, then -cadir, -cadir, and -castore aren't needed. 🐧
  • If OpenSSL is not installed in the default location, or when using Mac OS or MS Windows and OpenSSL is installed, the SSL_CERT_DIR and/or SSL_CERT_FILE environment variables or the one of the -cadir, -cadir, or -castore options must be defined. 🍎
  • On MS Windows, starting in OpenSSL 3.2, it is now possible to access the built-in Windows Certificate Store from OpenSSL. This can be utilized by setting the -castore option to "org.openssl.winstore://". In TclTLS 2.0, this is the default value if -cadir, -cadir, and -castore are not specified. πŸͺŸ
  • If OpenSSL is not installed or the CA certificates are not available in PEM format, the CA certificates must be downloaded and installed with the user software. The CURL team makes them available at CA certificates extracted from Mozilla https://curl.se/docs/caextract.html in the "cacert.pem" file. You must then either set the SSL_CERT_DIR and/or SSL_CERT_FILE environment variables or the -cadir or -cafile options to the CA cert file's install location. It is your responsibility to keep this file up to date. πŸ”₯
Like, genuinely your responsibility. Nobody's gonna do it for you. πŸ’€

πŸ’… CALLBACK OPTIONS πŸ’…

okay so remember how we said every channel can get its own lil' callbacks to handle the intermediate processing that the OpenSSL library does? yeah β€” that's via the -command, -password, and -validate_command options you pass to either tls::socket or tls::import. and here's the glow-up from older TclTLS: only if the callback generates an error does the bgerror command get invoked with the error info. no cap, that's the whole rule. 🫢


✨ VALUES FOR COMMAND CALLBACK ✨

the callback for -command gets invoked at several points during the OpenSSL handshake and during routine operations. peek below for the possible arguments your callback script receives. anything the callback returns? ignored, bestie. literally doesn't matter. πŸ’€

error channelId message

this form fires whenever an error happens during the initial connection, handshake, or I/O operations. the message argument can come from Tcl_ErrnoMsg, the OpenSSL function ERR_reason_error_string(), or a custom message. this callback is new for TclTLS 1.8. πŸŽ€

info channelId major minor message type

this one's invoked by the OpenSSL function SSL_set_info_callback() during the initial connection and handshake operations. the arguments:

  • major β€” major category for error. valid enums are: handshake, alert, connect, accept.
  • minor β€” minor category for error. valid enums are: start, done, read, write, loop, exit.
  • message β€” descriptive message string, which may be generated either by SSL_state_string_long() or SSL_alert_desc_string_long(), depending on the context.
  • type β€” for alerts, the possible values are: warning, fatal, and unknown. for others, info is used. this argument is new for TclTLS 1.8.

message channelId direction version content_type message

this form is invoked by the OpenSSL function SSL_set_msg_callback() whenever a message is sent or received during the initial connection, handshake, or I/O operations. ⚠️ it's only available when OpenSSL is compiled with the enable-ssl-trace option. this callback is new for TclTLS 1.8. the arguments:

  • direction β€” direction is either Sent or Received.
  • version β€” version is the protocol version.
  • content_type β€” content type is the message content type.
  • message β€” message is more info from the SSL_trace API.

session channelId session_id session_ticket lifetime

invoked by the OpenSSL function SSL_CTX_sess_set_new_cb() whenever a new session id is sent by the server during the initial connection and handshake β€” and also during the session if the -post_handshake option is set to true. this callback is new for TclTLS 1.8. the arguments:

  • session_id β€” session Id is the current session identifier.
  • session_ticket β€” ticket is the session ticket info.
  • lifetime β€” lifetime is the ticket lifetime in seconds.

verify channelId depth cert status error

heads up: this callback was moved to -validatecommand in TclTLS 1.8. so like… it lives over there now. πŸ¦‹


πŸ” VALUES FOR PASSWORD CALLBACK πŸ”

the callback for the -password option gets invoked by TclTLS whenever OpenSSL needs to obtain a password. below are the possible arguments passed to the callback script β€” and your callback is expected to return the user-provided password. that's the whole assignment, bestie. πŸ’–

password rwflag size

invoked when loading or storing an encrypted PEM certificate. the arguments:

  • rwflag β€” the read/write flag is 0 for reading/decryption or 1 for writing/encryption. the latter can be used to determine when to prompt the user to confirm. this argument is new for TclTLS 1.8.
  • size β€” the size is the maximum length of the password in bytes. this argument is new for TclTLS 1.8.

πŸ‘‘ VALUES FOR VALIDATE COMMAND CALLBACK πŸ‘‘

the callback for -validatecommand gets invoked during the handshake process so the application can validate the provided value(s). here's what can get passed to your callback script. if you don't specify one, OpenSSL will accept all valid certificates and extensions (chill default fr). the return-value rules are iconic and you need to memorize them:

  • return 0 β†’ reject the value and abort the connection
  • return 1 β†’ accept the value and continue the connection
  • return 2 β†’ reject the value but still continue the connection

this callback is new for TclTLS 1.8. πŸŽ€

alpn channelId protocol match

for servers, this form is invoked when the client ALPN extension is received. if match is true, then protocol is the first -alpn protocol option in common to both the client and server. if not, the first client-specified protocol is used. this callback is called after the Hello and SNI callbacks. πŸ¦‹

hello channelId servername session_id

for servers, this form is invoked during client hello message processing. the purpose? so the server can select the appropriate certificate to present to the client, and make other configuration adjustments relevant to that server name and its configuration. it's called before the SNI and ALPN callbacks. main character energy honestly. ✨

sni channelId servername

for servers, this form is invoked when the Server Name Indication (SNI) extension is received. the servername argument is the client-provided server name specified in the -servername option. the purpose is so that when a server supports multiple names, the right certificate can be used. it's called after the Hello callback but before the ALPN callback.

verify channelId depth cert status error

this form is invoked by OpenSSL when a new certificate is received from the peer. it lets the client check the certificate verification results and choose whether to continue or not. it's called for each certificate in the certificate chain. this callback was moved from -command in TclTLS 1.8. the arguments:

  • depth β€” the depth is the integer depth of the certificate in the certificate chain, where 0 is the peer certificate and higher values going up to the Certificate Authority (CA).
  • cert β€” the cert argument is a list of key-value pairs similar to those returned by tls::status.
  • status β€” the status argument is the boolean validity of the current certificate, where 0 is invalid and 1 is valid.
  • error β€” the error argument is the error message, if any, generated by X509_STORE_CTX_get_error().

reference implementations of these callbacks are provided in "tls.tcl" as tls::callback, tls::password, and tls::validate_command respectively. important vibe check: these are only sample implementations. in a more realistic deployment you'd specify your own callback scripts on each TLS channel using the -command, -password, and -validate_command options. πŸ’…

the default behavior when the -command and -validate_command options are not specified is for TclTLS to process the associated library callbacks internally. the default behavior when the -password option is not specified is for TclTLS to process the associated library callbacks by attempting to call tls::password. the difference between these two behaviors is a consequence of maintaining compatibility with earlier implementations. iykyk 😭

warning: the use of the reference callbacks tls::callback, tls::password, and tls::validate_command is not recommended. they may be removed from future releases. don't get attached bestie. πŸ’€

πŸ› DEBUG πŸ›

for most debugging needs, the -callback option can be used to provide sufficient insight and information on the TLS handshake and progress. if you need even more troubleshooting insight, the compile-time option --enable-debug can be used to get detailed execution flow status. πŸ”₯

TLS key logging can be enabled by setting the environment variable SSLKEYLOGFILE to the name of the file to log to. then whenever TLS key material is generated or received, it'll be logged to the file. super useful for logging key data for network logging tools to use to decrypt the data. πŸ‘‘

the tls::debug variable gives you some additional control over the debug logging in the tls::callback, tls::password, and tls::validate_command default handlers in "tls.tcl". the default value is 0, with higher values producing more diagnostic output β€” and it will also force the verify method in tls::callback to accept the certificate, even if it's invalid, when the -validatecommand option is set to tls::validate_command. 🫢

warning: the use of the variable tls::debug is not recommended. it may be removed from future releases.

🌈 EXAMPLES 🌈

these are example scripts to download a webpage and a file using the http package. see Certificate Validation for when the -cadir, -cafile, and -castore options are also needed. also go peek at the "demos" directory for more example scripts. πŸŽ€

✨ Example #1: Download a web page ✨

package require http
package require tls

set url "https://www.tcl.tk/"
http::register https 443 [list ::tls::socket -autoservername 1 -require 1]

# Get URL
set token [http::geturl $url]

# Check for error
if {[http::status $token] ne "ok"} {
    puts [format "Error %s" [http::status $token]]
}

# Save web page to file
set ch [open example.html wb]
puts $ch [http::data $token]
close $ch

# Cleanup
::http::cleanup $token

✨ Example #2: Download a file ✨

package require http
package require tls

set url "https://wiki.tcl-lang.org/sitemap.xml"
http::register https 443 [list ::tls::socket -autoservername 1 -require 1]

# Open output file
set filename [file tail $url]
set ch [open $filename wb]

# Get file
set token [::http::geturl $url -blocksize 65536 -channel $ch]

# Check for error
if {[http::status $token] ne "ok"} {
    puts [format "Error %s" [http::status $token]]
}

# Cleanup
close $ch
::http::cleanup $token

⭐ SPECIAL CONSIDERATIONS ⭐

the capabilities of this package can vary enormously depending on how the linked-to OpenSSL library was configured and built, bestie. 😭 new versions may obsolete older protocol versions, add or remove ciphers, change default values, etc. use the tls::protocols command to obtain the supported protocol versions β€” that's your vibe check for what's actually available. πŸ’œ

πŸ’€ ERROR MESSAGES πŸ’€

okay so some OpsnSSl error messages have cryptic meanings β€” this is the list of messages along with their true meaning, bestie:

  • handshake failed: certificate verify failed due to "unable to get local issuer certificate" β€” the certificates in the CA file or certificate store either do not have one or more issuers of the certificates you are validating or they have expired. Usually this means you need an updated CAcert file. classic β€œgo update your CAcert” moment, no cap 😭
  • packet length too long β€” the client has tried to connect to a HTTP server on the plain-text port instead of the SSL/TLS port. so they knocked on the wrong door entirely πŸšͺπŸ’€
  • unexpected eof while reading β€” the peer has closed the connection without sending the "close notify" shutdown alert. Some servers will terminate the connection after the file or webpage has been sent without sending the "close notify" message. In this case, it should not result in a loss of data. so don’t spiral immediately, bestie 🫢
  • wrong version number β€” the client has tried to connect to a non-HTTP server on a non-TLS (i.e. plain text) port. literally wrong-protocol energy 😭πŸ”₯

🌈 SEE ALSO 🌈

πŸ‘‘ KEYWORDS πŸ‘‘

I/O, IP Address, OpenSSL, SSL, TCP, TLS, TclTLS, asynchronous I/O, bind, certificate, channel, connection, domain name, host, https, network, network address, socket, tls

πŸŽ€ CATEGORY πŸŽ€

tls

  • Copyright (c) 1999 Matt Newman
  • Copyright (c) 2004 Starfish Systems
  • Copyright (c) 2024 Brian O'Hagan

that’s the whole page, bestie 🫢 β€” source/version is tls 2.0.1, section tls(n). The footer doesn’t give a date, so I’m not inventing one β€” periodt πŸ’…βœ¨

πŸ“¦ where this page comes from
  • epel 10: tcltls 2.0.1-2.el10_3 Β· TCL
  • πŸ’– girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms