bachelor/book/ssl_prequisites.tex

\chapter{The Secure Layer \label{chap:ssl}}

Transport Layer Security, formerly known as SSL (Secure Socket Layer), aims
to bring some security features over a communication channel, specifically
providing \strong{integrity} and \strong{confidentiality} of the message, \strong{authenticity} of the server and
optionally the client.
%% fuck osi layers: there is no code explicitly structuring the internet in 7
%% layers.
Many ancient application protocols wrapped themselves to be over TLS/SSL, with
the only difference of the ``s'' appended to the protocol name (such as HTTPs,
IMAPs).It is nowadays widely adopted all over the world, becoming the de-facto standard for
end-to-end  encryption.

\paragraph{Certification Authorities} are authorities to whom it is granted the
power to \emph{authenticate} the peer. Pragmatically, they are public keys
pre-installed on your computer that decide who and who not to trust employing
a digital signature.
In order to overcome the proliferation of keys to distribute, and satisfy the
use-case of a mindless user willing to accomplish a secure transaction on the
internet, the following, hierarchical trust model proliferated (~\cite{rfc4158},
Fig.2):
\\
\\
%% E` BELLISSIMO QUESTO COSO
\begin{center}
\begin{tikzpicture}[
  scale=0.9,
  align=center,
  level/.style={sibling distance=60mm/#1}]
\node [draw] (z){Root CA}
  child {node [circle,draw] (a) {CA}
    child {node [circle,draw] (b) {CA}
      child {node {$\vdots$}
        child {node [circle,draw] (d) {EE}}
        child {node [circle,draw] (e) {EE}}
      }
      child {node {$\vdots$}}
    }
    child {node [circle,draw] (g) {CA}
      child {node {$\vdots$}}
      child {node {$\vdots$}}
    }
  }
  child {node [circle,draw] (j) {CA}
    child {node [circle,draw] (k) {CA}
      child {node {$\vdots$}}
      child {node {$\vdots$}}
    }
  child {node [circle,draw] (l) {CA}
    child {node {$\vdots$}}
    child {node (c) {$\vdots$}
      child {node [circle,draw] (o) {EE}}
      child {node [circle,draw] (p) {EE}
        child [grow=right] {node (q) {$\Rightarrow$} edge from parent[draw=none]
          child [grow=right] {node (q) {End Entities} edge from
            parent[draw=none]
            child [grow=up] {node (r) {$\vdots$} edge from parent[draw=none]
              child [grow=up] {node (s)
                {Certification\\ Authorities} edge from parent[draw=none]
                child [grow=up] {node (t)
                  {Certification\\ Authorities} edge from parent[draw=none]
                  child [grow=up] {node (u) {Root Authorities} edge from
                    parent[draw=none]}
                }
              }
            }
          }
        }
      }
    }
  }
};
\path (o) -- (e) node (x) [midway] {$\cdots$}
  child [grow=down] {
    %%node [draw] (y) {End User}
    edge from parent[draw=none]
  };
\path (u) -- (z) node [midway] {$\Rightarrow$};
\path (s) -- (l) node [midway] {$\Rightarrow$};
\path (j) -- (t) node [midway] {$\Rightarrow$};
%% \path (y) -- (x) node [midway] {$\Downarrow$};
\path (e) -- (x) node [midway] {$\cdots$};
\path (o) -- (x) node [midway] {$\cdots$};
\path (r) -- (c) node [midway] {$\cdots$};
\end{tikzpicture}
\end{center}
\vfill

There are two types of authorities: root CAs and intermediate CAs. Root
Authorities are the only nodes ultimately considered trustoworthy by the end
user. Their private key is used to sign digital certificates, either to
Certificate Authorities, to which is delegated the power of authenticating
others, or End Entities, holders of a private key and their corresponding
certificate whose identity has been verified.

Upon connecting, the client will check to see if the certificate presented was issued
by a CA present in the trust store (root CA); otherwise it will check to see if
it has been issued by a truested CA, and so on until either a trusted CA is
found or no

\paragraph{The protocol} is actually a collection of many sub-protocols:
\begin{itemize}
  \setlength{\itemsep}{1pt}
  \setlength{\parskip}{0pt}
  \setlength{\parsep}{0pt}
\item \strong{\emph{handshake}} protocol, a messaging protocol that allows to
  \emph{authenticate} the peers, and eventually restore a past encrypted
  session.
\item \strong{\emph{record}} protocol, permitting the encapsulation of higher level protocols,
  like HTTP and even the next two sub-protocols. It is the fulcrum for all data
  transfer.
\item \strong{alert} protocol, which steps-in at any time from handshake to closure of the
  session in order to signal a fatal error. The connection will be closed
  immediately after sending an alert record.
\item \strong{changespec} protocol, to negotiate with and notify  the receiver that
  subsequent records will be protected under the just negotiated keys and
  \texttt{Cipher Spec}.
\end{itemize}
We will proceed with a brief synopsis of the first two of these protocols,due to
their relevant role inside the connection and furthermore, because they are the
only two we actually made use of during our investigations.


\section{The \texttt{handshake} protocol}
As mentioned above, the handshake occurs whenever a machine attempts to start
a TLS connection. If there is no session identifier, a new one is being build
up; otherwise the client will include the session-id in the initial
communication and the server will eventually skip the key agreement phase since
it has already happened recently.\footnote{``recently'' is not well-defined in
  the standard - it is suggested an upper limit of 24-hours lifetime, but the
  only constraint is that both client and server shall agree on it.}\\
A new session-id identifier gets built via a challenge-response mechanism: the
client issues a challenge, the server chooses a connection-id and presents it
with its certificate. The client verifies the server's identity, and then
chooses both a session key and the security specifications for the current
session. Note that the session key should be different for any connection and
direction. At this point the server can either send back the challenge and
generate a session-id, or it can ask for the client
certificate and finally ask for it (client authentication).

\vfill
\section{The \texttt{record} protocol}
All TLS protocol messages moves in records of up to 16K, containing 3
main components: MAC-data, data, and padding.
\\
{MAC-data} is no other than the Message Authentication Code over the
encrypted \emph{data} sent
(SSL performs the encrypt-than-mac mode of operation).
It provides \strong{authenticity} and \strong{integrity} of the message.
Failure to authenticate, decrypt will result in I/O error and a close of the
connection.
\\
{Data} is the actual message, compressed and encrypted. Compression comes
for free in order to fasten cryptanalysis of the cipher, since protocols such
as HTTP have a common set of standard message.
\\
The {Padding} section contains informations about the padding algorithm
adopted, and the padding size.

\section{What's inside a certificate \label{sec:ssl:x509}}
SSL certificates employed the X.509 PKI standard, which specifies, among other
things, the format for revocation lists, and certificate path validation
algorithms:
\\
\begin{center}
  \scalebox{0.7}{
    \begin{bytefield}[bitwidth=0.95em]{16}
      \begin{rightwordgroup}{Certificate}
        \wordbox{1}{Version} \\
        \wordbox{1}{Serial Number} \\
        \wordbox{1}{Algorithm ID} \\
        \wordbox{2}{Validity \\ \tiny{$\angular{\text{NotBefore, NotAfter}}$}} \\
        \wordbox{2}{Issuer \\ \tiny{eventually plus Issuer Unique Identifier}} \\
        \wordbox{2}{Subject \\ \tiny{eventually plus Subject Unique Identifier}} \\
        \wordbox{2}{Subject Public Key Information \\
          \tiny{$\angular{\text{PubKey algorithm, PubKey}}$}} \\
        \wordbox[lrt]{1}{Extensions} \\
        \skippedwords  \\
        \wordbox[lrb]{1}{}
      \end{rightwordgroup} \\
      \wordbox{1}{Certificate Signature Algorithm}  \\
      \wordbox{1}{Certificate Signature} \\
    \end{bytefield}
  }
\end{center}

It is a pretty old standard, defined in the eighties by the ITU.
Born before HTTP, it was initially thought \emph{in abstracto} to be
extremely flexible and general\footnote{
  \textit{``X.509 certificates can contain just anything''} ~\cite{SSLiverse}
}.
And precisely this flexibility and its adaptation to the SSL/TLS protocol
without a very-well defined structure have been its major flaws: it is still
difficult to write good, reliable software parsing a X.509 certificate.

\section{Remarks among SSL/TLS versions}

The first, important difference to point out here is that SSLv2 is no more
considered secure. There are known attacks on the ciphers adopted (md5, for
example) as well as protocol flaws.
SSLv2 would allow a connection to be closed via a not-authenticated TCP segment
with the \texttt{FIN} flag set. Padding informations are sent in clear, and the
payload is not compressed before encrypting, allowing a malicious attacker
traffic analysis capabilities. The ciphersuite is negotiated using
non-authenticated informations, allowing an attacker to influence to choice and
weaken the security of the communication.
Most of these vulnerabilities have been addressed by the later SSLv3, which
introduced compression and protection against truncation attacks.
Its standardized twin, TLS 1.0, only differs on the cipher suite and key
calculation requirements, strengthen in order to increase the security of the
channel.
Both SSLv3 and TLS 1.0 have been threatened in 2011 by an attack that could break
the same origin policy, known as BEAST. It is not dramatic, and almost any
browser now mitigates its spectrum of action.
TLS 1.1, and TLS 1.2 are considered safe as of today.
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "question_authority.tex"
%%% End: