TLS Stateful vs Stateless Session Resumption
1. Preliminary Information TLS Session Resumption allows caching of TLS session information. There are 2 kinds: stateful and stateless. In stateful session resumption, BIG-IP stores TLS session information locally. In stateless session resumption, such job is delegated to the client. BIG-IP supports both stateful and stateless TLS session resumption. Enabling stateful or stateless session resumption is just a matter of ticking/unticking a tickbox on LTM's Client SSL profile: In this article, I'm going to walk through how session resumption works by performing a lab test. Here's my topology: Do not confuseSession Reuse/Resumption withRenegotiation. Renegotiation uses the same TCP connection to renegotiate security parameters which does not involved Session ID or Session Tickets. For more information please refer to SSL Legacy Renegotiation Secure Renegotiation. 2. How Stateful Session Resumption works Capture used:ssl-sample-session-ticket-disabled.pcap 2.1 New session Statefulmeans BIG-IP will keep storing session information from as many clients its cache allows and TLS handshake will proceed as follows: We can see above that Client sends an empty Session ID field and BIG-IP replies with a new Session ID (filter used:tcp.stream eq 0). After that, full handshake proceeds normally where Certificate and Client Key Exchange are sent and there is also the additional cost CPU-wise to compute the keys: 2.2 Reusing Previous Session Now both Client and Server have Session ID 56bcf9f6ea40ac1bbf05ff7fd209d423da9f96404103226c7f927ad7a2992433 stored in their TLS session cache. The good thing about it is that in the next TLS connection request, client won't need to go through the full TLS handshake again. Here's what we see: Client just sends Session ID (56bcf9f6ea40ac1bbf05ff7fd209d423da9f96404103226c7f927ad7a2992433) it previously learnt from BIG-IP (via Server Hello from previous connection) on its Client Hello message. BIG-IP then confirms this session ID is in its SSL Session cache and they both go through what is known as abbreviated TLS handshake. No certificate or key information is exchanged during abbreviated TLS handshake and previously negotiated keys are re-used. 3. How Stateless Session Resumption works Capture used:ssl-sample-session-ticket-enabled-2.pcap 3.1 New Session Because of the burden on BIG-IP that has to store one session per client,RFC5077suggested a new way of doing session Resumption that offloads the burden of keeping all TLS session information to client and nothing else needs to be stored on BIG-IP. Let's see the magic! Client first signals it supports stateless session resumption by adding SessionTickets TLS extension to its Client Hello message (in green): BIG-IP also signals back to client (in red) it supports SessionTicket TLS by adding empty SessionTicket TLS extension.Notice thatSession IDis NOT used here! The TLS handshake proceeds normally just like in stateful session resumption. However, just before handshake is completed (with Finished message), BIG-IP sends a new TLS message calledNew Session Ticketwhich consists of encrypted session information (e.g. master secret, cipher used, etc) where BIG-IP is able to decrypt later using a unique key it generates only for this purpose: From this point on, client (10.199.3.135) keeps session ticket in its TLS cache until next time it needs to connect to the same server (assuming session ticket did not expire). 3.2 Reusing Previous Session Now, when the same client wants to re-use previous session,it forwards the same session ticket aboveinSessionTicket TLS extensionon its Client Hello message as seen below: As we've noticed, Client also creates a new Session ID used for the following purpose: Server replies back with same session ID: BIG-IP accepted Session Ticket and is going to reuse the session. Server replies with empty/different Session ID: BIG-IP decided to go through full handshake either because Session Ticket expired or it is falling back to stateful session resumption. PS: Such session ID is NOT stored on BIG-IP otherwise it would defeat the purpose of stateless session reuse. It is a one-off usage just to confirm to client BIG-IP accepted session ticket they sent and we're not going to generate new session keys. In our example, BIG-IP successfully accepted and reused TLS session. We can confirm that an abbreviated TLS handshake took place and on Server Hello message BIG-IP replied back with same session ID client sent (to BIG-IP): Now, client This is session resumption in action and BIG-IP doesn't even have to store session information locally, making it a more scalable option when compared to stateful session resumption.
Infrastructure 2.0: Aligning the network with the business (and the rest of IT)
When SOA was the hot topic of the day (not that long ago) everyone was pumped up about the ability finally align IT with the business. Reusability, agility, and risk mitigation were benefits that would enable the business itself to be more agile and react dynamically to the constant maelstrom that is "the market". But only half of IT saw those benefits; the application half. Even though pundits tried to remind folks that the "A" in SOA stood for "architecture", and that it necessarily included more than just applications, still the primary beneficiary of SOA has been applications and through their newfound agility and reusability, the business. The network has remained, for many, just as brittle and unchanging (and thus not agile) as it has ever been, mired in its own "hardwired" architectures, unable to flex or extend its abilities to support the applications it is tasked with delivering. And no one seemed to mind, really, because the benefits of SOA were being realized anyway, and no one could really quantify the benefits of also rearchitecting the network infrastructure to be as flexible and agile as the application infrastructure. But along comes virtualization and cloud computing, and an epiphany was had by many: the network and application delivery infrastructure must be as agile and flexible as the application infrastructure in order to achieve the full measure of benefits from this newest technology. Without an application delivery infrastructure that is as able to adapt dynamically the infrastructure is the wall between a successful deployment and failure. In order to truly align the network with the business - and the other half of IT - it becomes necessary to dig deeper into the network stack and really take a look at how you're delivering those agile applications and services. It's important to consider the ramifications of a static, brittle delivery infrastructure on the successful deployment and delivery of virtually hosted applications and services. It's necessary to look at the ability of your delivery infrastructure and evaluate its abilities in terms of reusability, scalability, and dynamism. Analyst and research firm Gartner said is as succinctly as it can be said: You Can't Do Cloud Computing Without the Right Cloud (Network) and the same holds true for virtualization efforts. You can't efficiently deliver virtualized applications without the right network infrastructure. Until your network and application delivery infrastructure is as agile and reusable as your application infrastructure you won't be able to align all of IT with the business. Until you have a completely agile architecture that spans all of IT, you're not truly aligned with the business.How AJAX can make a more agile enterprise
In general, we talk a lot about the benefits of SOA in terms of agility, aligning IT with the business, and risk mitigation. Then we talk about WOA (web oriented architecture) separately from SOA (service oriented architecture) but go on to discuss how the two architectures can be blended to create a giant application architecture milkshake that not only tastes good, but looks good. AJAX (Asynchronous JavaScript and XML) gets lumped under the umbrella of "Web 2.0" technologies. It's neither WOA nor SOA, being capable of participating in both architectural models easily. Some might argue that AJAX, being bound to the browser and therefore the web, is WOA. But WOA and SOA are both architectural models, and AJAX can participate in both - it is neither one or the other. It's seen as a tool; a means to an end, rather than as an enabling facet of either architectural model. It's seen as a mechanism for building interactive and more responsive user interfaces, as a cool tool to implement interesting tricks in the browser, and as yet another cross-browser incompatible scripting technology that makes developer's lives miserable. But AJAX, when used to build enterprise applications, can actually enable and encourage a more agile application environment. When AJAX is applied to user-interface elements to manipulate corporate data the applications or scripts on the server-side that interact with the GUI are often distilled into discrete blocks of functionality that can be reused in other applications and scripts in which that particular functionality is required. And thus services are born. Services that are themselves agile and thus enable broader agility within the application architecture. They aren't SOA services, at least that's what purists would say, but they are services, empowered with the same characteristics of their SOA-based cousins: reusable and granular. The problem is that AJAX is still seen as an allen wrench in an architecture that requires screwdrivers. It's often viewed only in terms of building a user interface, and the services it creates or takes advantage of on the back-end as being unequal to those specifically architected for inclusion in the enterprise SOA. Because AJAX drives the development of discrete services on the server-side, it can be a valued assistant in decomposing applications into its composite services. It can force you to think about the services and the operations required because AJAX necessarily interacts with granular functions of a service in a singular fashion. If we force AJAX development to focus on the user-interface, we lose some of the benefits we can derive from the design and development process by ignoring how well AJAX fits into the service-oriented paradigm. We lose the time and effort that goes into defining the discrete services that will be used by an AJAX-enabled component in the user-interface, and the possibility of reusing those services in the broader SOA. An SOA necessarily compels us to ignore platform and language and concentrate on the service. Services deployed on a web server utilizing PHP or ASP or Ruby as their implementation language are no different than those deployed on heavy application servers using JSP or Java or .NET. They can and should be included in the architectural design process to ensure they can be reused when possible. AJAX forces you to think in a service-oriented way. The services required by an AJAX-enabled user-interface should be consistent with the enterprise's architectural model and incorporated into that architecture whenever possible in order to derive agility and reuse from those services. AJAX is inherently an agile technology. Recognizing that early and incorporating the services required by AJAX-enabled components can help build a more agile, more consistent, more SOA-like application infrastructure.Port Knocking: What are you hiding in there?
I read with interest an article on port knocking as a mechanism for securing SOA services on CIO.com. If you aren't familiar with port knocking (I wasn't) then you'll find it somewhat interesting: From Nicholas Petreley's "There is More to SOA Security Than Authorization and Authentication" For the sake of argument, let's say you have an SOA server component for your custom client software that uses port 4000. Port knocking can close off port 4000 (and every other port) to anyone who doesn't know the "secret method" for opening it. Any cracker who scans your server for open ports will never discover that you have an SOA service available on that port. All ports will appear unresponsive, which makes your server appear to offer no services at all. Ironically, your client gains access to port 4000 in a way similar to the way crackers discover existing open ports. As described above, port scanners step through all available ports sequentially, knocking on each one to see if there's an answer. By default, a port knocking-enabled firewall never answers on any port. The secret to unlocking any given port is in the non-sequential order your client uses to check for open ports. For example, your client software might check ports 22, 8000, 45, 1056, in that order. Each time, there will be no answer. But the server will recognize that your device —running the legitimate client software—knocked on just the right ports in the right order, like the key to a combination lock. Having gotten the right combination, the firewall will open port 4000 to the authenticated device and only to that device. Port 4000 will continue to look closed and unused to the rest of the world. A great description is also available here along with client and server side software. At first I thought "this is way cool". Then I thought about it some more and thought "Wow. That's going to destroy performance, increase development and support costs, and put a big target on your services. Still cool from a technical perspective, but from an enterprise architecture point of view? Not so cool." While the initial value of port knocking - making it more difficult to find services to attack in the first place - seems obvious, there are better ways to secure access to services than by hiding them and requiring modifications to clients (or requiring custom clients in the first place) to access them. The description from Nicolas includes "running the legitimate client software", which implies there is some method of identifying legitimate - and therefore illegitimate - clients. There are much less intrusive methods of determining the legitimacy of clients such as client certificates, custom HTTP headers, and, for SOA specific applications, digital signatures. The use of port knocking necessarily adds additional requests, which degrades the responsiveness of applications simply because it requires more time to "get into" the application. SOA applications aren't all that speedy in the first place, so adding more latency into the equation is certainly not going to improve user adoption or satisfaction with the application in terms of performance. Requiring special clients increases the support costs for any application as well as introduces variability that can delay development and deployment, such as OS platform support. Will all the clients be .NET? Java? What versions? What about patching and upgrades? What do the port knocking libraries support? How secure are they? Do they even exist? It also destroys ubiquitous web access to services through a browser, which destroys the benefits of reusability of services. If you need a special client it's not likely that browser-based access is going to be possible. And what about changes to your infrastructure? Port knocking requires a port knocking enabled firewall or server, and it almost certainly will be need to be deployed on the outside perimeter, in front of your enterprise firewall, because all ports need to be "open and answerable" in order to port forward the client to the "next door" in the sequence. This changes your network infrastructure and requires that you add yet another point of failure in the security chain. SOA has some well defined security that goes further than just authentication and authorization in WS-Security 1.1. The use of encryption, digital signatures, and SSL goes a long way toward securing your SOA. Hiding the existence of services makes it harder to find them, as the article points out. But attackers aren't stupid; if you go to extreme lengths to hide those services then they must be worth finding. Will it stop script kiddies? Certainly. Will it stop the hard-core organized attack squads? Absolutely not. Hiding your services with port knocking is a lot like turning off all the lights and pretending not to be home. Thieves generally don't go after the well-lit, occupied homes. They like the empty ones, or the ones just pretending to be empty.
