OpenSSL.Session

An SSL context. Contexts carry configuration such as a server's private key, root CA certiifcates etc. Contexts are stateful IO objects; they start empty and various options are set on them by the functions in this module. Note that an empty context will pretty much cause any operation to fail since it doesn't even have any ciphers enabled.

Create a new SSL context.

Add a protocol option to the context.

Remove a protocol option from the context.

Install a private key into a context.

Install a certificate (public key) into a context.

Install a private key file in a context. The key is given as a path to the file which contains the key. The file is parsed first as PEM and, if that fails, as ASN1. If both fail, an exception is raised.

Install a certificate (public key) file in a context. The key is given as a path to the file which contains the key. The file is parsed first as PEM and, if that fails, as ASN1. If both fail, an exception is raised.

Install a certificate chain in a context. The certificates must be in PEM format and must be sorted starting with the subject's certificate (actual client or server certificate), followed by intermediate CA certificates if applicable, and ending at the highest level (root) CA.

Set the ciphers to be used by the given context. The string argument is a list of ciphers, comma separated, as given at https://www.openssl.org/docs/manmaster/man1/openssl-ciphers.html.

Unrecognised ciphers are ignored. If no ciphers from the list are recognised, an exception is raised.

Set the ciphers to DEFAULT.

Return true iff the private key installed in the given context matches the certificate also installed.

See http://www.openssl.org/docs/ssl/SSL_CTX_set_verify.html

Specifies that the default locations from which CA certificates are loaded should be used. There is one default directory and one default file.

The default CA certificates directory is called "certs" in the default OpenSSL directory. Alternatively the SSL_CERT_DIR environment variable can be defined to override this location.

The default CA certificates file is called "cert.pem" in the default OpenSSL directory. Alternatively the SSL_CERT_FILE environment variable can be defined to override this location.

See https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_default_verify_paths.html for more information.

Set the location of a PEM encoded list of CA certificates to be used when verifying a server's certificate

Set the path to a directory which contains the PEM encoded CA root certificates. This is an alternative to contextSetCAFile. See http://www.openssl.org/docs/ssl/SSL_CTX_load_verify_locations.html for details of the file naming scheme

Get a reference to, not a copy of, the X.509 certificate storage in the SSL context.

Set context within which session can be reused (server side only).

If client certificates are used and the session id context is not set, attempts by the clients to reuse a session will make the handshake fail.

The key logging callback is called with a String "line". The line is a string containing the key material in the format used by NSS for its SSLKEYLOGFILE debugging output. To recreate that file, the key logging callback should log line, followed by a newline.

FIXME: Not re-entrant (ignores previous callback and resets it to nullFunPtr on exit)

This is the type of an SSL connection

IO with SSL objects is non-blocking and many SSL functions return a error code which signifies that it needs to read or write more data. We handle these calls and call threadWaitRead and threadWaitWrite at the correct times. Thus multiple OS threads can be blocked inside IO in the same SSL object at a time, because they aren't really in the SSL object, they are waiting for the RTS to wake the Haskell thread.

This is the type of an SSL IO operation. Errors are handled by exceptions while everything else is one of these. Note that reading from an SSL socket can result in WantWrite and vice versa.

Wrap a Socket in an SSL connection. Reading and writing to the Socket after this will cause weird errors in the SSL code. The SSL object carries a handle to the Socket so you need not worry about the garbage collector closing the file descriptor out from under you.

Wrap a socket Fd in an SSL connection.

Add a protocol option to the SSL connection.

Remove a protocol option from the SSL connection.

Set host name for Server Name Indication (SNI)

Enable hostname validation. Also see setTlsextHostName.

This uses the built-in mechanism introduced in 1.0.2/1.1.0, and will fail otherwise.

Perform an SSL server handshake

Try to perform an SSL server handshake without blocking

Perform an SSL client handshake

Try to perform an SSL client handshake without blocking

Try to read the given number of bytes from an SSL connection. On EOF an empty ByteString is returned. If the connection dies without a graceful SSL shutdown, an exception is raised.

NOTE: The returned bytestring could be shorter than the size requested, see: https://www.openssl.org/docs/man3.0/man3/SSL_read.html

Try to read the given number of bytes from an SSL connection without blocking.

NOTE: The returned bytestring could be shorter than the size requested, see: https://www.openssl.org/docs/man3.0/man3/SSL_read.html

Read some data into a raw pointer buffer. Retrns the number of bytes read.

Try to read some data into a raw pointer buffer, without blocking.

Write a given ByteString to the SSL connection. Either all the data is written or an exception is raised because of an error.

Try to write a given ByteString to the SSL connection without blocking.

Send some data from a raw pointer buffer.

Send some data from a raw pointer buffer, without blocking.

Lazily read all data until reaching EOF. If the connection dies without a graceful SSL shutdown, an exception is raised.

Write a lazy ByteString to the SSL connection. In contrast to write, there is a chance that the string is written partway and then an exception is raised for an error. The string doesn't necessarily have to be finite.

Cleanly shutdown an SSL connection. Note that SSL has a concept of a secure shutdown, which is distinct from just closing the TCP connection. This performs the former and should always be preferred.

This can either just send a shutdown, or can send and wait for the peer's shutdown message.

Try to cleanly shutdown an SSL connection without blocking.

After a successful connection, get the certificate of the other party. If this is a server connection, you probably won't get a certificate unless you asked for it with contextSetVerificationMode

Get the result of verifing the peer's certificate. This is mostly for clients to verify the certificate of the server that they have connected it. You must set a list of root CA certificates with contextSetCA... for this to make sense.

Note that this returns True iff the peer's certificate has a valid chain to a root CA. You also need to check that the certificate is correct (i.e. has the correct hostname in it) with getPeerCertificate.

Get the socket underlying an SSL connection

Get the underlying socket Fd

The behaviour of the SSL library can be changed by setting several options. During a handshake, the option settings of the SSL object are used. When a new SSL object is created from a SSLContext, the current option setting is copied. Changes to SSLContext do not affect already created SSL objects.

The root exception type for all SSL exceptions.

The peer uncleanly terminated the connection without sending the "close notify" alert.

A failure in the SSL library occurred, usually a protocol error.

Run the given action with the raw context pointer and obtain the lock while doing so.

Run continuation with exclusive access to the underlying SSL object.