SSL Über Alles
Mark Hoover, President, Acuitive, Inc.

Why do people have to worry about the security and privacy of their communications over networks?  Why isn’t everything scrambled or encrypted as a matter of course?  The answer is related to the cost of doing so.  Encryption and decryption require a lot of costly horsepower; and the management and operations burden of managing and distributing the keys, which is the make/break factor that determines whether encryption really ensures privacy, can be enormous.  

As a result, encryption is used today only where and when absolutely necessary.   Web-based E-commerce sites and financial sites use the Secure Sockets Layer (SSL) protocols to protect key information such as credit card numbers and personal account information.  SSL works because of the strong encryption used by the protocol. Strong encryption, however, requires CPU processing power. So the trade-off of using SSL is the burden placed on the system CPU.

As an example, according to study by Networkshop, a web server based on an Intel Pentium III, running Linux and Apache, required 13.29 times the computing power to process HTTPS (SSL) traffic than it did to process HTTP (clear text). A Sun E450/1x250Mhz, running Solaris and Apache, took 114.53 times the computing power to process the same traffic. As is apparent, SSL traffic processed by the server takes CPU cycles - lots of them.   Therefore users have to be careful in what they choose to encrypt.  They have to walk a tightrope every day between the cost of security and the liability of lack of security.  Committees with lawyers on them get together regularly to decide what to encrypt and what not to encrypt.  To allow as much as possible to be encrypted, the content encrypted is generally much less “rich” than the content unencrypted since the encryption cost is generally imposed per byte.  For instance, when I go to my on-line brokerage site I am presented with a rich, colorful, dynamic interface – until I go to my account to check on my stock portfolio where I am presented with simple text and tables – a very dry, but hopefully secure, experience. 

Over the past year or so, my work with Server Load Balancing (I’m sorry – Internet Traffic Management, Content Switching, Internet Service Level Control, or whatever your favorite term is) and E-Commerce companies has resulted in an interesting convergence of priorities related to security.  This stems from another issue with SSL, which is that it can interfere with the functionality of Server Load Balancers designed to examine URLs, cookies, and application headers in packets as they travel towards server farms, and make intelligent routing decisions based on such information. Sometimes, features dependent on access to such information are critical to the proper operation of an application.  But if the packet payload has been encrypted, then the functionality of these devices is greatly limited.

Thus there are two forces at work that would like to push the responsibility for SSL processing off the servers – one to offload the servers and return lots and lots of valuable cycles to application processing – and the other to terminate the SSL protocols “in front of” the SLB function so that valuable ‘content-aware’ features can operate without restriction.  

This has led to the so-called SSL Appliance, which operates external to the servers to terminate SSL sessions.  However, up to now the use of such devices has been limited due to major concerns related to performance and reliability.   If such a device is going to handle the SSL processing requirements for tens or hundreds of servers, it better be super scalable and dependable itself.  But first and second generation SSL accelerators are not.  They tend to support only modest secure session rates (200 to 600 per second or so) and throughput (Fast Ethernet at best).  

There are a couple of ways to deal with these issues, (a) faster devices and (b) implementation architectures that allows multiple SSL appliances to be deployed and used efficiently.  The Alteon WebSystems (Nortel Networks) iSD architecture demonstrates the latter. Alteon views SSL appliances as just another device to be load balanced and “virtualized” so that an arbitrary number of SSL appliances can be used, looking like one large SSL appliance to the outside world.  Traffic is received by the Alteon switch, a determination is made as to whether the traffic is encrypted or needs to be encrypted, and all such traffic is re-directed to one of the available and healthy attached SSL appliances so that it can do its thing.  

Implementation architectures like this are a big step in the right direction. But still, with today’s SSL appliances, you’d need 100 of them to handle the peak loads at some of the popular financial sites, and many more if those sites decided to encrypt more traffic or make their encrypted content more rich, graphical, and multimedia-like.  Clearly, bigger and badder SSL appliances are needed.  And guess what?  They are on their way.  Merchant silicon companies such as IPSec heavyweight Hi/fn, everything heavyweight Broadcom, and newcomer Corrent have announced intentions and roadmaps that will enable SSL appliances to be built that can handle thousands of secure connections per second and gigabits of throughput. 

Even more interesting to me, an Acuitive client (who I am going to unabashedly promote in this Musing) called Andes Networks just publicly launched their company a couple of weeks ago.  They are an SSL appliance systems company who isn’t waiting for the merchant silicon vendors to supply the chips they need.  Instead, they have invented a unique approach to SSL processing that when put into silicon and software results in an almost ten-fold improvement in SSL appliance efficiency.  This technology can be scaled almost arbitrarily up or down to meet any sort of price/performance requirement.  Their initial products, which will be shipping this spring, are oriented towards configurations that meet the demands of what is considered to be the high end of today’s market.  But I’m convinced that as products such as Andes’ hit the market it will result in a rapid and dramatic shift in the usage patterns of SSL – towards encryption of more content and towards increasing richness of the content encrypted.  This will quickly result in an uplift of our definition of “high end” to sites that require many tens of thousands of secure sessions per second and many, many gigabits of throughput.  The issue is going to be scaling connection set-ups more than bulk encryption, due to the short nature of many of the communications protected by SSL.  But no matter what the gating bottleneck, it will be pretty easy for Andes to spin out products that address the needs of the largest sites.

