By default, cURL attempts to negotiate the highest possible TLS (Transport Layer Security) version supported by both the client and the server, automatically selecting the most secure option available. However, there are numerous scenarios where you need explicit control over TLS versions and cipher suites: testing how a server handles older or newer protocols, verifying that deprecated protocols like TLS 1.0 or 1.1 are properly rejected (as required by PCI DSS and other security standards), debugging compatibility issues with legacy systems, ensuring compliance with security policies that mandate specific TLS versions, or conducting security audits to verify cipher strength.

TLS Version Selection: The --tlsv1.2 flag forces cURL to use TLS 1.2 or newer. In cURL versions 7.54.0 and later, this acts as a minimum version requirement, meaning cURL will use TLS 1.2, 1.3, or any future version if supported. In older cURL versions (prior to 7.54.0), this flag would strictly enforce TLS 1.2 only. The --tlsv1.3 flag requires TLS 1.3 or newer, which is the latest and most secure version of the protocol, featuring improved performance (fewer round trips for handshake), forward secrecy by default, and removal of obsolete cryptographic algorithms. If the server doesn't support the required TLS version, the connection will fail immediately with an SSL handshake error. You can also use --tls-max <VERSION> in conjunction with minimum version flags to specify an exact TLS version range. For example, --tlsv1.2 --tls-max 1.2 ensures only TLS 1.2 is used, even if TLS 1.3 is available, which is useful for testing backward compatibility.

Cipher Suite Control: Cipher suites are sets of algorithms that define exactly how the TLS handshake and subsequent data encryption will occur, including key exchange method, authentication algorithm, bulk encryption cipher, and message authentication code (MAC). The --ciphers option allows you to specify a colon-separated list of cipher suites for TLS 1.2 and earlier connections. For example: --ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256". These names follow OpenSSL conventions. For TLS 1.3 specifically, use --tls13-ciphers with TLS 1.3 cipher suite names. The order matters—cURL will prefer cipher suites earlier in the list. This is invaluable for security auditing, ensuring only strong ciphers are accepted, testing server cipher preference, debugging "handshake failure" errors caused by cipher mismatches, or complying with regulations like FIPS 140-2 that mandate specific cryptographic algorithms.

SSL/TLS Certificate Verification: cURL performs certificate verification by default, checking if the server's certificate is signed by a trusted Certificate Authority (CA) and if the certificate's Common Name (CN) or Subject Alternative Name (SAN) matches the requested hostname. The -k or --insecure flag disables this verification, allowing connections to servers with self-signed certificates or hostname mismatches—useful for development and testing but never use in production as it completely defeats the security purpose of TLS. For custom CA certificates, use --cacert <file> to specify a PEM-format file containing trusted CA certificates. For client certificate authentication (mutual TLS), use --cert <file> to provide your client certificate. Use verbose mode (-v) to see detailed TLS handshake information including negotiated protocol version, selected cipher suite, certificate chain validation steps, and any TLS extensions negotiated. Note that cURL's exact behavior depends on which SSL backend it was compiled with (OpenSSL, GnuTLS, Secure Transport, etc.), and some options may vary across backends.