Transport Layer Security (TLS)
1. Prototype client / server application
We implemented the following TLS client / server programs using GnuTLS libraries.
Simple TLS client & server using anonymous authentication
In this the TLS client doesn’t provide any authentication. This means no external certificates or
passwords are required to setup the connection. Although, the data integrity and privacy is
protected in this application but it is vulnerable to man in the middle attack. The TLS server is
a nothing but a simple echo server.
Simple TLS client & server with X.509 certificate support
In this application the TLS server is a simple echo server which supports X.509 authentication,
using the RSA cipher suites.
Additional functionality incorporated into the programs
We have used the sample programs provided by GnuTLS, but the programs lacked a several
things which we had to implement by ourselves and incorporate those into the programs.
* TCP connection code
We incorporated the function for TCP connection between the client and server using sockets.
*Certificates & private key
We utilized the tool ‘certtool’ to generate self signed certificate, server certificate and client
and server private key.
* Session information
We included a function in the client program which outputs the session information on the
console after a successful handshake.
* Error check
For debugging, in case there is failure in trusting the CA certificate, we included the return
code so that it could display the appropriate integer value.
1
Spring 2006
Transport Layer Security (TLS)
Setup – Installations & Configurations
We used the following libraries for implementing the gnuTLS programs. These can be
obtained from http://www.gnu.org/software/gnutls/download.html and installed referring the
readme file. The operating system used for implementation is Fedora Core 5 distribution.
•
gnutls -1.2.9
•
libgcrypt-1.2.2
•
libtasn1-0.3.2
Create Certificates & private keys
* To create a self signed certificate, use the command:
]# certtool --generate-privkey --outfile root-key.pem
]# certtool --generate-self-signed --load-privkey root-key.pem --outfile root.pem
The root-key.pem is the private key of CA and root.pem is the certificate of our CA which will
be the trusted certificate. We used this CA certificate to sign server and client certificates.
* To create a private key, use the command
]# certtool --generate-privkey --outfile server-key.pem
* To create a certificate request, use the command
]# certtool --generate-request --load-privkey server-key.pem --outfile request2.pem
* To generate a certificate using the previous request, use the command
]# certtool --generate-certificate --load-request request2.pem --outfile server.pem \ --load-cacertificate root.pem --load-ca-privkey root-key.pem
2
Spring 2006
Transport Layer Security (TLS)
2. Analysis of TLS using Apache and mod ssl
APACHE HTTP SERVER TLS protocol has been evaluated and tested using APACHE HTTP
SERVER. The server has been configured on UBUNTU(5.01) platform.
The following steps were involved in configuring the apache2 server
1. Installing apache2 server and ssl cert
apt-get install apache2
apache2-ssl-certificate
Note the certificate created is valid only for a month. To make it valid for a year, we
use the following command
/usr/sbin/apache2-ssl-certificate -days 365
2. Now, enable ssl
a2enmod ssl
3. Configure ssl
cp /etc/apache2/sites-available/default /etc/apache2/sites-available/ssl
ln -s /etc/apache2/sites-available/ssl /etc/apache2/sites-enabled/ssl
4. Now edit sites-enabled file”/etc/apache2/sites-enabled/ssl” so that HTTPS will be
configured on port 443
NameVirtualHost *:443
<VirtualHost *:443>
5. Edit “/etc/apache2/sites-enabled/default” so that HTTP will be configured on port 80
NameVirtualHost *:80
<VirtualHost *:80>
6. Edit ports.conf
add Listen 443
7. Edit the file /etc/apache2/sites-available/ssl
Insert
SSLEngine On
SSLCertificateFile /etc/apache2/ssl/apache.pem
The snapshot of Secure browser
3
Spring 2006
Transport Layer Security (TLS)
The snapshot of ethereal capture
4
Spring 2006
Transport Layer Security (TLS)
3. Analysis of Man in the middle attack over TLS using Proxy Sniffer tool
The architecture includes features such as:
 Universal HTTP/S recorder
All data exchanged between the web browser and the web server can be recorded
 Proxy Sniffer Server
This acts like “man in the middle” which sniffs all the data between the client and the sever.
 Web browser