This change of usage patterns, combined with the increasing use of XML in E-Business and other server-to-server communications (which is almost always SSL-encrypted), and an increasing desire for end-to-end security, will result in a huge market opportunity for companies like Andes.    I think the existence of solutions like Andes’ could result in a situation where every communication, packet, and flow over the Internet or any other IP-oriented private or semi-private network, will be encrypted.  However, not all of that may be SSL in the near future.   Today SSL is clearly the encryption technology of choice for HTTP and XML-related communications (although it can easily accommodate support for any TCP-based protocol), and in fact any communication or application that is inherently node-to-node oriented (i.e. a browser accessing a server or one server communicating with another).  Thus today SSL is mostly understood, leveraged, sworn at, and loved by people involved in E-Business, Extranets, and internet-centric applications.  

But an alternative approach that we have all heard a lot about exists in the form of IPSec-based VPNs.   IPSec and SSL are similar in many ways, except that SSL rides on top of TCP and IPSec operates at the network layer.  Seemingly modest differences, but they have some fundamental implications.  One of the big issues with IPSec is that it encrypts the IP and TCP headers of the originating source.  This characteristic carries with it some small side effects – like the fact that IPSec packets break almost all Firewall, Server Load Balancer, Bandwidth Manager, Protocol Analysis, Capacity Planning, and Accounting/Billing products and systems in place today.   The cost of replacing these devices and re-engineering for IPSec on an end-to-end basis is many of billions of dollars.  That is why IPSec is almost never used end-to-end.  It is generally used just over the WAN, with IPSec tunnels terminated at the LAN/WAN junction within a VPN gateway of some sort.  Of course, a lot of WAN providers who would like to peak at packets a little deeper to make better routing, QoS, and accounting decisions aren’t too crazy about IPSec either. 

If IPSec doesn’t fill well on the LAN and can even cause problems in the WAN, where does it fit?  Well, IPSec does have a characteristic that is of fundamental importance.  It can support non-TCP protocols, such as NetBios, Netbios-over-IP, and DNS; one or more of which are used in almost all LAN operating systems to allow file servers, print servers and other shared networked devices to advertise their availability and their services to other network-attached devices.  Thus if one wants to achieve simple LAN extension, i.e. allow a remote device to behave as if it were locally attached, one may want to support NetBios-over-IP transport over the remote link, which IPSec does but SSL does not.  When a remote client is authenticated to join a VPN, it is allowed access to a wide variety of resources on the LAN (just as if it were locally attached), which explains why IPSec gateway products tend to support other functions such as access authentication, Network Address Translation and Firewalling that are needed as part of a complete solution to prevent major security holes.

So we have two technologies, SSL and IPSec, which on the surface compete with one another.  SSL is clearly better for node-to-node communications and end-to-end security and is more easily implemented over today’s LAN (and WAN) infrastructures, characteristics that make it ideal for supporting high value B2B, B2C, E-Commerce, ASP, extranet, and tiered service applications, all of which makes its prospects for future usage very bright.   However, IPSec and TCP tunneling supports simple LAN extension, which SSL cannot today.  Some day it may be viewed is inefficient to have one technology that is used for all node-to-node communications and another one for remote access LAN extension functions.  SSL usage will be growing fast and will achieve a much greater critical mass than IPSec.  As a final blow to IPSec, could SSL take on the LAN extension application as well?  To achieve that either the end system protocol stacks need to change – to provide SSL a port to bind to below the TCP socket (which I doubt will happen), or a set of new LAN/WAN security gateway products will need to be developed that support tunneling of NetBios/IP across WANs using SSL or a new morph of SSL, probably using a “dummy layer” of TCP (which I hope the inventors call a “Hoover layer”) to enable reliable-enough communication across the WAN, but leaving the TCP headers unencrypted (the encrypting of which is the big mistake of IPSec).   Or is that just re-inventing the IPSec wheel?  I’m not sure.  

Whether or not SSL eventually assumes the role of IPSec or not in remote LAN extension, I am predicting that in the coming years SSL will take on dramatically increased significance, not only in E-Commerce but in Enterprise intranets and extranets, dial-up networks, broadband access, …… everywhere where node-to-node communications is prevalent and growing and the desire for end-to-end security exists.

SSL Über Alles is the title of this Musing and my prediction of the month.  SSL will become almost as ubiquitous as IP itself. And the SSL market, which some of my VC friends have characterized as a niche, may be one.  But it will be the world’s largest niche, on the order of the routing “niche.”  In several years, it will be IPSec that will be the true niche technology.

(volume 4, number 2)