The term “SSL persistence” is best understood by looking
at the example of the electronic shopping-cart. The shopping-cart, as
employed by most ecommerce sites, is a logical repository for items that
have been selected by a client while shopping at on online site. The items
selected generally reside on the server to which the client first
connected, and which served the client the content during the session. If
at any point during the session the client if switched to another server,
a server that does not share the session-data, the client’s shopping-cart
will be lost and the shopping experience will be ruined. During the
unencrypted browsing portion of the session, it is fairly unlikely for
this breaking of persistence to occur because of the reliability of
unencrypted or non-secure persistence mechanisms.
Source IP Persistence
The first non-secure persistence mechanism employed by load-balancers was
Source IP Address stickiness (Source IP). Using Source IP, load-balancers
attempted to identify users by their Source IP Address, and to keep the
users stuck to the appropriate server using this identifier. This method
quickly proved to be unreliable due to the effect of proxy servers and
network-address translation (NAT). When proxy-servers or NAT are used,
there is no way to reliably correlate an IP address to a user; Instead
many users may be represented by a single IP address, or a single user’s
IP address may change throughout the life of a session. Because of this
pervasive effect, a new non-secure persistence method soon supplanted
Source IP persistence.
Cookie Persistence
As load-balancers became more advanced, they began
to inspect data beyond simply Network (Layer 3) and Transport (Layer 4)
information. Newer load-balancers, also known as Content or Application
Switches, offered the ability to inspect the data all the way up to the
application layer (Layer 5 or Layer 7). With this advancement came a new
persistence mechanism known as Cookie Persistence. Cookie Persistence used
a browser cookie to uniquely identify users. Either the application or the
content-switch itself would serve cookies to users at the start of a
session, and the user’s browser would automatically return the cookie
during each successive hit. By tracking this cookie information, the
content-switches were able to accurately determine which server should
receive the subsequent traffic. Cookie persistence remains the most
reliable method of non-secure persistence, but unfortunately, it does not
work with SSL: because SSL encrypts all data, including the cookie,
content-switches are unable to inspect the cookie, rendering ineffectual
yet another form of persistence.
SSL Session ID Persistence
Unable to rely on Source IP addresses, and unable to inspect the cookie
during an SSL session, content-switch vendors had to devise a method of
offering persistence in an SSL environment. Fortunately, SSLv3 offered a
way to do this. SSLv3 moved the SSL Session ID, a unique 32 byte session
identifier, out of the encrypted portion of the data into a clear portion.
Load-balancing and content-switch vendors were able to read this unique
identifier, and to balance the traffic to the appropriate server based on
this predictable identifier. This method worked until Microsoft introduced
Internet Explorer version 5.0. Beginning with IE5, Microsoft changed the
behavior of their secure channel libraries to force a renegotiation of a
new SSL session every two minutes. This meant that all IE5+ users would
change SSL Session ID every two minutes, breaking the only method of
secure persistence available.
Guaranteed Secure Persistence
At about the same time that IE’s SSL behavior became an issue, SSL
offloaders began to rise in popularity. By coupling an offloader with a
content-switch, it once again became possible to offer guaranteed
persistence by decrypting the SSL content so that the content-switch can
inspect the data again. The logical flow is illustrated below. When SSL
traffic arrives at the content-switch, it is redirected to an SSL
offloader. The offloader decrypts the content in its entirety, including
any cookies that might have been sent by the browser, and sends them back
to the content switch. At this point, the data is in-the-clear, and the
content-switch can inspect the cookies, the URL, the URI, the browser
type, etc. Full functionality is returned to the content-switch, and the
client is guaranteed a secure persistent browsing experience.
SSL
Persistence