This acts like a client, which contacts destination server through the proxy server.
Demonstration of man in the middle
In the demonstration here, the Opera browser has been used as a client, which contacts
https://www.wellsfargo.com, which is a secured server.
The demonstration was tested on three protocols SSLV3, TLS 1.0,TLS 1.1
Following are the steps involved when the opera browser contacts https://www.wellsfargo.com
1. The client sends a request to “Wells Fargo” which goes through the proxy sniffer
server.
2. Wells Fargo sends a reply with its trusted certificate to the proxy sniffer server which in
turn sends a reply to the client.
3. Proxy sniffer server detects the certificate from the server and signs the certificate with
its own certificate authority.
5
Spring 2006
Transport Layer Security (TLS)
4. The client gets a warning saying that “the certificate is not signed by a trusted
authority” for SSLV3 and TLS1.0 which is shown below.
6
Spring 2006
Transport Layer Security (TLS)
5. TLS1.1 over HTTPS:
TLS 1.1 doesn’t allow us to visit the website which is susceptible to man in the middle attack.
7
Spring 2006
Transport Layer Security (TLS)
4. Improvement for TLS
Transport Layer Security Protocol provides authentication and integrity for communication
network through encryption. Though this protocol is being a successor to SSL, there are
security issues that are encountered by TLS while providing secure channel between the client
and the server. The purpose of TLE is to secure and provide protection to the network web
Traffic. The issues covered in this paper are as follows:
1) Time consumption during the connection establishment using the Handshake messages.
2) The clients employing TLS face some problems during session resumption .The servers
store information (heavily loaded servers) of session for a relatively short period of time
before evicting it from the server’s cache.
3) Web servers tend to use only the server authentication and not the client authentication
leading to the possibility of man in the middle attack.
4) Time consuming and expensive RSA private key decryption leads to the degradation of the
server’s performance.
5) When the web traffic goes beyond the capacity, the load on the server increases and there
may be a possibility of the server being crashed or Denial of service (DOS) attacks.
6) TLS can be a problem in Bandwidth constrained environment where the Latency is high
such as wireless environment.
The possible solutions to these problems are addressed by employing certain techniques, which
are covered in the following sections.
[ I ] Time consumption during the Handshake Messages:
Resume Handshake mechanism: Client resumes the session using the same session ID that
was previously negotiated in the TLS session between the client and the server. This not only
reduces the network Traffic but also computation on both the ends. This session is resumed
only if the old session is present at the server’s cache. The problem at the server’s side is that
the server allows the session to be stored only for the certain period of time after that the
session is expired, aborting the session and the client has to perform the full handshake
procedure in order to communicate back to the server. E.g. Amazon’s server expires the
session every 2mins. This may cause the client to perform the full handshake even it wanted to
resume the session that was previously communicated. Whereas the clients rarely connects to
8
Spring 2006
Transport Layer Security (TLS)
large no of TLS servers and hence can maintain the information in its cache for a longer period
of time, for example Mozilla browser stores the information of the sessions in its cache for max
24hrs (RFC –2246).
The solution as proposed by HOVAV SHACHAM, DAN BONEH, and ERIC RESCORLA is
the use of two mechanisms for caching the handshake information on the TLS clients. The first
mechanism is “Fast Track Handshake”, and the second is “Client side caching”.
Fast Track Mechanism: In this mechanism the server’s parameters and the other negotiated
parameters are cached at the client side during the ordinary handshake. It is then not required to
communicate these parameters for the subsequent handshakes. This mechanism reduces the
network traffic, bandwidth and the round trip times(Eric Rescorla,2004). The ordinary
handshake mechanism is shown in the diagram below.
The TLS handshake mechanism follows three objectives 1) to negotiate the session’s
parameters 2) to authenticate the server and client (optional) 3) Sharing cryptographic secret.
9
Spring 2006
Transport Layer Security (TLS)
The server identifies a particular connection using the session ID and hence the client and the
server can resume the session using this ID.
The Fast Track mechanism is specifically used for the short-lived TLS sessions where there is
no resumption done. In this case either the 2 entities have never communicated or the client
and server have communicated at some point but the session has expired in between. There
was a situation once that the Amazon clients placed multiple orders in the 2min window of the
server’s cache. The efficiency of the Full TLS handshake is improved using this fast track
mechanism. The Fast Track clients maintain a cache of long-lived server information, such as
the server certificate and the long lived negotiated information that is the preferred cipher suite.
The process to store the long-lived session parameters in the client’s cache reduces the
bandwidth. The initial messages used by the server to communicate with the client are not
included in the Fast Track Handshake. Hence consists of only 3 flows instead of 4 flows.
Network that has high latency, saving flow can help in saving time, but does not provide any
computational speed up. The use of fast track, along with the particular fast-track parameters, is
negotiated between clients and servers by means of TLS extensions [Blake-Wilson et al. 2003].
These Handshake parameters are called the determining parameters, which the client collects
during the process of ordinary TLS handshake. The client has to know the group modulus and
generator relative to which the DH exchange will operate (Eric Rescorla, 2004). The client
sends the cache parameters, which are stored using the EDH key along with the client Key
exchange message. But if the server is employing temporary RSA key exchange then the client
would cache the required parameters briefly and hence the fast track does not support the RSA
key authentication (Eric Rescorla, 2004).
The long-lived parameters that the client caches normally do not change except in situation
where either the client or the server changes their configuration.
Handshake Parameters:
The handshake parameters are defined into two categories: 1) the parameters that give server’s
configuration and 2) those, which depend on the interaction of the server’s configuration with
the client’s. These parameters do not change frequently.
In the first category, we include:
The server’s certificate chain and also;

