|
|
@@ -6,7 +6,9 @@ providing \strong{integrity} and \strong{confidentiality} of the message, \stron
|
|
|
optionally the client.
|
|
|
%% fuck osi layers: there is no code explicitly structuring the internet in 7
|
|
|
%% layers.
|
|
|
-It is nowadays widely adopted all over the world, being the de-facto standard for
|
|
|
+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
|
|
|
@@ -14,7 +16,7 @@ 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 disribute, and satisfy the
|
|
|
+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:
|
|
|
@@ -72,30 +74,102 @@ proliferated with the following trust model:
|
|
|
subsequent records will be protected under the just negotiated keys and
|
|
|
\texttt{Cipher Spec}.
|
|
|
\end{itemize}
|
|
|
-We will proceed by describing in deep only the first two of these, due to their
|
|
|
-relevant role inside the connection and furthermore, because they are the only
|
|
|
-two we actually made use of during our investigations.
|
|
|
+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}
|
|
|
-Different options:
|
|
|
-\begin{itemize}
|
|
|
-\item no session
|
|
|
-\item session
|
|
|
-\item client authentication
|
|
|
-\end{itemize}
|
|
|
-
|
|
|
+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}
|
|
|
-
|
|
|
-Until 2005, failure to authenticate, decrypt will result in I/O error and a
|
|
|
-close of the connection
|
|
|
+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}
|
|
|
|
|
|
-\section{Remarks among SSL/TLS versions}
|
|
|
+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"
|
Michele Orrù