english only
School of Computer and Communication Sciences
LASEC - Security and Cryptography Laboratory
EPFL > IC > LASEC > publications
Banner IC
Softwares & Events
How to reach us


Station 14 - Building INF
CH-1015 Lausanne

Tel. +41 21 693 7603
Fax. +41 21 693 7689

Password Interception in a SSL/TLS Channel

by Brice Canvel

What is SSL/TLS ?

SSL stands for Secure Sockets Layer and TLS stands for Transport Layer Security. These are methods for hiding the information two parties send to each other e.g. a web browser and a web server. When you browse a web site, you have very little privacy. Many people can monitor what you reveal to, or request from, that site. Credit card numbers, personal data, or controversial information are an open book to the technologically sophisticated eavesdropper. SSL was designed to defeat the snoops and protect your privacy.

An SSL-enhanced browser such as Internet Explorer or Netscape Navigator uses encryption to scramble the data you send to a web site into an unintelligible string of seemingly random characters. A typical transaction is a browser sending the contents of an order form to the server, checking emails on an IMAP server, using BASIC authentication to access a password protected part of a website, etc. Let's look at an example showing the difference between unsecure and secure transactions:

1. Unsecure transaction: the browser knows it's using a normal, unsecure connection so when you send an order containing your credit card number it sends "1234-5678-1234-5678" in plain text to the server.

2. Secure (SSL) Transaction: the browser knows it is using a secure connection for this form. The browser converts "1234-5678-1234-5678" into a seemingly random collection of characters like "e$$%0lj*&*(#foij" and sends it to the server. The server receives "e$$%0lj*&*(#foij" and converts it back into "1234-5678-1234-5678".

The important thing to notice here is that, in theory, when the browser encrypts the form no one can read the contents and obtain your personal details.

In addition to providing privacy, SSL was designed to answer a related question: how do you know you are really communicating with the Web site you intended? SSL also guarentees you are talking to the web site you intend to by using public and private key technology through the use of certificates.

In order to encrypt data, SSL and TLS frequently use symetric key algorithms know as block ciphers (e.g. DES, AES, ...) in Cipher Block Chaining Mode (CBC) or they can also use stream ciphers such as RC4.

CBC-PAD in Secured Channels

When encrypting a message MES in TLS/SSL using block ciphers in CBC mode, a Message Authentication Code (MAC) of MES is first computed. Then, when using a block cipher in CBC mode, the concatenated string MES|MAC is padded with padding PAD such that MES|MAC|PAD|LEN is of length a mutiple of the block cipher input size (typically 8 bytes). LEN represents the length of PAD in bytes. The message MES|MAC|PAD|LEN is then cut into blocks of length the input size of the block cipher and encrypted in CBC mode.

When the encrypted message is received, it is first decrypted back into MES|MAC|PAD|LEN. Then the validity of the padding is verified e.g. if LEN equals 4, the padding will be valid if PAD equals "4 4 4 4". If the padding is found not to be valid then a padding error is generated. Otherwise the MAC value is then checked. If it is not valid then a MAC error is generated.

In TLS/SSL, such errors are fatal and abort the session but we can restart a new session. The client and the server will then negotiate a new symmetric key. Note that in SSL/TLS, errors are sent through the same channel as messages and are therefore MACed, padded and then encrypted before being sent.

In 2002, Vaudenay [10] presented an attack which enables the decryption of blocks provided that error messages are available (as a side channel attack) and sessions do not abort. This is not the case with TLS/SSL. We can solve the latter problem in the case where a TLS/SSL session includes a/several critical plaintext block which is/are always the same (e.g. a password). The former problem of availability of error messages (encrypted in TLS/SSL) is solved by performing a timing attack i.e. by measuring the taken for error messages to come back from the server. It is then possible to perform the attack over several sessions of TLS/SSL.

