Facebook, SSL and Network Forensics

Facebook announced earlier this week that they will start enabling the ability to encrypt all communication to their servers though HTTPS (i.e. HTTP over SSL). Until now it is only the login that has been encrypted, all other Facebook traffic has been sent in clear text.

I suppose it was the Firesheep plugin for Firefox that forced the Facebook developers into pushing out this encryption-for-all-traffic feature. My personal opinion is that this encryption feature is something that has been needed for a long time in order to protect the privacy of all the Facebook users. By looking at network traffic from a Facebook user it has been quite simple see what email address the Facebook account is registered with as well as to extract messages that have been sent to other users. This means that anyone who has been able to sniff a user's network traffic has also been able to extract this information. One simple way to get hold of Facebook network traffic would be to bring a laptop to the nearest coffee shop with free WiFi, Starbucks seems to be a popular choice for such activities.

It is, however, not only script kiddies leeching free WiFi at Starbucks who are wanna listen in on Facebook sessions. Incident response teams as well as law enforcement utilize network forensics regularly in order to investigate computer security incidents and criminal activity. The goal of performing network forensics on Facebook traffic could be to find out who is using a particular computer or to track a botnet or worm that is running its command and control channel over Facebook. In Mandiant's recent M-trends 2011 they note that APT are starting to utilize third-party Internet services, such as Facebook, for data theft as well as command and control. The fact that Facebook are going down the SSL route therefore limits the ability of investigators to perform network forensics.

There are of course way so capture network traffic even though it is encapsulated in an SSL stream. When investigating malware one can for example perform a man-in-the-middle attack by proxying all traffic trough a server controlled by the investigator. In cases when malware achieves SSL encryption by running stunnel, or some similar encryption service running on localhost, one can rely on a simple tool such as a socket proxy in order to dump the network traffic before it is encrypted.

Looking inside SSL encrypted streams is unfortunately much more difficult when you don't have full access to the SSL client computer. In order to decrypt SSL traffic one need to know the session key, which is typically unique for each individual session. And in order to get hold of the session key one need to be able to intercept and decode the key exchange at the beginning of the SSL session. There are multiple ways to perform the key exchange in SSL, but the most common ways are to either use RSA or to use ephemeral Diffie-Hellman key exchange. When RSA is used, and a passive listener is in possession of the server's private RSA key, one can actually decode the SSL traffic. Diffie-Hellman key exchange does, on the other hand, use a scheme where a new random private key is generated for each individual session. This prevents a third-party listener, who did not participate in the key exchange, from decoding the SSL session.

I took a quick look at Facebook's SSL encryption feature by sniffing traffic from an IE7 client establishing an HTTPS session towards Facebook. Running the pcap through tshark gives the following output from the client's SSL hello message:

Secure Socket Layer
SSL Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 123
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 119
Version: TLS 1.0 (0x0301)
Random
gmt_unix_time: Jan 30, 2011 10:10:51.000000000
random_bytes: D75BFFDF5F2DB997C8CBA54DE8B57B76AAC4EF2D16E593D5...
Session ID Length: 0
Cipher Suites Length: 24
Cipher Suites (12 suites)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)

This gives the Facebook server multiple options when it comes to choosing the key exchange algorithm, including both RSA and ephemeral Diffie-Hellman (DHE).

Looking closer at the server hello from Facebook we see this:

Secure Socket Layer
TLSv1 Record Layer: Handshake Protocol: Server Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 74
Handshake Protocol: Server Hello
Handshake Type: Server Hello (2)
Length: 70
Version: TLS 1.0 (0x0301)
Random
gmt_unix_time: Jun 8, 2028 22:15:05.000000000
random_bytes: 3CD8EB6009A4CA6ECEAE9FC514DEC967C848FC2B0A5406CF...
Session ID Length: 32
Session ID: 54DFE1534E829C3AC0CF0D604C0AEF7973DAA64367870057...
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
Compression Method: null (0)

Facebook selects RSA for key exchange and RC4 for session encryption. This makes the HTTPS traffic to Facebook fairly easy to decrypt for Mark Zuckerberg, or whoever would be in possession of the private RSA key used by Facebook.

By the way, here is a good YouTube video on how to enable SSL encryption on your Facebook account.
And here is a blog post that explains how to decrypt SSL traffic with Wireshark.

Posted by Erik Hjelmvik on Sunday, 30 January 2011 21:21:00 (UTC/GMT)

Tags: #Netresec​