Tag: encryption

http vs https performance

A while ago I had a huge argument with a development team regarding the usage of https. Their major concern was that the impact on performance would be so big that their servers wouldn’t be able to handle the load.

Their approach was to use https just for the login sequence and plain text communication for everything else. And it was not like they didn’t understand the underplaying problem of sending session cookies over an unencrypted channel, it was just that they thought https is too much for the servers to deal with.

Doing some research back then, I found a paper from the 90s stating that the performance impact was between 10 and 20%. And that only because of the hardware (mainly) CPU available at that time. With the advancement in computational power that should have decreased over time.

And indeed, as of 2010, Gmail switched to using HTTPS for everything by default. Their calculation shows that SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Of course there were some tweaks, but no rocket science involved.

1%, 2%, 10KB. Nothing. I remember somebody saying that 640KB ought to be enough for anyone 🙂 Maybe he knew something. As you can see in the link, Bill Gates didn’t actually say that.

5 more years have passed since then, hardware is more capable, cheaper, so there’s no excuse not to use https.

I’ve seen poor implementations where all http traffic was passed over a secure channel, but not the .js files. Needless to say, a MitM attack can easily modify the .js on the fly and run code in the victim’s browser.

As a closing note, use https for everything, don’t invoke the performance issues, there’s no reason in the current era not to do so.

Techniques to play with custom and encrypted protocols

An interesting presentation from DEFCON20 provided by Elie Bursztein and Patrik Samy called “Fuzzing Online Games” touches areas of application security where traffic analysis is not enough to perform a penetration test.

As stated by the authors:
“In a nutshell the lack of direct access to the game server and having to deal with clients that are far too complex to be easily emulated force us to rely on injecting fuzzing data into a legitimate connections rather than use the standard replay execution approach. Top that with heavily encrypted and complex network protocols and you start to see why we had to become creative to succeed :)”

The problem of an application security analysts is that most of the communication is encrypted and is using custom protocols that can’t be intercepted using standard proxies like Burp or Charles. One’s thoughts on this could go into using Mallory as transport layer proxy and should be fine with some custom protocols but still doesn’t deal with the encryption problem. So reverse engineering and memory analysis and manipulation must be involved.

Techniques proposed by the presenters:
– Combining network traffic analysis with memory analysis (check what happens in the memory when certain packets are sent over the wire)

Challenges involved:
– Intercepting traffic
– Bypassing Encryption
– Reversing the protocol
– Monitoring the results of fuzzing

Traffic interception:
– DLL injection at the application level – direct access to game state
– Write a driver at the OS level
– Pass the traffic through an intercepting box – this is done at the network level; as a side note this can be done on the same box using WireShark; keep in mind that WireShark does not intercept packets sent on the loopback interface and you can use RawCap for this

DLL injection:
– Most application use Windows Winsock API and the interesting functions to watch for are connect, recv and send
– Ways to do it: Microsoft detour library and IAT (Import Address Table) hooking:
o http://sandsprite.com/CodeStuff/Understanding_imports.html
o http://sandsprite.com/CodeStuff/IAT_Hooking.html
– The problem is that protection mechanisms like anti-cheating engines detect hooking

Writing a driver:
– Windows Filter Platform – could be an excellent replacement for Mallory since we don’t need an external machine (even a virtual one) to capture the packets

The presenters then focus on the analysis of the custom LOL (League of Legends) protocol to give a practical example. Among others, they use packet, statistical, n-gram analysis and search for a feasible way to fuzz the protocol. They don’t go into details like tools, usage and how to perform the analysis but stay on a high perspective level.