The attack presented by Vaudenay [10] works basically as follows:

  • The attacker intercepts the block that he/she wants to decrypt (e.g. password).
  • The attacker then sends a block that he/she has constructed from the intercepted block to the server.
  • The server will then send an error message to the attacker. This message will either be a padding error message or a MAC error message.

  • The error message reveived by the attacker tells him/her whether he/she has made a good guess at a particular byte in the block. The attacker works its way from the most significant byte to the least significant byte in the block.

    Timing Attack

    We have performed some timing measures in a setup where an attacker is situated "not too far" from the server and we have obtained the distributions shown in the graph below which reprensent the time taken for a padding error message and the time taken by a MAC error message.

    Figure 1

    The graph shows that the two distributions are seperable. In LASEC at EPFL, Pascal Junod has been doing research on sequential distinguishers (see [7]). By using the theory of hypothesis testing with sequential distinguishers, we obtained a method to seperate the two distributions by asking the same question to the server over several sessions before deciding whether a padding or a MAC error occured. The question is asked while the average of the time taken before receiving the error message lies within a given interval. Once this average falls out of the interval, a decision whether a padding or MAC error has occured is taken. If the average is greater than the upper bound of the decision interval, then we conclude that we received a MAC error.

    Dictionnary and Brute Force

    Two types of attacks can be performed:
  • a brute force attack where all characters to be found are in an alphabet Z of size 64 or 256 for example and each element of the alphabet is used to guess bytes of the block we want to decrypt.
  • a dictionnary attack where words of a dictionnary are used in order to guess a password. The dictionnary is ordered in decreasing probablity of the character guessed in the password.
  • We have used the data collected to draw Figure 1 in order to compute the upper and lower bound of our decision interval and complexity value C for a given success probability for both brute force and dictionnary attacks. These values can be seen in the tables below where p represents the probability of success of the attack and C is the complexity i.e. the number of sessions needed to perform the attack.

    Dictionnary Attack
    p 0.5 0.9
    C 166 261
    Alphabet Size = 64
    p 0.5 0.9
    C 1140 1938
    Alphabet Size = 256
    p 0.5 0.9
    C 4239 7397

    The Attack in Practice

    Martin Vuagnoux, a student of EPFL doing a semester project in LASEC, has performed the attack and validated the results presented in the previous sections by intercepting passwords sent to an IMAP REV 4 server when checking emails with an Outlook Express 6.x client using a secure connection [5].

    Outlook sends the login and pasword to the IMAP server using the following format:

    XXXX LOGIN "username" "password"<13><10><MAC><PAD><LEN>

    Here XXXX are four random digits which are incremented each time Outlook connects to the server and <13><10> correspond to ASCII characters carriage return and new line respectively.

    Interestingly, Outlook is setup by default to connect to the email server every 5 minutes. Also, it requires an authentification for each folder created on the IMAP user account. Therefore, this gives a bunch of free sessions every 5 minutes.

    The attack is a man-in-the-middle type attack where connections to the server from the client are redirected to the attackers machine using DNS spoofing [11] where the attacker intercepts the authentication message and attempts to decrypt it by using the multisession version of the CBC-PAD attack.


    Using a multisession version of Vaudenay's CBC-PAD attack [10], it is possible to attack TLS/SSL in the case when the message that is being encrypted remains the same during each session. This is the case, for example, when an email client connects to an IMAP server.

    One problem is that error messages in TLS/SSL are encrypted. However, using a timing attack that looks at timings between error messages and a statistical method based on sequential distinguishers, it is possible to efficiently decrypt a password for an IMAP account in less than an hour. In doing so, we have also shown that the latest version of openssl [9] is not secure when used with block ciphers in CBC mode.

    TLS/SSL are used in other secure Internet applications such as e-banking and e-commerce meaning that an attacker could potentially intercept banking transactions, credit card numbers, etc.

    In the case of openssl [9], a new version has already been released (0.9.7a) with a countermeasure against our attack.

    Other links

    Full report

    Omen: tool developed to automatically carry out password recovery when an email client connects to an IMAP server over a TLS channel.


    [1] T. Dierks and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, standard tracks, the Internet Society, 1999

    [2] FIPS 46-3, "Data Encryption Standard (DES)", U.S. Department of Commerce - National Institute of Standards and Technology, Federal Information Processing Standard Publication 46-3, 1999

    [3] FIPS 81, "DES Modes of Operation", U.S. Department of Commerce - National Bureau of Standards, National Technical Information Service, Springfield, Virginia, Federal Information Processing Standards 81, 1999

    [4] M. Crispin, "Internet Message Access Control" - Version 4, RFC 1730, standard tracks, University of Washington, 1994

    [5] C. Newman, "Using TLS with IMAP, POP3 and ACAP", RFC 2595, standard tracks, the Internet Society, 1999

    [6] University of Washington, IMAP 2002 rc3, http://www.washington.edi/imap/, 2002

    [7] P. Junod, "On the Optimality of Linear, Differential and Sequential Distinguishers", To appear in Advances of Cryptology - EUROCRYPT'03, LNCS, Springler-Verlag, 2003

    [8] P. Kocher, "Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS and other Systems", In Advances of Cryptology - CRYPTO'96, Santa Barbara, California, U.S.A., Lecture Notes in Computer Science 1109, pp. 104-113, Springler Verlag, 1996

    [9] Bodo Möller, "Security of CBC Ciphersuites in SSL/TLS: Problems and Countermeasures", http://www.openssl.org/~bodo/tls-cbc.txt,2002

    [10] S. Vaudenay, "Security Flaws Induced by CBC Padding - Applications to SSL, IPSEC, WTLS, ...", In Advances in Cryptology - EUROCRYPT'02, Amsterdam, Netherland, LNCS 2332, pp. 534-545, Springler Verlag, 2002

    [11] Marco Ricca, "DNS Spoofing", Ecole Polytechnique Federale de Lausanne, LASEC, Semester Project, 2002

    © 2009, EPFL