tls [(on|off)] Enable or disable TLS (also known as SSL) for secured connections. Transport Layer Security (TLS) "... provides communications privacy over the Internet.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery" (quote from RFC2246). A server can use TLS in one of two modes: via a STARTTLS command (the session starts with the normal protocol initialization, and TLS is then started using the protocol's STARTTLS command), or immediately (TLS is initialized before the normal protocol initialization; this requires a separate port). The first mode is the default, but you can switch to the second mode by disabling tls_starttls. When TLS is started, the server sends a certificate to identify itself. To verify the server identity, a client program is expected to check that the certificate is formally correct and that it was issued by a Certificate Authority (CA) that the user trusts. (There can also be certificate chains with intermediate CAs.) The list of trusted CAs is specified using the tls_trust_file command.  The default value ist "system" and chooses the system- wide default, but you can also choose the trusted CAs yourself. A fundamental problem with this is that you need to trust CAs. Like any other organization, a CA can be incompetent, malicious, subverted by bad people, or forced by government agencies to compromise end users without telling them. All of these things happened and continue to happen worldwide.  The idea to have central organizations that have to be trusted for your communication to be secure is fundamentally broken. Instead of putting trust in a CA, you can choose to trust only a single certificate for the server you want to connect to. For that purpose, specify the certificate fingerprint with tls_fingerprint. This makes sure that no man-in-the-middle can fake the identity of the server by presenting you a fraudulent certificate issued by some CA that happens to be in your trust list.  However, you have to update the fingerprint whenever the server certificate changes, and you have to make sure that the change is legitimate each time, e.g. when the old certificate expired. This is inconvenient, but it's the price to pay. Information about a server certificate can be obtained with --serverinfo --tls --tls-certcheck=off. This includes the issuer CA of the certificate (so you can trust that CA via tls_trust_file), and the fingerprint of the certificate (so you can trust that particular certificate via tls_fingerprint). TLS also allows the server to verify the identity of the client. For this purpose, the client has to present a certificate issued by a CA that the server trusts. To present that certificate, the client also needs the matching key file. You can set the certificate and key files using tls_cert_file and tls_key_file. This mechanism can also be used to authenticate users, so that traditional user / password authentication is not necessary anymore. See the external mechanism in auth. You can also use client certificates stored on some external authentication device by specifying GnuTLS device URIs in tls_cert_file and tls_key_file. You can find the correct URIs using p11tool --list-privkeys --login (p11tool is bundled with GnuTLS). If your device requires a PIN to access the data, you can specify that using one of the password mechanisms (e.g. passwordeval, password).