The server’s Diffie-Hellman group
10
Spring 2006
Transport Layer Security (TLS)

Whether client authentication is required; if so

Acceptable client certificate types; and

Acceptable certificate authorities.
In the second category, we include parameters such as:

The preferred client–server cipher suite; and

The preferred client–server compression method (Eric Rescorla, 2004).
The Fast Track Handshake Messages are shown below:
The above figure shows, the clientHelloFT message includes the fast-track hash function with
the hash of the determining parameters. In this the “Server Certificate”, “Certificate request”,
“Server Hello done” is not included and hence requires only 3 flows instead of 4 flows. Once
the client validates the server’s certificate chain, its does not revalidate during the course of the
handshake .The only requirement is that the server has to verify the SHA-1 hash of the
determining parameters. The server uses this information from the client Hello message and its
own configuration to form its own version of the determining parameters for the connection.
Both the versions should match for the connection to be successful. These cryptographic
hashes are used to exchange the determining parameter. To provide additional security the
Handshake MAC is included in the finished message. The client certificate is also included in
the finished message MAC and hence it is not exposed to tampering. This mechanism thus
saves bandwidth, flow, and time and improves the network performance in terms of network
traffic and round trips. We discuss the effect of Fast track on CPU load for both the client and
the server.
The performance details are explained in the following tables, which give the number of bytes
sent for the key exchange with 2 different cipher suites. It is observed that without the client
authentication there is more saving.
11
Spring 2006
Transport Layer Security (TLS)
The first cipher suite, called “TLS RSA WITH 3DES EDE CBC SHA” in RFC 2246 (and
called “DES-CBC3-SHA” in OpenSSL), uses RSA for key exchange. It does not require a
ServerKeyExchange message to be sent. The second cipher suite, “TLS DHE RSAWITH
3DES EDE CBC SHA” (“EDH-RSA-DES-CBC3-SHA” in OpenSSL), employs EDH for key
exchange, with RSA authentication. A handshake using this cipher suite requires the server to
send a ServerKeyExchange message. (ERIC RESCORLA, 2004).
The client stores the determining parameters only after verifying the authenticity of the client;
these parameters come from the ordinary handshake and hence not open to tampering. But if
the parameters do not match then the communication is incomprehensible.
We have figured out few flaws in this mechanism that even tough 3 messages are not required;
they do not involve any significant computational intensive operations. RSA key exchange is
the most important key exchange method used for the TLS handshake but the Fast TLS
handshake does not support it.
12
Spring 2006
Transport Layer Security (TLS)
Client Side Session Caching: This is another mechanism that is used to reduce the load on
the servers. In order to reduce the overload of the session caching, the client is forced to store
the session cache data for the server and provide the server with it when attempting to resume.
The cache data sent to the client is encrypted to protect from the man in the middle attack using
a symmetric cipher under the fixed server key called the enc-key. But then this is also not safe
since the attacker can get deduce the relations between the cache data in different tokens. The
integrity is not guaranteed so the server should use MAC with the fixed server key called mackey. A token is formed using the enc-key and the mac-key.
Token = enc key [cache data || mac]
Mac= mac-key [cache data]
The enc-key and the mac-key are derived from the server master key. All the information that
the server wants to retain during the session is retained inside the authentication token. For this
the master key is shared. During the resumption of the session the client is expected to transfer
the token along with the guaranteed session ID.
The problem encountered here was that the session ID is 32 bytes and the master secret is 48
bytes. The master secret cannot be fitted in the session ID. Another problem is that the server
provides the session ID in the server Hello message, which is transmitted before it knows the
master secret.
To overcome this problem the normal zero length session ID is sent in the server hello message
and then the extended session ID message is sent containing the authentication token is sent
immediately before the change cipher spec message. During the connection establishment the
client signals the server about its capability of CSSC using the client side cache capable
extension in the client Hello. If the server wants to request it sends a client side cache capable
request extension. For the resumption of the session the client sends the authentication token,
if less than 256 bytes, it is placed in the session ID. Though the session ID of the client Hello
has 32 bytes, the length field can go up-to 255 bytes but not the client certificate. The
handshake is described as below.
13
Spring 2006
Transport Layer Security (TLS)
This mechanism faces problem of cache invalidation. The session can become invalid due to
expiration, improper closer and error. Authentication tokens are self-authenticating and hence
it is difficult to invalidate the session easily, if an error is found. The only way to invalidate the
session is to have a blacklist consisting of session that have been invalidated but may not have
been expired.
Improving the TLS performance by Re-balancing:
There are situations where numerous clients send simultaneous requests flooding the
server due to which the server crashes or may result in Denial of Service attacks. These attacks
cause the server to deny service to legitimate clients. The server consumes a lot of CPU
processing time to perform the costly computation like decrypting key.
The solution to this problem is load distribution where the client performs more work and the
server performs commensurately less work, hence the workload is lessened. A mechanism
called Client Aided RSA can speed up the processing by the factor of 11 to 19 compared to the
server aided RSA depending on the RSA key size. The mechanism works as shown in the TLS
handshake diagram.
14
Spring 2006
Transport Layer Security (TLS)

