28.08.2007
A Case of SSL MITM attack - Protecting The Trust Relationship - Part 1: TLS In Action

 Carbonwind.net and the author do not condone or approve the illegal use of this tutorial in any way.

Protecting data while is traversing insecure networks is a must these days.
The road warriors need access to their emails, documents, information, data from anywhere.
But what is the definition of this "anywhere" ?
Let's create a real world scenario.

Suppose that we are miles away from our HQ in a hotel room or in an Internet Café or something similar and we need to read our emails.
OWA(Outlook Web Access) seems a great choice. It is protected using SSL/TLS.
At a first glance we have two options: use our corporate laptop or a local PC(say, a computer from an Internet café).
The difference: the first one is a managed private computer and the other one is a shared public PC.
So let's see what's happening. Our user JohnVPN, for some reasons, chooses to use a shared public PC from, say an Internet café where he went to kill his time and play a couple of onlines games, socialize?
Our attacker is just waiting for people like John. He is preparing a SSL MITM attack in order to steal John's credentials. He did manage to compromise the Internet café network, which can be done very easy. After all, the owner did his job, installed a firewall, some AV/Spyware on his PCs, but he cannot cope with a skillful attacker. The attacker now directs traffic from computers to the local gateway through, say, a local PC where he has installed his malicious software. He can do that very simple using ARP Spoofing. In Figure1 we have the network diagram which describes the traffic paths.

Figure1: Network Diagram

So now all the traffic from JohnVPN to the gateway passes through the attacker PC. No big deal we might say since the OWA traffic is encrypted. There is no big deal if only the attacker resumes to passive eavesdropping. If he decides to mount a SSL MITM attack then JohnVPN will soon have problems.
Why the attack might succeed and so why we must avoid using public, shared PCs to read our emails ?
Let’s first analyze a normal OWA connection from a managed private PC.
For this test, for protecting the Exchange 2003 Server I have used ISA 2006 Firewall. On ISA, OWA is published using SSL bridging, FBA on ISA(ISA is a domain member, so ISA validates credentials using Windows(Active directory)) and if authentication succeeds it will use basic authentication delegation for forwarding the basic credentials to the Exchange Server. In this way no packets will reach the Exchange Server if authentication on ISA fails.
The default ISA HTML forms will be used.
My private CA, named DCMain, is an Enterprise CA(Windows 2003) and sits on my DC. Nothing special since I’m in my test lab. You might like to read:
Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure
Our JohnVPN Our JohnVPN user is away from his office and using his laptop he wants to read his emails from his hotel room. Since this laptop is a managed device, he should be protected against worms, keyloggers and he is confident that he is using, say, Genuine Windows. Also proper antivirus, spyware and firewalls are configured on his notebook. Already a trust relationship was build.
The company for which John works is using a private CA for issuing certificates. The OWA web server certificate is from this CA. Obviuosly JohnVPN’s laptop has installed on it the CA certificate and he is confident that no one has altered his Trusted Root CAs where the private CA certificate is installed or edited hisIE7 settings.

Let's see what's happening.

Figure2: A normal OWA login screen with no errors in IE7

Let's analyze the web server certificate:

Figure3: Viewing the web server certificate

Figure4: The web server certificate

Since we went to https://owa.carbonwind.net/exchange the common name on the certificate must be owa.carbonwind.net otherwise IE will give us some warnings.

Figure5: The web server's certificate details

Figure6: The web server's public key

Figure7: The web server's enhanced key usage

The key of the server can be used for signing and Key Encipherment (a0) (not for Data Encipherment (f0)).

The web server certificate is configured with one or more purposes in EKU extensions that correlate to the certificate use. In our case, the certificate used for the authentication of the web server must be configured with the Server Authentication purpose. The CA certificate is in the Trusted Root Certifications Authorities Store:

The web server certificate is configured with one or more purposes in EKU extensions that correlate to the certificate use. In our case, the certificate used for the authentication of the web server must be configured with the Server Authentication purpose.
The CA certificate is in the Trusted Root Certifications Authorities Store:

Figure9: CA Cert from Trusted Root Certifications Authorities Store

The Certification Path from the web server certificate:

 
Figure10: The Certification Path from the web server certificate 

RFC2246(TLSv1.0) and RFC4346(TLSv1.1) states that:
“If the server is authenticated, its certificate message must provide a valid certificate chain leading to an acceptable certificate authority“.

So at this point JohnVPN can say that the remote server is really our Exchange server(actually is the ISA server) and he can proceed with his login.

 
Figure11: JohnVPN has logged on 

As we have seen there are some details:

- During the SSL/TLS session the browser will “request” from the web server its certificate in order to authenticate it

