Firesheep and the SSL every...

Sometimes i can observe trends in reader interest in the webserver logs: In the last time there were a lot of accesses to an article dating back to September 2007 when i talked about SSL acceleration and made the case for T2.

In the first few seconds i asked my self, why there is that new interest in this article. However then i just thought "Damned, Firesheep".

Just in case you didn't heard about it: With firesheep you can highjack user sessions by sniffing on unencrypted data flow in your network. This can work, as often the authentication form itself is encrypted, but afterwards they use unencrypted communication. The authorization to access those pages with your login credentials is carried forward by cookies. When you are able to gather this cookie, you can take over the session of a user. This isn't really a new attack vector, but firesheep is makes this really easy ... script-kiddies easy. It's integrated into Firefox as a plugin and hijacking other peoples session is as easy as changing tabs.When you want an explanation for that, please look at Eric Butlers preso "Hey Web 2.0:Start protecting user privacy instead of pretending to". The attack vector bases on the fact that someone can sniff your data. You may think at first "Well, we have switches, no sniffing", however think about unencrypted (and i consider WEP as unencrypted) WLANs.

There is just one solution: Encrypt everything. HTTPS to the help. However while this isn't a problem on client side, it creates a lot of problems on the server side. Like the problem, that virtual hosts are in need of their own IP addresses (there is an Hen-Egg-Problem in SSL). Or that you have to provide the other end of the cryptographic connection, thus you have to do all the calculation on the server side.

I'm still pretty sure, that SPARC T-class and Solaris can really help you here. The T-Series because of it's cryptographic unit. It isn't just an rather small extension like the additional commands in Nehalem to accelerate AES, it's a full-fledged crypto co processor. In the case of the SPARC T3 you have 16 of them and they got some significant update to accelerate mor ciphers and to handle many small packets much better. There is an interesting presentation availble about this piece of silicon in T3. It's already the 3rd generation of crypto acceleration in T3.

However hardware is nothing without software and thus i want to point you view to kssl. kssl is an in-kernel proxy for SSL. This in-kernel proxy uses the hardware acceleration in the T3 via the Solaris Cryptographic Framework (SCF), another nice thing that does the abstraction between the hardware (or non-existing hardware, when you do cryptography on your normal CPU) and the services using cryptography. Why is the in-kernel proxy that useful? At first it's easy to configure, but more important you don't have to hop between user- and kernelspace, as when a usermode library like openssl uses the kernel driver of your hardware. This gives you additional performance.

This kssl and SCF thing is however nothing that's limited to T-class. It's available on x86-solaris as well and in the case you purchase a supported crypto acceleration card, kssl uses this via SCF as well. However a PCI based card can never be as fast as crypto accelerators directly on die and on core like the ones in T-class.