The client sends the Hello message along with the cipher suites and a random number,
rc.

The server sends the server Hello message along with its public key certificate and rs.

It then chooses the 48 byte premaster secret, x. Using the premaster secret it computes
the shared master secret, K by inputting the values x,rc,rs into the hash function, f.

Encrypts x using the server’s public key (RSA) and attaches the cipher text to the client
key exchange message and sent to the server.

The server decrypts the premaster secret x, using its private RSA key and uses it to
compute the shared master secret as f(x,rc,rs).

Sends the client, server finished message that includes a keyed hash of all the
handshake messages.
This mechanism is Time consuming, expensive server’s RSA private key decryption.
Hardware accelerators are used for the speeding up the servers. Critical web servers often
employ the expensive cryptographic hardware to speed up the decryption process, enabling
them to handle more simultaneous handshake requests and connections.
The following diagram shows the decryption of the key that involves much of computational
process at the server side.
15
Spring 2006
Transport Layer Security (TLS)
Here the server has to compute y in order to get the master secret using the Chinese Remainder
Theorem.
One solution to reduce the computational load on the server is to make the value of d small but
then this makes RSA insecure. The other option is that the server can encrypt the session key
thus shifting the decryption burden to the client. But for this the server has to authenticate the
client and if the server cannot verify it will lead to DOS attacks. The server needs to verify all
the certificate chain. Therefore, the Client Aided RSA is used. In this the clients have to do the
work of RSA decryption. The following handshake shows how this can be achieved.
In this case the client computes the vector z and using the value of z the server easily and
quickly computes the master secret. This computational process reduces the server’s time since
the client is already resolving all the important parameters.
16
Spring 2006
Transport Layer Security (TLS)
5. Testing
Test Case No1: Verification of certificates and keys
Description: For verification of certificates and keys we used a tool named ‘verify’ provided
by openSSL.
Test Case No2: Checking return code CA files function
Description: We implemented the logic for debugging purpose. We checked the value is
returned by the ‘’ function.
Results: From our observations, whenever the client or the server program could not trust the
self signed certificate ‘root.pem’, it gave the error ‘unable to verify the certificate’.
Test Case No3: Port Number checking
Description: In this we used different port number values for client and server.
Results: The client program exited by created a socket and the server didn’t receive any
request as it was listening on a different port.
Test Case No4: Session information
Description: In this we had implemented a function that prints session information on the
client side in case the handshake was successful. We implemented this in TLS client for x509
authentication.
Results: We successfully observed the following information at our client side.
17
Spring 2006
Transport Layer Security (TLS)
Test Case No5:
Description: Response time of SSL v3 and TLS over HTTPS using Opera, Internet Explorer
and Mozilla. For these tests we used a tool ‘Proxy Sniffer’.
Results:
2000
1500
1000
Response time in ms
500
0
TLS
SSLV3/SSLV2
700
600
500
400
Response time with
Opera and mozilla
browser in ms
300
200
100
0
TLS
SSL V3
18
Spring 2006
Transport Layer Security (TLS)
Conclusion:
•
SSL / TLS is the most widely deployed security protocol, standard
•
Easy to implement, deploy and use
•
widely available; Flexible, supports many scenarios
•
Mature cryptographic design
Reference
[1] TLS v1.0 RFC http://www.ietf.org/rfc/rfc2246.txt
[2] HTTP over TLS RFC http://www.ietf.org/rfc/rfc2818.txt
[3] Open Source Library http://www.gnu.org/software/gnutls/
[4] SSL and TLS, Eric Rescorla, Addison-Wesley
[5] http://www.tc.umn.edu/%7Ebrams006/selfsign_ubuntu.html
[6] http://www.ubuntuforums.org/archive/index.php/t-4466.html
[7] Client-Side Caching for TLS
Hovav Shacham Boneh, and Eric Rescorla
[8] Improving Secure Server Performance by Re-balancing SSL/TLS
Handshakes,
Claude Castelluccia, Einar Mykletun, Gene Tsudik
[9] http://eprint.iacr.org/2005/037.pdf
19
Spring 2006