- The common name on the certificate must match the name of the server from our URL: if we connect by https://owa.carbonwind.net then the CN on the certificate must be owa.carbonwind.net

- The web server’s certificate must be signed by a trusted CA: the CA certificate must be in the Trusted Root CAs Store, otherwise the client cannot really tell if the web server is who is pretending to be, since it cannot verify who has signed its certificate. This one is the most critical detail. Other details like the CN, OU,O…as we will see later can be forged. If you log on from a managed, private computer then it is very unlikely that you actually have a forged CA certificate on your computer

- The public key of the web server from its certificate. It cannot be forged because it must have a corresponding private key. This is how public encryption works: I give you my public key and then you send me “something” encrypted with my public key. This “something” can only be decrypted with my private key. The CA signes my certificate with its own private key, in this way enabling you to verify that the public key that I have sent you is really my public key. Since you have on your computer the CA certificate(which was obtain from a trusted place), thus the CA public key, you can verify my certificate authenticity and so trust my public key. Also, if I sign something with my private key and send it to you, you can check by using my public key if I really sent you that something. If you have a good memory, maybe you can remember my public key letter by letter and add an extra layer of verification. Very unlikely though.

- The “Certification Path” leads you to the CA as you can see from Figure10.

- The certificate must not be expired or revoked

This was what actually what an end user sees. But what’s happening on the wire?
A quick search through RFC2246(TLSv1.0) and RFC4346(TLSv1.1) for directions :
   “   TLS supports three authentication modes: authentication of both
   parties, server authentication with an unauthenticated client, and
   total anonymity. Whenever the server is authenticated, the channel is
   secure against man-in-the-middle attacks, but completely anonymous
   sessions are inherently vulnerable to such attacks.  Anonymous
   servers cannot authenticate clients. If the server is authenticated,
   its certificate message must provide a valid certificate chain
   leading to an acceptable certificate authority.  Similarly,
   authenticated clients must supply an acceptable certificate to the
   server. Each party is responsible for verifying that the other's
   certificate is valid and has not expired or been revoked.”
-----------------------------------------------------------------------------------------------
The TLS Handshake Protocol involves the following steps:
     - Exchange hello messages to agree on algorithms, exchange random
       values, and check for session resumption.
     - Exchange the necessary cryptographic parameters to allow the
       client and server to agree on a premaster secret.
     - Exchange certificates and cryptographic information to allow the
       client and server to authenticate themselves.
     - Generate a master secret from the premaster secret and exchanged
       random values.
     - Provide security parameters to the record layer.
     - Allow the client and server to verify that their peer has
       calculated the same security parameters and that the handshake
       occurred without tampering by an attacker.”
-----------------------------------------------------------------------------------------------
“      Client                                               Server

      ClientHello                  -------->
                                                      ServerHello
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                   <--------      ServerHelloDone
      Certificate*
      ClientKeyExchange
      CertificateVerify*
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished
      ApplicationData            <------->     Application Data
             Fig. 1 - Message flow for a full handshake
   * Indicates optional or situation-dependent messages that are not
   always sent. “

Now let’s visualize all these with Wireshark:
The Client Hello message:

Figure12: The Client Hello message

The proposed client Cipher Suites(a list of cryptographic parameters that the client supports):

Figure13: The proposed client list of Cipher Suites 

The “Server Hello” message which includes:

Figure14: the Server Hello message

- the Certificate which contains the server certificate, thus the server will be authenticated by the client

- the selected Cipher Suite. But what does TLS_RSA_WITH_RC4_128_MD5 means?

It means that we are using RSA key exchange and authentication(from RFC2246(TLSv1.0) , we are using TLS 1.0):
“With RSA, key exchange and server authentication are combined. The public key may be either contained in the server's certificate or may be a temporary RSA key sent in a server key exchange message.
After verifying the server's certificate, the client encrypts a pre_master_secret with the server's public key. By successfully decoding the pre_master_secret and producing a correct finished message, the server demonstrates that it knows the private key corresponding to the server certificate.
pre_master_secret - This random value is generated by the client and it is used to generate the master secret
master secret - Secure secret data used for generating encryption keys, MAC secrets, and IVs.
Message Authentication Code (MAC) - A Message Authentication Code is a one-way hash computed from a message and some secret data. It is difficult to forge without knowing the secret data. Its purpose is to detect if the message has been altered.
MD5 - Message-Digest algorithm 5 is a secure hashing function that converts an arbitrarily long data stream into a digest of fixed size (16 bytes) 
SHA - The Secure Hash Algorithm is defined in FIPS PUB 180-1. It produces a 20-byte output. Note that all references to SHA actually use the modified SHA-1 algorithm.
RSA - A very widely used public-key algorithm that can be used for either encryption or digital signing.
- RC4 as the symetric encryption algorithm to protect data(confidentiality).
- TLS uses MD5 as the hash function. The connection is reliable. Message transport includes a message integrity check using a keyed MAC. Secure hash functions (e.g., SHA, MD5, etc.) are used for MAC computations.For example we can create a hash of the data and keyed this hash with a key known only by the two peers(this is a shared secret). In this way we can assure data integrity(proof that the data was not modified in transit) and data authentication(proof that the data was sent by the legitimate source) per packet. This is called HMAC(Hashed Message Authentication Code).”

