Protocol Realism: AOL Instant Messenger and TLS

The latest Application Protocol & Strike Pack includes support for AOL Instant Messenger, version 6. AIMv6 (as opposed to AIMv4 and earlier) has built-in support for conducting most of its business over an encrypted channel on port 443, and this encrypted communication is on by default. If that sounds like TLS/SSLv3 to you, you'd be right -- up to a point. There is an area where the encrypted AIM traffic (in its default configuration on Windows) diverges rather starkly from your usual TLS traffic, and I'd like to highlight that today to illustrate the value in realistic protocol implementation.

Cryptographic Traffic Analysis

While researching the post-authentication sequence for AIM, I noticed that certain message lengths and message sequences kept popping up during particular phases of the protocol. For example, message lengths of 32 bytes seem to be common from the client to the server during the post-authentication sequence of setting a user's initial status, retrieving buddy list information, and filling in the online/offline properties of buddies. In fact, the initial post-authentication sequence is quite static, from the message length and message sequence standpoint. It looks something like this for the first dozen application data packets:

It goes on from here and gets more varied the further in we get to the post-authentication sequence. More importantly, it does happen every time an AIMv6 user logs in, and this is distinct from "normal" TLS in some important ways.

First, the usual use of TLS over port 443 is for secure web browsing. These sessions tend to have a client request of between five hundred and a thousand bytes, followed by a slew of server responses with sizes all over the place, varying wildly by site and page the user happens to be requesting. Because we see here some relatively small message lengths, and a more even client, server, client, server request and response pattern, it's clear that this is more interactive than your typical web browsing.

Secondly, the stacked Application Data messages are pretty unusual. Most client/server TLS implementations will dedicate each message to a TCP packet, and won't normally concatenate small messages into larger (and more bandwidth efficient) packets. When I first captured some AIM traffic to look at, this jumped out immediately and I needed to double-check that this wasn't a transmission or capture error, since I've never seen it before in normal traffic.

So, who cares?

People who are into DPI, that's who. Let's say you wanted to build a device that, among its many wonderful inspection capabilities, should be able to pick out AIMv6 traffic from other encrypted traffic for the purpose of rate limiting or ensuring QoS or whatever. Well, without the above insight, that task may be an expensive proposition -- a DPI device would have to monitor connections to first find the AOL keyserver certificate, then deduce from that connection where the communications channel is going to show up (either through guesswork or some clever man-in-the-middle SSL proxy shenanigans). Alternatively, they could keep tabs on the IP addresses AOL uses for their AIM switchboard servers, and just go by those addresses to pick out the interesting from the uninteresting encrypted data...but they risk false positives/false negatives any time AOL removes or adds an IP address to their switchboard server farm. Since these approaches are unreliable hassles, I would go for traffic analysis to decide if I'm looking at AIM.

Maybe there's some other reason why modeling encrypted applications accurately is important. Imagine there's an inspection device (like an IPS), that performs a length check on the Application Data messages of TLS sessions, and due to a parsing error, that device blows up if it sees TCP packets with four or five of them all stacked together. That fault wouldn't be detected if a testing apparatus didn't include some of this unusual traffic -- traffic that is otherwise perfectly realistic and based on real-world network usage.

Perhaps there's some other reason that we haven't thought of here yet. After all, some of our customers can be the secretive sort, since they tend to be designing, building, and testing the next generation of network hardware, so we don't always have perfect insight into what they're up to with our Application Simulator protocols. Hopefully, with BreakingPoint's dedication to protocol realism, those customers are able to test features and discover bugs that we haven't anticipated yet.

Posted by Tod Beardsley

Printer Friendly Create PDF

0 comments
Tags: Custom Applications and Attacks // DPI Testing //