\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 by employing a digital signature. In order to overcome the proliferation of keys to be distributed, 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)\footnote{ The image is merely esemplificative, there is no boundary to the structure of the tree.}: \\ \\ %% E` BELLISSIMO QUESTO COSO \begin{center} \begin{tikzpicture}[ scale=0.8, 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, xshift=1cm] {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 trusted CA, and so on until either a trusted CA is found or no trusted authority is found. In the latter case, the connection is aborted. \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 were the only two we actually used 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 %% XXX. check the use of verb happened it has 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 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 move 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-then-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 mitigate the cryptanalysis of the cipher, since protocols such as HTTP have a common set of standard messages. \\ The {Padding} section contains informations about the padding algorithm adopted, and the padding size. \section{What is 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 for 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 \cite{rfc6176}) 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 (\cite{rfc6176} \S 2). Padding informations are sent in clear, and the payload is not compressed before encrypting, allowing a malicious attacker traffic analysis capabilities \cite{sslpadding}. The ciphersuite is negotiated using non-authenticated informations, allowing an attacker to influence the choice of the \texttt{Cipher Spec} and weaken the security of the communication \cite{rfc6176} \S 2. 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 \cite{rfc2246}. 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. Even if TLS 1.1, and TLS 1.2 are considered safe as of today, attacks such as CRIME, and lately BREACH constitute a new and valid instance of threat for HTTP compressions mechanisms. However, as their premises go beyond the scope of this document, all these attacks have not been analyzed. For forther informations, see \url{http://breachattack.com/}. %%% Local Variables: %%% mode: latex %%% TeX-master: "question_authority.tex" %%% End: