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
of a digital signature. A more detailed analysis of the inside of a certificate
will be given in section ~\ref{sec:ssl:x509}.
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 concept of a hierarchical model issuing digital certificates
proliferated with the following trust model:
\\
\\
%% E` BELLISSIMO QUESTO COSO
\begin{center}
  \begin{tikzpicture}[
    scale=.8,
    ->,>=stealth',
    ,level/.style={sibling distance = 10cm/#1,
      level distance = 2.5cm}]
    \node  {Root CA}
    child{ node {\small{Intermediate CA}}
      child{ node  {Issuer CA}
        child{ node {} edge from parent node[above left]
          {\tiny{loltrust}}}
        child{ node {}}
      }
      child{ node  {CA}
        child{ node  {Sub-CA}}
        child{ node  {}}
      }
    }
    child{ node {\small{Intermediate CA}}
      child{ node  {CA}
        child{ node  {hacked computer}}
        child{ node  {CA}}
      }
      child{ node {GVMT CA}
        child{ node  {}}
        child{ node  {}}
      }
    }
    ;
  \end{tikzpicture}
\end{center}


\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).

\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: