Last few weeks, I have been pulled into an interesting gig for demonstrating security for _____ SOA/XML Web Services and Java EE applications…. so I had a chance to play with some untold security features of Solaris 10. KSSL is one of the unsung yet powerful security features of Solaris 10. As the name identifies, KSSL is a Solaris Kernel Module that helps representing server-side SSL protocol to help offloading operations such as SSL/TLS based communication, SSL/TLS termination and reverse-proxying for enduser applications. KSSL takes advantage of Solaris Cryptographic Framework (SCF), to act as an SSL proxy server performing complete SSL handshake processing in the Solaris Kernel and also using the underlying hardware cryptographic providers (SSL accelerators, PKCS11 Keystores and HSMs) to enable SSL acceleration and supporting secure key storage.
Before I jump into how to use KSSL for offloading SSL operations, here is some compelling aspects you may want to know:
- Helps non-intrusively introduce an SSL proxy server for Web servers, Java EE application servers and also applications that does’nt implement SSL.
- KSSL proxy listens to all secured requests on the designated SSL port (ex. HTTPS://:443) and renders a cleartext traffic via reverse proxy (ex. HTTP://:8080) port for the underlying Web or application server. All SSL operations including the SSL handshake and session state are performed asynchronously in the Solaris Kernel and without the knowledge of the target application server.
- KSSL automatically uses SCF for offloading operations to underlying hardware cryptographic providers with no extra effort needed.
- Manages all the SSL certificates independently supporting most standard formats (ex. PKCS12, PEM), the key artifacts can be stored in a flatfile or a PKCS11 conformant keystore (If you are worried about loosing the private key).
- Supports the use Solaris zones, where each IP identified zone can be configured with a KSSL proxy
- Delivers 25% – 35% faster SSL performance in comparison with traditional SSL configurations of most popular Web servers and Java EE application servers.
- KSSL can be used to delegate Transport-layer security and the applications may choose to implement WS-Security mechanisms for message-layer security.
Those are some compelling aspects of KSSL that are hard to ignore…. if you really understand the pain from performance overheads associated with SSL/TLS As I verified, KSSL works well with most common Web servers and Java EE applications servers.
Try it yourself
Certainly it is worth a try…and you should able to do it very quickly than configuring SSL for your web sever !
- Obtain your server SSL and CA certificates. If you just want to test-drive KSSL and considering to using a self-signed OpenSSL certificate.. just follow the example commands and make sure that your web server hostname is correct. If you choose to use a flatfile based SSL keystore, KSSL requires to have all your certificate artifacts (including private key and certificates) in a single file. If you need more OpenSSL help, read my earlier post.
Ex. To create a self-signed server certificate using OpenSSL (in PEM format).
openssl req -x509 -nodes -days 365 -subj"/C=US/ST=Massachusetts/L=Burlington/CN=myhostname"-newkey rsa:1024 -keyout myServerSSLkey.pem -out mySelfSSLcert.pem
Ex. Concatenate the server certificates in a single file.
cat mySelfSSLcert.pem myServerSSLkey.pem > mySSLCert.pem
- Configure the KSSL proxy service, assuming the secured requests are forwarded to an SSL port (ex. 443) and the reverse-proxy of your backend Web server listens to a non-SSL port (ex. 8080). Use -f option to identify the certificate fomat, to represent PEM (-f pem) and to represent PKCS12 (-f pk12). If the certificates are located in a HSM/PKCS11 Keystore, use -f pkcs11 to identify the token directory, -T to identify the token label and -C to identify the certificate_subject.
Ex. To configure the KSSL proxy service with SSL Port 443 and reverse-proxy port is 8080 using PEM based certificates and the passphrase stored in file (ex. password_file).
ksslcfg create -f pem -i mySSLCert.pem -x 8080 -p password_file webserver_hostname 443
Verify the KSSL proxy service under Solaris Service Management Framework (SMF) controls, the KSSL services is identified with FMRI svcs:/network/ssl/proxy.
svcs - a | grep "kssl"
Assuming your webserver in the backend listens at port 8080, you should able to test the SSL configuration provided by the KSSL proxy. Open your browser, goto https://webserver_host:443/ you should be prompted by the SSL dialog warning to accept a self-signed certificate.
More importantly, if your Solaris host is a Sun CMT server (based on UltraSPARC T1/T2 processor), KSSL automatically takes advantage of the cryptographic acceleration and no additional configuration is necessary.
Here is an unofficial benchmark that highlights performance comparisons with KSSL and other SSL options. The following shows the latency of an Web application running on Oracle Weblogic server using different SSL configurations (Certificate using RSA 1024) on a Sun CMT server (T5440) – To interpret the graph, make a note “Smaller the Latency means Faster”.
Adopting to Sun CMT servers (based on UltraSPARC T1/T2 processors) helps delivering on-chip cryptographic acceleration for supporting SSL/TLS and its cryptographic functions. With KSSL based SSL deployment, you will atleast get an additional 30% performance advantage while comparing with other Web server based SSL deployments. I heard that Intel Nehalem EX processors are expected to provide similar on-chip crypto capabilities, not sure ! Either way, using KSSL is a no brainer and it works. If you are itching the head to provide transport-layer security for your applications, this could be easiest way to go ! Ofcourse, it can help you score some points in those IT infrastructure security assessment checklists verifying for PCI-DSS, FISMA, HIPPA and/or similar regulatory/industry compliance mandates ! :-)