TLS and the Hidden Intricacies of Secure Browsing

Joseph Argento

With more than half a billion users, Facebook has become nearly ubiquitous among
college students. By default, pages on Facebook are transmitted over unsecured http, a
vulnerability which has recently been brought to light in the media. In January of 2011, the
Tunisian government exploited this insecure connection to steal the passwords of activists within
the country. These accounts were then deleted. Weeks later, the account of Facebook creator
Mark Zuckerburg was compromised, leading Facebook to implement the option of using secure-
http, or https1. On the surface, enabling this option is invisible to the user. An address is entered,
and they are greeted by their Facebook homepage. The reality, however, is far more complex.
Within roughly 300ms, the user’s computer and Facebook exchange a series of messages.
Negotiations are performed, hands shaken, certificates and codes exchanged, and eventually a
pool of secret data is created--all to keep your account safe from prying eyes. This secure means
of browsing is done using the TLS standard. TLS, or Transport Layer Security, is a suite of
cryptographic protocols introduced in January 19992. The secure connection is made in three
stages; establishing trust, exchanging secrets, and then exchanging data.
The eventual goal of TLS is to allow for the transmission of encrypted data between two
computers. But before anything relating to this encryption is exchanged, trust must be
established between the user’s browser and the website’s server. This begins will a “hello”
message from the client3. The message contains a suite of information, including the time, the
version of TLS being used, and a list of the cipher suites the user can support.

Figure 1. Contents of the Client Hello packet4

1
http://www.wired.com/threatlevel/2011/01/facebook-https/
2
http://en.wikipedia.org/wiki/Transport_Layer_Security
3
http://tools.ietf.org/html/rfc2246#page-43
4
Packet captures obtained using Wireshark
 2

The server then replies with its own hello message, beginning a negotiation over which cipher
suite is to be used. In this case, Facebook chooses to use the RSA cipher with128 bit RC4
encryption and the MD5 hash algorithm.

Figure 2. Contents of the Server Hello packet

Next, the server begins the process of demonstrating its trustworthiness by sending a
packet containing a certificate. This contains information about the URL the holder of this
certificate is authorized to use, dates of validity, and the digital signature of a third party. In this
case that company is DigiCert. The users browser (in my case Mozilla Firefox) trusts that
DigiCert would not sign a company’s certificate without ensuring that they are legitimate. All
that is left to do, then, is verify that this signature really came from DigiCert.

Figure 3. One certificate from the “Certificate, Server Hello Done” packet.
 3

Figure 4. Response by DigiCert to request for validation of Facebook’s certificate.

The verification of this signature is based off the RSA algorithm, the same means by
which the client and server will later exchange keys. RSA works on the principal that it is easy to
raise numbers to various powers, but difficult to factor large numbers into their prime factors5.
Most of the work in creating an RSA cipher is done long before the user attempts a
connection. First, two large prime numbers are chosen, designated p and q. The product, n, of
these two primes is then computed, along with their totient, φ(n). Knowing p and q, the totient
can be easily calculated as (p-1)(q-1).
Next, an exponent e is chosen. Knowing φ(n), the modular multiplicative inverse of e, d,
can be calculated as

This value, d, is then kept secret while e and n are made public. To encrypt a message, it is
interpreted as a number, and the cipher text C calculated as

Then, since d is the modular multiplicative inverse of e, a message can be decrypted by raising C
to the power of d. That is

As shown before, the modular multiplicative inverse d was calculated with the help of the
toitent of n. Knowing p and q, the totient was easy to determine. For anyone who doesn’t know
what these values are, however, determining the totient would require factoring them from n.
Since the numbers used are all very large (on the order of 2000 bits), this is computationally
difficult. Accordingly, only someone who knows d should be able to decrypt the message.
Now, let’s get back to handshaking. The signature attached to the certificates sent by
Facebook consists of a hashed (or scrambled) version of the certificate contents, and a version of
this hash on which DigiCert has performed a modular exponentiation with their private key, d,
mod n. As Facebook told us it would be using the MD5 hash algorithm in its hello message, we
can easily verify that the hashed bytes are as they should be. The client can then perform a
modular exponentiation of the signed bytes with the public key e, mod n. Since e and d are

5
http://www.di-mgt.com.au/rsa_alg.html
 4

