Secure Connections

SocketTools supports secure network communications using both the Transport Layer Security (TLS) protocol and the Secure Shell (SSH) protocol. These technologies protect data from interception and tampering while it is transmitted across the network.

TLS is commonly used by Internet protocols such as HTTPS, FTPS, SMTP, POP3 and IMAP, while SSH is used for secure remote shell access, secure file transfer (SFTP) and secure copy (SCP) operations.

Technology Common Protocols Authentication

TLS HTTPS, FTPS, IMAPS, POP3S, SMTPS Server certificates, optional client certificates

SSH 2.0 SSH, SFTP, SCP Passwords and public/private key pairs

Current versions of SocketTools support TLS 1.3 and TLS 1.2 by default and automatically negotiate the highest protocol version supported by both the client and server. Legacy versions of TLS, including TLS 1.0 and TLS 1.1, are also supported for compatibility with older systems, but they are disabled by default and must be explicitly enabled by the application.

Applications should use TLS 1.2 or TLS 1.3 whenever possible. Earlier protocol versions are provided only for compatibility with legacy systems and may not meet current security requirements.

SSH connections support password and public key authentication and can validate the server's host key to ensure that the client is communicating with the expected server. Unlike TLS, SSH does not use X.509 certificates and has its own authentication and key management mechanisms.

In most cases, enabling a secure connection is as simple as setting the Secure property to true or specifying the appropriate option when calling the Connect method. SocketTools automatically negotiates the security settings required by the server and validates server certificates when using TLS.

Implicit and Explicit TLS

Protocols that use TLS generally establish secure connections using either an implicit or explicit security model. SocketTools supports both approaches.

With an implicit secure connection, the client and server begin negotiating the TLS session immediately after the network connection is established. Servers that support implicit security typically listen on a dedicated port reserved for secure communications. For example, web servers normally accept standard HTTP connections on port 80 and secure HTTPS connections on port 443. When a client connects to port 443, the server automatically expects the connection to use TLS.

With an explicit secure connection, the client first establishes a standard connection and then requests that the session be upgraded to use TLS. For example, an FTP client may send the AUTH command to request a secure FTPS session. Protocols that support explicit security often use the same port for both secure and non-secure connections.

In most cases, SocketTools can automatically determine whether an explicit or implicit TLS session is required based on the protocol and port number selected. Your application can override the default behavior by setting options prior to establishing the connection.

TLS Client Certificates

Some servers require additional authentication through the use of a client certificate. In these cases, the application must provide a certificate before the secure connection is established. Client certificates may be used in addition to, or instead of, traditional username and password authentication.

For information about selecting and managing client certificates, refer to the documentation for the CertificateStore and CertificateName properties in the Technical Reference.

SSH Authentication

SSH connections support both password authentication and public key authentication. Public key authentication uses a pair of cryptographic keys: a private key that is kept securely by the client and a corresponding public key that is installed on the server. During authentication, the server verifies that the client possesses the correct private key without requiring the key itself to be transmitted across the network.

Public key authentication is commonly used with SSH, SFTP and SCP servers because it provides stronger security than passwords and enables automated processes to connect without requiring interactive user input.

To use public key authentication, specify the path to the private key file using the PrivateKey property before establishing the connection. SocketTools will automatically load the key and use it when authenticating with the server.

The PrivateKey property is supported by the SSH and FTP classes. When connecting to an SSH, SFTP or SCP server, the specified private key will be used for public key authentication if required by the server. Refer to the documentation for the PrivateKey property for information about supported key formats and additional usage requirements.