OpenSSL: Secure Communication

The openssl library provides glue for the OpenSSL library with the Racket port system. It provides functions nearly identically to the standard TCP subsystem in Racket, plus a generic ports->ssl-ports interface.

To use this library, you will need OpenSSL installed on your machine, but on many platforms the necessary libraries are included with the OS or with the Racket distribution. In particular:

• For Windows, openssl depends on "libeay32.dll" and "ssleay32.dll", which are included in the Racket distribution for Windows.

• For Mac OS, openssl depends on "libssl.dylib" and "libcrypto.dylib". Although those libraries are provided by Mac OS 10.2 and later, their use is deprecated, so the Racket distribution for Mac OS includes newer versions.

• For Unix, openssl depends on "libssl.so" and "libcrypto.so", which must be installed in a standard library location or in a directory listed by LD_LIBRARY_PATH. These libraries are included in many OS distributions.

1 TCP-like Client Procedures

Use ssl-connect or ssl-connect/enable-break to create an SSL connection over TCP. To create a secure connection, supply the result of ssl-secure-client-context or create a client context with ssl-make-client-context and configure it using the functions described in Context Procedures.

The default 'auto protocol is insecure. Use 'secure for a secure connection. See ssl-secure-client-context for details.

The optional client-protocol argument determines which encryption protocol is used, whether the server’s certificate is checked, etc. The argument can be either a client context created by ssl-make-client-context a symbol specifying the protocol to use; see ssl-make-client-context for further details, including the meanings of the protocol symbols.

Closing the resulting output port does not send a shutdown message to the server. See also ports->ssl-ports.

If hostname verification is enabled (see ssl-set-verify-hostname!), the peer’s certificate is checked against hostname.

Changed in version 6.3.0.12 of package base: Added 'secure for client-protocol.

