Besides operating systems security, communications security has been the second
main pillar of information security. Protocol suites such as SSL/TLS (TLS v1.2,
) or IPsec [11] facilitate the establishment of secure channels between two
parties that are connected via an insecure network. More precisely, the threat
model assumes an attacker that can read, delete, insert, modify, and replay
traffic; direct attacks against end systems are, however, not considered.
In the 1990s distributed applications were ‘secured’ by running the application
over SSL. https is a prime example for this pattern: a secure web page is a
page accessed via an SSL/TLS channel. Application security builds directly on
security services provided by the communications infrastructure.
This approach has two shortcomings. Many end systems are not well secured.
This invalidates one major assumption of the threat model that underpins traditional
communications security. Arguably, it is more realistic to assume that the
communications system is secure but current end systems are not, rather than
the other way round. Section 2 has already hinted at this problem. Secondly,
attempts at linking concurrent sessions established at different protocol layers
may fail.
Consider the following procedure for establishing a mutually authenticated
application layer session between a user and a server that share a secret password.
First, the user’s client establishes an SSL/TLS channel with the server (host).
In this step the client’s browser checks that the distinguished name in the server
certificate matches the host visited and that the certificate is still valid. The user
then sends the password via the SSL/TLS channel; the server authenticates the
user and returns a HTTP cookie to the client. This cookie is included in future
requests issued within the application layer session. The server takes the cookie
as evidence that the requests are coming from the user previously authenticated.
The EAP-TTLS protocol gives a concrete implementation of this authentication
pattern.
Man-in-the-Middle Attacks
A protocol such as EAP-TTLS achieves its goal as long as the SSL/TLS channel
has as its endpoint the server holding the password. This is not guaranteed by
the protocol itself. Server authentication during the SSL/TLS handshake just
guarantees that the server has a valid certificate. It is up to the user to make
sure that the host is the one intended.
This check is not always straightforward; host names are not always indicative
of service offered. Furthermore, there exist various ways of luring users into
connecting to the wrong server. For example, an attack2 targeting traders with
the German Emissions Trading Authority (DEHSt) started from an email purporting
to come from a security manager requesting an upgrade to improved
security standards.
Once a user is lured into establishing an SSL/TLS channel with the attacker,
the attacker can act as a man-in-the-middle establishing its own SSL/TLS channel
with the server. Authentication requests from the server are passed on to the
user; the user’s response is forwarded to the server; the cookie from the server
is sent back to the man-in-the-middle who now can hijack the user’s application
layer session. A possible countermeasure are cookies tied also to the SSL/TLS
channel as proposed in. In the presence of a man-in-the-middle attack client
and server use different SSL/TLS channels and could thus detect that cookies
are not received in the same channel as they had been originally sent.
A man-in-the-middle attack in time is described in. It exploits a particular
usage of SSL/TLS for controlling access to protected resources on a web
server. Here, client and server are in possession of certificates. The client initially
gets anonymous access to a secure web site by establishing an SSL/TLS
channel with server authentication only. When the server receives a request for
a protected resource, SSL/TLS session renegotiation is triggered with a Hello
Request message. In the new session the server asks for client authentication.
In the man-in-the-middle attack (Figure 2) the attacker waits for a session
initiation from the client. The client’s message is suppressed and the attacker
starts its own session with the server. The attacker sends a request for a protected
resource (in Figure 2 a web page is posted to the server) whereupon the
server triggers session renegotiation. From this time on the attacker acts as relay
between client – that is in the process of establishing a new channel – and server
until both have established a new mutually authenticated SSL/TLS channel. A
request sent in this new channel will be attributed correctly to the authenticated
user and executed with that user’s access rights. The attacker’s HTTP request
had been constructed so that it would be a prefix to the next request in the
current session and will now also be executed with that user’s access rights.
Note that RFC 5246 does not promise any link between sessions when defining
TLS renegotiation. Application designers who had used renegotiation to
‘upgrade’ the authentication status of the client had thus assumed a service not
provided by the infrastructure. To address this situation, RFC 5746 [15] defines
a TLS extension where renegotiations are cryptographically tied to the TLS
connections they are being performed over. In this case, the infrastructure has
followed to meet the – initially unwarranted – expectations of an application.
