Saturday, 23 October 2010
This scenario implies that any employed transport security (HTTPS -> SSL/TLS) provides an end-to-end protection for any data users submit to the website because the webserver in effect would terminate the SSL/TLS connection and process the data itself (ignoring any security issues relating to persistance). However, because SSL/TLS termination is computationally expensive most major websites deployed dedicated systems to terminate the SSL/TLS connection in order to offload the cryptographic operations to a dedicated (usually proprietary) systems:
However, most often websites implement a multi-tier architecture in which the webserver is separate from the application-server (which runs the business logic) like so:
While the use of SSL/TLS terminators and application-servers makes perfect sense from a system-architectural perspective it introduces an additional security issue - the "encryption gap":
This might not seem like a significant issue because the prime purpose of SSL/TLS is usually to provide protection for communications spanning insecure networks (ie: the Internet). However, even "internal" networks are more often than not rather not-too-secure because many different parties might obtain access to the network communications between the SSL Terminator and webservers as well as the network segments between the webservers and the application-servers.
Naturally, this assumes that the application-server implements sufficient safeguards for protecting the data it processes - but that's an entirely different story. What's surprising is that this additional security layer is virtually never deployed, although ready-to-use implementations (libraries) exist. My assumption is that this is because they aren't bundled in major application frameworks just yet and most application architects are unaware of the possibilities.
I think I've established the conceptual issue at hand - let's get to the practical part: what ready-to-use implementations was I referring to? The underlying and (cryptographically) established protocol is the "Secure Remote Password" (SRP) protocol. Implementing SRP requires a change as to how one approaches user authentication: usually the submitted password is matched against a record in the application's database (which is hopefully a salted and hashed representation of the user's password) in order to evaluate the validity of the submitted user credentials. The SRP's core paradigm is to shift away from this compare-and-decide approach and towards a cryptographic proof-of-knowledge approach. The benefit to this approach is that a by-product of this cryptographic verification can be used to establish a shared secret know only to the client and the application-server. This shared secret can than be used to encrypt any sensitive data within the SSL/TLS layer in order to prevent interception in between the SSL/TLS Terminator and the application-server - thus closing the "encryption gap".
An exceptional demo page is provided on the SRP's homepage. It requires Java but is well worth the effort since it neatly details the involved computational steps. Lastly, let me point you to the promised ready-to-use implementations: