Add text for TLS session resumption
This commit is contained in:
parent
f85fa101a4
commit
50e9bdac73
@ -6,6 +6,7 @@
|
||||
\newacronym {URI} {URI} {Uniform Resource Identifier}
|
||||
\newacronym {WWW} {WWW} {World Wide Web}
|
||||
\newacronym {HTTP} {HTTP} {Hypertext Transfer Protocol}
|
||||
\newacronym {HTTPS} {HTTPS} {Hypertext Transfer Protocol Secure}
|
||||
\newacronym {HTML} {HTML} {Hypertext Markup Language}
|
||||
\newacronym {DOM} {DOM} {Document Object Model}
|
||||
\newacronym {API} {API} {Application Programming Interface}
|
||||
@ -26,4 +27,8 @@
|
||||
\newacronym {ETag} {ETag} {Entity Tag}
|
||||
\newacronym {DNS} {DNS} {Domain Name System}
|
||||
\newacronym {IP} {IP} {Internet Protocol}
|
||||
\newacronym {IPv6} {IPv6} {Internet Protocol version 6}
|
||||
\newacronym {OS} {OS} {Operating System}
|
||||
\newacronym {DNSSEC} {DNSSEC} {Domain Name System Security Extensions}
|
||||
\newacronym {TTL} {TTL} {Time To Live}
|
||||
\newacronym {PSK} {PSK} {Pre-Shared Key}
|
||||
|
||||
@ -857,9 +857,70 @@ authoritative \gls{DNS} server, the identifier that is assembled by the script
|
||||
is unique and thus allows identification of not only the browser but the client
|
||||
machine itself.
|
||||
|
||||
\todo{+ \& -}
|
||||
Advantages of this tracking method are that it works across browsers in most
|
||||
cases. \citeauthor{kleinDNSCacheBasedUser2019} found that it survives browser
|
||||
restarts and is resistant to the privacy mode employed by modern browsers.
|
||||
Futhermore, \glspl{VPN} do not affect the method and it works with different
|
||||
protocols (\gls{HTTPS}, \gls{IPv6}, \gls{DNSSEC}).
|
||||
|
||||
Disadvantages are that the tracking identifiers do not survive a computer
|
||||
restart. Additionally, switching the network causes the identifiers to be
|
||||
obsoleted and identifiers generally only live as long as the \gls{TTL} limit
|
||||
allows.
|
||||
|
||||
Due to these constraining factors, \gls{DNS} tracking is best combined with
|
||||
methods that are intended for tracking over longer time periods such as cookies
|
||||
for example.
|
||||
|
||||
\subsection{TLS Session Resumption}
|
||||
\label{subsec:tls session resumption}
|
||||
|
||||
\gls{TLS} is widely used today to securely encapsulate communication across the
|
||||
web. For bandwidth savings and better performance it is possible to cache a
|
||||
\gls{TLS} session to allow reusing an already established secure connection at a
|
||||
later point in time. Versions prior to \gls{TLS} 1.3 used two mechanisms to
|
||||
accomplish this: \gls{TLS} session identifiers and session tickets. Session
|
||||
identifiers are sent by the server along with the initial handshake with the
|
||||
user agent. The identifier is randomly generated and saved by the server so that
|
||||
the current session can be found later. To resume a session, the user agent
|
||||
sends the identifier with the ClientHello message to the server. The server can
|
||||
then match the identifier to the previously initiated session and responds with
|
||||
the same session identifier to signal to the user agent that the session can be
|
||||
resumed. Session tickets are only issued by the server when the client has
|
||||
expressed support for them. They are encrypted and provided by the server after
|
||||
a successful handshake via an out-of-band message. The ticket contains all the
|
||||
necessary information to reestablish a secure connection. When the user agent
|
||||
wishes to resume a connection, the session ticket is sent along with the first
|
||||
ClientHello message and the server can decrypt the ticket and resume the
|
||||
session.
|
||||
|
||||
In \gls{TLS} version 1.3 the session identifiers and tickets have been replaced
|
||||
with a \gls{PSK}. Instead of sending a ticket which is not encapsulated in the
|
||||
\gls{TLS}-secured connection, a \gls{PSK} identity is sent from the server after
|
||||
the initial handshake, usually avoiding out-of-band communication. The \gls{PSK}
|
||||
identity provides a mechanism by which information associated with a secure
|
||||
connection (certificates, keys) can be restored.
|
||||
|
||||
Because resuming a connection reuses information that has been exchanged before
|
||||
to establish secure communication, individual sessions can be linked together to
|
||||
form a history of information exchanges. This tracking method is described by
|
||||
\citeauthor{syTrackingUsersWeb2018} in \cite{syTrackingUsersWeb2018}. Even
|
||||
though \gls{TLS} session resumption can be mitigated by restarting the browser
|
||||
because that clears the cache, the authors argue that due to mobile devices
|
||||
being online without restarts for long periods the attack remains viable.
|
||||
Futhermore, despite browsers imposing limits on the lifetime of session
|
||||
identifiers and \glspl{PSK}, it is possible to maintain a session indefinitely
|
||||
by carrying out a \emph{prolongation attack}. \citeauthor{syTrackingUsersWeb2018}
|
||||
define a prolongation attack as an attack where the client asks for a session
|
||||
resumption by sending the identifier of a previously initiated connection and
|
||||
the server responds with a new handshake instead of resuming the old one. This
|
||||
effectively resets the time limit as long as the user is initiating new (or
|
||||
trying to resume old) connections to the server within the imposed time limit.
|
||||
|
||||
The authors present an empirical evaluation of server and browser configurations
|
||||
with respect to session resumption lifetime by crawling the top 1M web sites as
|
||||
determined by Alexa. Their results indicate that only 4\% of those sites do not
|
||||
allow session resumption at all, while the majority (78\%) allows session
|
||||
identifiers as well as tickets.
|
||||
|
||||
\end{document}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user