Although I initially had my reservations about the increased use of client-side Javascript in Webpages (which is in fact a significant security risk as with XSS injections) there're new opportunities for additional architectural security "features" that websites can implement. What I am talking about is the ability to use client-side computational capabilities to establish an additional cryptographic security layer. For example, take the "traditional" (albeit mostly outdated) website architecture:

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.

The aforementioned opportunity for improving security is that the presumed client-side computational capabilities (Javascript) can be employed to implement an additional cryptographic layer in order to provide an effective end-to-end protection for data transferred between the client and the application-server:

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:

• SRP's "links" page lists several implementation by programming language
• Denksoft's PHP implementation (I really don't know why it isn't listed on the SRP's link page)

I've come across a great resource for SELinux: http://selinux-mac.blogspot.com/. Especially the 10 part SELinux tutorial is recommended for anyone new to SELinux: http://selinux-mac.blogspot.com/2009/06/selinux-lockdown-part-one-confined.html.