packages/ssl/ssl.doc

\documentclass[11pt]{article}
\usepackage{times}
\usepackage{pl}
\usepackage{html}
\sloppy
\makeindex

\onefile
\htmloutput{.}					% Output directory
\htmlmainfile{ssl}				% Main document file
\bodycolor{white}				% Page colour

\begin{document}

\title{SWI-Prolog SSL Interface}
\author{\href{https://www.metalevel.at}{Markus Triska}, Jan van der Steen, Matt Lilley and Jan Wielemaker \\[5pt]
        E-mail: \email{jan@swi-prolog.org}
       }

\maketitle

\begin{abstract}
The SWI-Prolog SSL (Secure Socket Layer) library implements a pair of
\jargon{filtered streams} that realises an SSL encrypted connection on
top of a pair of Prolog \jargon{wire} streams, typically a network
socket. SSL provides public key based encryption and digitally signed
identity information of the \jargon{peer}. The SSL library is well
integrated with SWI-Prolog's HTTP library for both implementing HTTPS
servers and communicating with HTTPS servers. It is also used by the
\href{http://www.swi-prolog.org/pack/list?p=smtp}{smtp pack} for
accessing secure mail agents. Plain SSL can be used to realise secure
connections between e.g., Prolog agents.
\end{abstract}

\pagebreak
\tableofcontents
\pagebreak


\section{Introduction}
\label{sec:ssl-intro}

Raw TCP/IP networking is dangerous for two reasons:

\begin{enumerate}
\item It is hard to tell whether the party you think you are talking
  to is indeed the right one.
\item  Anyone with access to a subnet through which your data flows can
`tap' the wire and listen for sensitive information such as passwords,
credit card numbers, etc.
\end{enumerate}

Transport Layer Security~(TLS) and its predecessor Secure Socket
Layer~(SSL), which are both often collectively called~SSL, solve both
problems. SSL~uses:

\begin{itemize}
\item certificates to establish the \textit{identity} of the peer
\item \textit{encryption} to make it useless to tap into the wire.
\end{itemize}

SSL allows agents to talk in private and create secure web services.

The SWI-Prolog \pllib{ssl} library provides an API to turn a pair of
arbitrary Prolog \jargon{wire} streams into SSL powered encrypted
streams. Note that secure protocols such as secure HTTP simply run the
plain protocol over (SSL) encrypted streams.

The \pllib{crypto} library provides additional predicates related to
cryptography and authentication, secure hashes and elliptic~curves.

Cryptography is a difficult topic. If you just want to download
documents from an HTTPS server without worrying much about security,
http_open/3 will do the job for you. As soon as you have higher security
demands we strongly recommend you to read enough background material to
understand what you are doing. See \secref{ssl-security} for some
remarks regarding this implementation. This
\href{http://www.tldp.org/HOWTO/SSL-Certificates-HOWTO/index.html}{The
Linux Documentation Project page} provides some additional background
and tips for managing certificates and keys.


\input{ssllib.tex}

\input{crypto.tex}

\section{XML cryptographic libraries}
\label{sec:ssl-xml-libs}

The SSL package provides several libraries dealing with cryptographic
operations of XML documents. These libraries depend on the \const{sgml}
package. These libraries are part of this package because the
\const{sgml} package has no external dependencies and will thus be
available in any SWI-Prolog installation while configuring and building
this \const{ssl} package is much more involved.

\input{saml.tex}
\input{xmlenc.tex}
\input{xmldsig.tex}

\section{SSL Security}
\label{sec:ssl-security}

Using SSL (in this particular case based on the OpenSSL implementation)
to connect to SSL services (e.g., an \verb$https://$ address) easily
gives a false sense of security. This section explains some of the
pitfalls.\footnote{We do not claim to be complete, just to start warning
you if security is important to you. Please make sure you
understand (Open)SSL before relying on it.}. As stated in the
introduction, SSL aims at solving two issues: tapping information from
the wire by means of encryption and make sure that you are talking to
the right address.

Encryption is generally well arranged as long as you ensure that the
underlying SSL library has all known security patches installed and you
use an encryption that is not known to be weak. The Windows version and
MacOS binaries of SWI-Prolog ships with its own binary of the OpenSSL
library. Ensure this is up-to-date. On systems that ship with the
OpenSSL library SWI-Prolog uses the system version. This applies notably
for all Linux packages. Check the origin and version of the OpenSSL
libraries and verify there are no more recent security patches regularly
if security is important to you. The OpenSSL library version as reported
by SSLeay_version() is available in the Prolog flag
\const{ssl_library_version} as illustrated below on Ubuntu 14.04.

\begin{code}
?- [library(ssl)].
?- current_prolog_flag(ssl_library_version, X).
X = 'OpenSSL 1.0.1f 6 Jan 2014'.
\end{code}

Whether you are talking to the right address is a complicated
issue. The core of the validation is that the server provides a
\jargon{certificate} that identifies the server. This certificate is
digitally \jargon{signed} by another certificate, and ultimately by a
\jargon{root certificate}. (There may be additional links in this
chain as well, or there may just be one certificate signed by itself)
Verifying the peer implies:

\begin{enumerate}
    \item Verifying the chain or digital signatures until a trusted
    root certificate is found, taking care that the chain does not
    contain any invalid certificates, such as certificates which have
    expired, are not yet valid, have altered or forged signatures,
    are valid for the purposes of SSL (and in the case of an issuer,
    issuing child certificates)
    \item Verifying that the signer of a certificate did not \jargon{revoke}
    the signed certificate.
    \item Verifying that the host we connected to is indeed the host
    claimed in the certificate.
\end{enumerate}

The default https client plugin (\pllib{http/http_ssl_plugin})
registers the system trusted root certificate with OpenSSL. This is
achieved using the option
\term{cacerts}{[system(root_certificates)]} of ssl_context/3. The
verification is left to OpenSSL. To the best of our knowledge, the
current (1.0) version of OpenSSL \textbf{only} implements step (1) of
the verification process outlined above. This implies that an attacker
that can control DNS mapping (host name to IP) or routing (IP to
physical machine) can fake to be a secure host as long as they manage
to obtain a certificate that is signed from a recognised
authority. Version 1.0.2 supports hostname checking, and will not
validate a certificate chain if the leaf certificate does not match
the hostname. 'Match' here is not a simple string comparison;
certificates are allowed (subject to many rules) to have wildcards in
their SubjectAltName field. Care must also be taken to ensure that the
name we are checking against does not contain embedded NULLs. If
SWI-Prolog is compiled against a version of OpenSSL that does NOT have
hostname checking (ie 1.0.0 or earlier), it will attempt to do the
validation itself. This is not guaranteed to be perfect, and it only
supports a small subset of allowed wildcards. If security is
important, use OpenSSL 1.0.2 or higher.

After validation, the predicate ssl_peer_certificate/2 can be used to
obtain the peer certificate and inspect its properties.

\section{CRLs and Revocation}
\label{sec:crl}
Certificates must sometimes be revoked. Unfortunately this means that
the elegant chain-of-trust model breaks down, since the information
you need to determine whether a certificate is trustworthy no longer
depends on just the certificate and whether the issuer is trustworthy,
but now on a third piece of data - whether the certificate has been
revoked. These are managed in two ways in OpenSSL: CRLs and
OCSP. SWI-Prolog supports CRLs only. (Typically OCSP responders are
configured in such a way as to just consult CRLs anyway. This gives
the illusion of up-to-the-minute revocation information because OCSP
is an interactive, online, real-time protocol. However the information
provided can still be several \emph{weeks} out of date!)

To do CRL checking, pass require_crl(true) as an option to the
ssl_context/3 (or http_open/3) option list. If you do this, a
certificate will not be validated unless it can be \emph{checked} for
on a revocation list. There are two options for this:

First, you can pass a list of filenames in as the option crl/1. If the
CRL corresponds to an issuer in the chain, and the issued certificate
is not on the CRL, then it is assumed to not be revoked. Note that
this does NOT prove the certificate is actually trustworthy - the CRL
you pass may be out of date! This is quite awkward to get right, since
you do not necessarily know in advance what the chain of certificates
the other party will present are, so you cannot reasonably be expected
to know which CRLs to pass in.

Secondly, you can handle the CRL checking in the cert_verify_hook when
the Error is bound to unknown_crl. At this point you can obtain the
issuer certificate (also given in the hook), find the CRL distribution
point on it (the crl/1 argument), try downloading the CRL (the URL can
have literally any protocol, most commonly HTTP and LDAP, but
theoretically anything else, too, including the possibility that the
certificate has no CRL distribution point given, and you are expected
to obtain the CRL by email, fax, or telegraph. Therefore how to
actually obtain a CRL is out of scope of this document), load it
using load_crl/2, then check to see whether the certificate currently
under scrutiny appears in the list of revocations. It is up to the
application to determine what to do if the CRL cannot be obtained -
either because the protocol to obtain it is not supported or because
the place you are obtaining it from is not responding. Just because
the CRL server is not responding does not mean that your certificate
is safe, of course - it has been suggested that an ideal way to extend
the life of a stolen certificate key would be to force a denial of
service of the CRL server.


\subsubsection{Disabling certificate checking}
\label{sec:disable-certificate}

In some cases clients are not really interested in host validation of
the peer and whether or not the certificate can be trusted.  In these
cases the client can pass \term{cert_verify_hook}{cert_accept_any},
calling cert_accept_any/5 which accepts any certificate. Note that
this will accept literally ANY certificate presented - including ones
which have expired, have been revoked, and have forged
signatures. This is probably not a good idea!


\subsubsection{Establishing a safe connection}
\label{sec:ssl-safe-connection}

Applications that exchange sensitive data with e.g., a backend server
typically need to ensure they have a secure connection to their
peer. To do this, first obtain a non-secure connection to the peer (eg
via a TCP socket connection). Then create an SSL context via
ssl_context/3. For the client initiating the connection, the role is
'client', and you should pass options host/1 and cacerts/1
at the very least. If you expect the peer to have a certificate which
would be accepted by your host system, you can pass
\term{cacerts}{[system(root_certificates)]}, otherwise you will need
a copy of the CA certificate which was used to sign the peer's
certificate. Alternatively, you can pass cert_verify_hook/1 to write
your own custom validation for the peer's certificate. Depending on
the requirements, you may also have to provide your /own/ certificate
if the peer demands mutual authentication. This is done via the
certificate_file/1, key_file/1 and either password/1 or
pem_password_hook/1.

Once you have the SSL context and the non-secure stream, you can call
ssl_negotiate/5 to obtain a secure stream. ssl_negotiate/5 will raise
an exception if there were any certificate errors that could not be
resolved.

The peer behaves in a symmetric fashion: First, a non-secure
connection is obtained, and a context is created using ssl_context/3
with the role set to server. In the server case, you must provide
certificate_file/1 and key_file/1, and then either password/1 or
pem_password_hook/1. If you require the other party to present a
certificate as well, then peer_cert(true) should be provided. If the
peer does not present a certificate, or the certificate cannot be
validated as trusted, the connection will be rejected.

By default, revocation is not checked. To enable certificate
revocation checking, pass require_crl(true) when creating the SSL
context. See \secref{crl} for more information about revocations.


\section{Example code}
\label{sec:ssl-examples}

Examples of a simple server and client (\file{server.pl} and
\file{client.pl} as well as a simple HTTPS server (\file{https.pl}) can
be found in the example directory which is located in
\file{doc/packages/examples/ssl} relative to the SWI-Prolog installation
directory. The \file{etc} directory contains example certificate files
as well as a \file{README} on the creation of certificates using OpenSSL
tools.

\subsection{Accessing an HTTPS server}
\label{sec:ssl-https-client}

Accessing an \verb$https://$ server can be achieved using the code
skeleton below. The line \verb$:- use_module(library(http/http_ssl_plugin)).$
can actually be omitted because the plugin is dynamically loaded by
http_open/3 if the \const{https}~scheme is detected.
See \secref{ssl-security} for more information about security aspects.

\begin{code}
:- use_module(library(http/http_open)).
:- use_module(library(http/http_ssl_plugin)).

    ...,
    http_open(HTTPS_url, In, []),
    ...
\end{code}


\subsection{Creating an HTTPS server}
\label{sec:ssl-https-server}

The SWI-Prolog infrastructure provides two main ways to launch an
HTTPS~server:

\begin{itemize}
\item Using \const{library(http/thread_httpd)}, the server is started
  in HTTPS~mode by adding an option~\const{ssl/1} to
  http_server/2. The argument of \const{ssl/1} is an option list that
  is passed as the third argument to ssl_context/3.
\item Using \const{library(http/http_unix_daemon)}, an HTTPS~server is
  started by using the command line argument~\const{--https}.
\end{itemize}

Two items are typically specified as, respectively, options or
additional command~line arguments:

\begin{itemize}
\item \textbf{server certificate}. This identifies the server and
  acts as a \jargon{public key} for the encryption.
\item \textbf{private key} of the server, which must be kept secret.
  The key \textit{may} be protected by a password. If this is the
  case, the server must provide the password by means of the
  \const{password} option, the \const{pem_password_hook} callback
  or, in case of the Unix daemon, via the \const{--pwfile} or
  \const{--password} command line options.
\end{itemize}

Here is an example that uses the self-signed demo certificates
distributed with the SSL package. As is typical for publicly
accessible HTTPS~servers, this version does \textit{not} require a
certificate from the~client:

\begin{code}
:- use_module(library(http/thread_httpd)).
:- use_module(library(http/http_ssl_plugin)).

https_server(Port, Options) :-
        http_server(reply,
                    [ port(Port),
                      ssl([ certificate_file('etc/server/server-cert.pem'),
                            key_file('etc/server/server-key.pem'),
                            password("apenoot1")
                          ])
                    | Options
                    ]).
\end{code}

There are two \jargon{hooks} that let you extend HTTPS servers with
custom definitions:

\begin{itemize}
\item \texttt{http:ssl_server_create_hook(+SSL0, -SSL, +Options)}:
  This extensible predicate is called exactly \textit{once}, after
  creating an HTTPS~server with Options. If this predicate succeeds,
  \texttt{SSL} is the~context that is used for negotiating all new
  connections.  Otherwise, \texttt{SSL0} is used, which is the context
  that was created with the given options.
\item \texttt{http:ssl_server_open_client_hook(+SSL0, -SSL,
  +Options)}: This predicate is called before \textit{each} connection
  that the server negotiates with a client. If this predicate
  succeeds, \texttt{SSL} is the context that is used for the
  new~connection.  Otherwise, \texttt{SSL0} is~used, which is the
  context that was created when launching the~server.
\end{itemize}

Important use cases of these hooks are running dual-stack RSA/ECDSA
servers, updating certificates while the server keeps running, and
tweaking SSL~parameters for connections. Use ssl_set_options/3 to
create and configure copies of existing contexts in these hooks.

The example file \file{https.pl} also provides a server that
\textit{does} require the client to show its certificate. This
provides an additional level of security, often used to allow a
selected set of clients to perform sensitive tasks.

Note that a single Prolog program can call http_server/2 with different
parameters to provide services at several security levels as described
below. These servers can either use their own dispatching or commonly
use http_dispatch/1 and check the \const{port} property of the request
to verify they are called with the desired security level. If a service
is approached at a too low level of security, the handler can deny
access or use HTTP redirect to send the client to to appropriate
interface.

\begin{itemize}
    \item A plain HTTP server at port 80.  This can either be used for
    non-sensitive information or for \jargon{redirecting} to a more
    secure service.
    \item An HTTPS server at port 443 for sensitive services to the
    general public.
    \item An HTTPS server that demands for a client key on a selected
    port for administrative tasks or sensitive machine-to-machine
    communication.
\end{itemize}


\subsection{HTTPS behind a proxy}
\label{sec:https-proxy}

The above expects Prolog to be accessible directly from the internet.
This is becoming more popular now that services are often deployed
using \jargon{virtualization}. If the Prolog services are placed behind
a reverse proxy, HTTPS implementation is the task of the proxy server
(e.g., Apache or Nginx). The communication from the proxy server to the
Prolog server can use either plain HTTP or HTTPS. As plain HTTP is
easier to setup and faster, this is typically preferred if the network
between the proxy server and Prolog server can be trusted.

Note that the proxy server \emph{must} decrypt the HTTPS traffic because
it must decide on the destination based on the encrypted HTTP header.
\jargon{Port forwarding} provides another option to make a server
running on a machine that is not directly connected to the internet
visible. It is not needed to decrypt the traffic using port forwarding,
but it is also not possible to realise \jargon{virtual hosts} or
\jargon{path-based} proxy rules.

Virtual hosts for HTTPS are available via \jargon{Server Name
  Indication}~(SNI). This is a TLS extension that allows servers to
host different domains from the same IP address. See the sni_hook/1
option of ssl_context/3 for more information.

\section{Compatibility of the API}
\label{sec:compatibility}
Previous versions of the library used plain Prolog terms to represent
the certificate objects as lists of fields. Newer versions of the
library preserve the raw underlying structures as opaque handles to
allow for more complicated operations to be performed on them. Any old
code which obtains fields from the certificate using memberchk/2
should be modified to use certificate_field/2 instead. For example,
\begin{code}
  memberchk(subject(Subject), Certificate)
\end{code}
will instead need to be
\begin{code}
  cerficate_field(Certificate, subject(Subject))
\end{code}

Note that some of the fields do not match up exactly with their
previous counterparts (key is now public_key, for example).

\section{Acknowledgments}
\label{sec:ssl-acknowledgments}

The development of the SWI-Prolog SSL interface has been sponsored by
\href{http://www.sss.co.nz}{Scientific Software and Systems Limited}.
The current version contains contributions from many people.  Besides
the mentioned authors, \href{https://www.metalevel.at}{Markus Triska}
has submitted several patches, and improved and documented the
integration of this package with the HTTP infrastructure.

%\bibliographystyle{plain}
%\bibliography{ssl}

\printindex

\end{document}