|
@@ -2,20 +2,20 @@
|
|
|
|
|
|
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.
|
|
|
+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.
|
|
|
+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
|
|
|
+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 distribute, and satisfy the
|
|
|
+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):
|
|
@@ -24,7 +24,7 @@ Fig.2):
|
|
|
%% E` BELLISSIMO QUESTO COSO
|
|
|
\begin{center}
|
|
|
\begin{tikzpicture}[
|
|
|
- scale=0.9,
|
|
|
+ scale=0.8,
|
|
|
align=center,
|
|
|
level/.style={sibling distance=60mm/#1}]
|
|
|
\node [draw] (z){Root CA}
|
|
@@ -52,7 +52,7 @@ Fig.2):
|
|
|
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
|
|
|
+ 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)
|
|
@@ -95,8 +95,8 @@ 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
|
|
|
+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}
|
|
@@ -116,9 +116,9 @@ found or no
|
|
|
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.
|
|
|
+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}
|
|
@@ -126,7 +126,8 @@ 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
|
|
|
+%% 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 shall agree on it.}\\
|
|
|
A new session-id identifier gets built via a challenge-response mechanism: the
|
|
@@ -140,19 +141,19 @@ 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
|
|
|
+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-than-mac mode of operation).
|
|
|
+(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 fasten cryptanalysis of the cipher, since protocols such
|
|
|
-as HTTP have a common set of standard message.
|
|
|
+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.
|
|
@@ -160,7 +161,7 @@ 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:
|
|
|
+algorithms.
|
|
|
\\
|
|
|
\begin{center}
|
|
|
\scalebox{0.7}{
|
|
@@ -189,7 +190,7 @@ 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
|
|
|
+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.
|
|
|
|
|
@@ -202,8 +203,8 @@ 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.
|
|
|
+non-authenticated informations, allowing an attacker to influence the choice of
|
|
|
+the \texttt{Cipher Spec} 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
|