As we can see from Figure14 the Server Hello does not contain the Server Key Exchange field because the server certificate has a public key that can be used for encryption. Also there is no Certificate request meaning that the client will not provide any certificates to the sever thus it will not be authenticated by the server. So we can resume that we are using RSA for key exchange and authentication, RC4 for protecting the data confidentiality, MD5 for data integrity and only the server is authenticated.
The Server Hello Done message is sent by the server to indicate the end of the Server Hello and associated messages. After sending this message the server will wait for a client response.

And here it comes the client answer:

Figure15: Client response following the Server Hello message 

The client response contains a “Client Key Exchange”. Because RSA is being used for key agreement and authentication, the client generates a 48-byte premaster secret, encrypts it using the public key from the server's certificate and sends the result in an encrypted premaster secret message.
No Certificate or Certificate Verify messages since the client does not send any certificate(the client certificate must has signing capabilities for the Certificate Verify message).
The Change Cipher Spec message is sent by the client to notify the server that subsequent records will be protected under the newly negotiated CipherSpec and keys before the verifying Finished message is sent.
The client then immediately sends the Finished message under the protection of the new algorithms, keys, and secrets. In our Figure15 it is the Encrypted Handshake Message.
Now the server receive the “Finished” message from the client, it valides it and sends its own Change Cipher Spec and its Finished(the Encrypted Handshake Message) message protected with the newly negotiated CipherSpec and keys.

Figure16: The server response following the client Change Cipher Spec Finished messages

If the client receives and validates the server Finished message, application data traffic might start to flow.

Figure17: Application data protected by TLS

In our case the application protocol is HTTP.
Now let’s proceed and log on our JohnVPN user from a public computer while the web server certificate was issued by our private CA. JohnVPN doing so, from the Internet café, from where he thought he can combine pleasure with business, has no idea if the computer contains keyloggers, worms, viruses, an original OS or even if the antivirus installed on it is the “real deal”. There is no trust relationship, au contraire, there is one based on suspicions.

Figure18: Big IE error 

Wow! 
IE blocked us the access to the OWA site.
So let’s click to continue and then view the certificate.

Figure19: The certificate cannot be verified up to a trusted CA

Figure20: The certificate details 

Figure21: The certification path 

Everything appears to be OK except the Certification Path. We can see that the CA is missing. The RFC2246(TLSv1.0) states about the server Certificate message:
“This is a sequence (chain) of X.509v3 certificates. The sender's certificate must come first in the list. Each following certificate must directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate which specifies the root certificate authority may optionally be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case.”
So our server(ISA) did not send to JohnVPN the CA certificate since there is no real need for it. He must have on his computer this CA in order to prove that the certificate is valid. 
Looking more carefully at our certificate we can see an Authority Information Access field.

Figure22: The certification path Authority Information Access field

Since we are on a public computer and our CA is private, this computer has no clue about our CA.
So it’s trying to download the CA’s certificate as we can see from Figure23.

Figure23: Trying to download the CA certificate

But we did not publish this information on our ISA, so its request will be denied(obviously a DNS entry must exist for dcmain.carbonwind.net).
Now let’s go and publish the CA certificate(I have used another web server where I manually put the CA certificate and the CRL) with ISA and let’s try one more time.
The same errors will come up in IE. However as you can see from Figure24 the CA certificate was downloaded.

Figure24: Downloading the CA certificate 

Now let’s look again at the “Certification Path”:

Figure25: The new  “Certification Path”

And now as we can see the correct certificate chains appears. But there is a red X on the CA certificate(the CA is not trusted). Let’s click on “View Certificate”:

 
Figure26: The CA certificate 

If we proceed and install this certificate in our Trusted Root CA store then IE will not give us any errors just like when JohnVPN logged from its private laptop.
So as you can see when JohnVPN logs on from a public computer the trust relationship is broken. Note that this trust relationship is only one-way, we authenticate the server but the server does not authenticate us because we do not present it any client certificate. Also we cannot really tell if the server certificate is real when JohnVPN used the public PC unless we remember the public key of the server, unlikely though.