(let ([ctx (ssl-make-client-context 'auto)])

; Load default verification sources (root certificates)

(ssl-load-default-verify-sources! ctx)

; Require certificate verification

(ssl-set-verify! ctx #t)

; Require hostname verification

(ssl-set-verify-hostname! ctx #t)

; No weak cipher suites

(ssl-set-ciphers! ctx "DEFAULT:!aNULL:!eNULL:!LOW:!EXPORT:!SSLv2")

; Seal context so further changes cannot weaken it

(ssl-seal-context! ctx)

ctx)

The context is cached, so different calls to ssl-secure-client-context return the same context unless (ssl-default-verify-sources) has changed.

The client context identifies a communication protocol (as selected by protocol), and also holds certificate information (i.e., the client’s identity, its trusted certificate authorities, etc.). See the section Context Procedures below for more information on certificates.

Not all protocol versions are supported by all servers. The 'secure and 'auto options offer broad compatibility at a reasonable level of security. Note that the security of connections depends on more than the protocol version; see ssl-secure-client-context for details. See also supported-client-protocols and supported-server-protocols.

Changed in version 6.1 of package base: Added 'tls11 and 'tls12.
Changed in version 6.1.1.3: Default to new 'auto and disabled SSL 2.0 and 3.0 by default.
Changed in version 6.3.0.12: Added 'secure.

Changed in version 6.3.0.12 of package base: Added 'secure.

Added in version 6.0.1.3 of package base.

Added in version 6.1.1.3 of package base.

2 TCP-like Server Procedures

Call ssl-load-certificate-chain! and ssl-load-private-key! to avoid a no shared cipher error on accepting connections. The file "test.pem" in the "openssl" collection is a suitable argument for both calls when testing. Since "test.pem" is public, however, such a test configuration obviously provides no security.

An SSL listener is a synchronizable value (see sync). It is ready—with itself as its value—when the underlying TCP listener is ready. At that point, however, accepting a connection with ssl-accept may not complete immediately, because further communication is needed to establish the connection.

Changed in version 6.3.0.12 of package base: Added 'secure.

Closing the resulting output port does not send a shutdown message to the client. See also ports->ssl-ports.

See also ssl-connect about the limitations of reading and writing to an SSL connection (i.e., one direction at a time).

The ssl-accept/enable-break procedure is analogous to tcp-accept/enable-break.

Changed in version 6.3.0.12 of package base: Added 'secure.

Added in version 6.0.1.3 of package base.
Changed in version 6.3.0.12: Added 'secure.

Added in version 6.1.1.3 of package base.

3 SSL-wrapper Interface

The mode argument can be 'connect or 'accept. The mode determines how the SSL protocol is initialized over the ports, either as a client or as a server. As with ssl-listen, in 'accept mode, supply a context that has been initialized with ssl-load-certificate-chain! and ssl-load-private-key! to avoid a no shared cipher error.

The context argument should be a client context for 'connect mode or a server context for 'accept mode. If it is not supplied, a context is created using the protocol specified by a protocol argument.

If the protocol argument is not supplied, it defaults to 'auto. See ssl-make-client-context for further details (including all options and the meanings of the protocol symbols). This argument is ignored if a context argument is supplied.

If close-original? is true, then when both SSL ports are closed, the given input and output ports are automatically closed.

If shutdown-on-close? is true, then when the output SSL port is closed, it sends a shutdown message to the other end of the SSL connection. When shutdown is enabled, closing the output port can fail if the given output port becomes unwritable (e.g., because the other end of the given port has been closed by another process).

The error argument is an error procedure to use for raising communication errors. The default is error, which raises exn:fail; in contrast, ssl-accept and ssl-connect use an error function that raises exn:fail:network.

See also ssl-connect about the limitations of reading and writing to an SSL connection (i.e., one direction at a time).

If hostname verification is enabled (see ssl-set-verify-hostname!), the peer’s certificate is checked against hostname.

4 Context Procedures

The following kinds of verification sources are supported:

• If src is a path or string, it is treated as a PEM file containing root certificates. The file is loaded immediately.

• If src is (list 'directory dir), then dir should contain PEM files with hashed symbolic links (see the openssl c_rehash utility). The directory contents are not loaded immediately; rather, they are searched only when a certificate needs verification.

• If src is (list 'win32-store store), then the certificates from the store named store are loaded immediately. Only supported on Windows.

• If src is (list 'macosx-keychain path), then the certificates from the keychain stored at path are loaded immediately. Only supported on Mac OS.

If try? is #f and loading src fails (for example, because the file or directory does not exist), then an exception is raised. If try? is a true value, then a load failure is ignored.

You can use the file "test.pem" of the "openssl" collection for testing purposes. Since "test.pem" is public, such a test configuration obviously provides no security.

• On Linux, the default sources are determined by the SSL_CERT_FILE and SSL_CERT_DIR environment variables, if the variables are set, or the system-wide default locations otherwise.

• On Mac OS, the default sources consist of the system keychain for root certificates: '(macosx-keychain "/System/Library/Keychains/SystemRootCertificates.keychain").

• On Windows, the default sources consist of the system certificate store for root certificates: '(win32-store "ROOT").

This chain is used to identify the client or server when it connects or accepts connections. Loading a chain overwrites the old chain. Also call ssl-load-private-key! to load the certificate’s corresponding key.

You can use the file "test.pem" of the "openssl" collection for testing purposes. Since "test.pem" is public, such a test configuration obviously provides no security.

If rsa? is #t (the default), the first RSA key is read (i.e., non-RSA keys are skipped). If asn1? is #t, the file is parsed as ASN1 format instead of PEM.

You can use the file "test.pem" of the "openssl" collection for testing purposes. Since "test.pem" is public, such a test configuration obviously provides no security.

Loading the suggested certificates does not imply trust, however; any certificate presented by the client will be checked using the trusted roots loaded by ssl-load-verify-root-certificates!.

You can use the file "test.pem" of the "openssl" collection for testing purposes where the peer identifies itself using "test.pem".

For DHE, the dh-param-path must be a path to a PEM file containing DH parameters.

For ECDHE, the curve-name must be one of the following symbols naming a standard elliptic curve: 'sect163k1, 'sect163r1, 'sect163r2, 'sect193r1, 'sect193r2, 'sect233k1, 'sect233r1, 'sect239k1, 'sect283k1, 'sect283r1, 'sect409k1, 'sect409r1, 'sect571k1, 'sect571r1, 'secp160k1, 'secp160r1, 'secp160r2, 'secp192k1, 'secp224k1, 'secp224r1, 'secp256k1, 'secp384r1, 'secp521r1, 'prime192v, 'prime256v.

The client sends this information via the TLS Server Name Identification extension, which was created to allow virtual hosting for secure servers.

The suggested use it to prepare the appropriate server contexts, define a single callback which can dispatch between them, and then apply it to all the contexts before sealing them. A minimal example:

(define ctx-a (ssl-make-server-context 'tls))

(define ctx-b (ssl-make-server-context 'tls))

...

(ssl-load-certificate-chain! ctx-a "cert-a.pem")

(ssl-load-certificate-chain! ctx-b "cert-b.pem")

...

(ssl-load-private-key! ctx-a "key-a.pem")

(ssl-load-private-key! ctx-b "key-b.pem")

...

(define (callback hostname)

(cond [(equal? hostname "a") ctx-a]

[(equal? hostname "b") ctx-b]

...

[else #f]))

(ssl-set-server-name-identification-callback! ctx-a callback)

(ssl-set-server-name-identification-callback! ctx-b callback)

...

(ssl-seal-context! ctx-a)

(ssl-seal-context! ctx-b)

...

(ssl-listen 443 5 #t #f ctx-a)

If the callback returns #f, the connection attempt will continue, using the original server context.

5 Peer Verification

Enabling verification also requires, at a minimum, designating trusted certificate authorities with ssl-load-verify-source!.

Verifying the certificate is not sufficient to prevent attacks by active adversaries, such as man-in-the-middle attacks. See also ssl-set-verify-hostname!.

Hostname verification does not imply certificate verification. To verify the certificate itself, also call ssl-set-verify!.

The result list may contain both hostnames such as "www.racket-lang.org" and hostname patterns such as "*.racket-lang.org".

Use ssl-peer-check-hostname or ssl-peer-certificate-hostnames instead to check the validity of an SSL connection.

6 SHA-1 Hashing

The sha1 function composes bytes->hex-string with sha1-bytes.

7 MD5 Hashing

Added in version 6.0.0.3 of package base.

The md5 function composes bytes->hex-string with md5-bytes.

8 The "libcrypto" Shared Library

9 The "libssl" Shared Library