modular multiplicative inverses, this operation will produce the hashed bytes from the signed
bytes. Since we trust that DigiCert’s d value is known only to them, we can then trust that
DigiCert created this signature.
Now that trust has been established, the client and server can begin exchanging the data
they will need to establish a secure connection. Eventually each side will need to have possession
of a secret key, which will be used to seed the encryption algorithm. Arriving at this secret key
begins with the client generating a random value. The user’s computer samples data from
sources such as the system time, process information, and a host of various statistics with
obscure names like Cache manager Pin-Mapped Data Count and Quota Peak Paged Pool Usage6.
This data is used to generate 48 pseudo-random bytes, called the pre-master secret. This secret is
then sent to Facebook, once again using the RSA cipher.
Now that both sides of the connection share the pre-master secret, a master secret can be
calculated using additional random information which was sent along with the hello messages.
This master secret is then fed into the RC4 encryption algorithm which Facebook elected to use.
The client and server are now ready to begin encrypting and decrypting data.
RC4 is a stream cipher, meaning it works by combining the information to be encrypted
with additional information known only to the two parties communicating, one byte at a time7.
The master secret is fed into an algorithm which uses it to seed the scrambling of a 256 bit binary
sequence. This scrambling can be performed over and over again, producing a different bit
sequence every time. While the bits appear random, since both the client and server started with
the same seed information the bit streams they produce will be the same. To encrypt a sequence
of data, this pseudo-random information just needs to be combined with the information to be
encrypted.
This combination is done using an exclusive or (XOR) operation between the message
bits and the pseudo-random bit stream. XOR returns 1 when one but not both of the input bits are
1, and otherwise returns 0. Accordingly, wherever there is a 1 in the pseudo-random bit stream
the corresponding bit in the message will be flipped. For example, encoding the message JA
gives

Message: 0100 1010 0100 0001b

Random bits: 1011 0100 1100 0101b
XOR: 1111 1110 1000 0100b (Encoded message)

Since the recipient knows the random bits used to encode the message, they can decode it
by simply repeating the XOR operation, flipping back whatever bits were flipped in the encoding
process.

Encoded Message: 1111 1110 1000 0100b

Random bits: 1011 0100 1100 0101b
XOR: 0100 1010 0100 0001b (Decoded message)

And there we have it, our connection is now secure. When we click a link to open our
email account or make an online purchase it is easy to take for granted all the work being done
behind the scenes. Even what is described here is a simplification, and the RC4 schema chosen is

6
http://blogs.msdn.com/b/michael_howard/archive/2005/01/14/353379.aspx#353493
7
http://en.wikipedia.org/wiki/Rc4
 5

one of the simplest encryption algorithms. This fascinating technology has played a crucial role
in enabling the growth of online commerce, and the field of information security continues to
evolve. New attacks on these security measures are always being devised, and new
vulnerabilities exploited. For the moment, though, we can rest assured that our Facebook pages
are safe from hijacking.

Sources

Howard, Michael. "Cryptographically Secure Random Number." MSDN Blogs - MSDN Blogs.
14 Jan. 2005. Web. 08 Apr. 2011.
<http://blogs.msdn.com/b/michael_howard/archive/2005/01/14/353379.aspx>.

Internet Engineering Task Force. "RFC 2246 - The TLS Protocol Version 1.0." IETF Tools. Jan.
1999. Web. 08 Apr. 2011. <http://tools.ietf.org/html/rfc2246>.

Ireland, David. "RSA Algorithm." DI Management. 19 Feb. 2010. Web. 08 Apr. 2011.
<http://www.di-mgt.com.au/rsa_alg.html>.

Moser, Jeff. "The First Few Milliseconds of an HTTPS Connection." Moserware. 10 June 2009.
Web. 08 Apr. 2011. <http://www.moserware.com/2009/06/first-few-milliseconds-of-
https.html>.

Singel, Ryan. "Facebook Enables HTTPS So You Can Share Without Being Hijacked."
Wired.com. 26 Jan. 2011. Web. 08 Apr. 2011.
<http://www.wired.com/threatlevel/2011/01/facebook-https/>.

Wikipedia contributors. "RC4." Wikipedia, The Free Encyclopedia. Wikipedia, The Free
Encyclopedia, 30 Mar. 2011. Web. 8 Apr. 2011.

Wikipedia contributors. "Transport Layer Security." Wikipedia, The Free Encyclopedia.

Wikipedia, The Free Encyclopedia, 8 Apr. 2011. Web. 8 Apr. 2011.