Web Services Over SSL - Is It Really That Slow Like They Say?
My answer is "no" .
I am working on solution where there is no Windows Active Directory Domain so we cannot utilize our beloved Kerberos and Windows Integrated Authentication saving big on configuration and management while taking advantage of increased security it offers.
Other technique that we thought that could give us a lots of benefits in terms of strong authentication, transport level protection, and interoperability was using Client Certificates.
Here is the scenario.
ASP.NET web page calls on ASP.NET Web Service on separate machine. Think of scenario where Internet facing ASP.NET web site calls on Web Service deployed in internal zone:
The other scenario would be so called B2B scenario where intranet facing ASP.NET web site calls on Web Service over the Internet:
Another scenario would be calling Java Web Service.
Not that friendly for Windows Integrated Authentication.
The question we asked ourselves was - will it be fast enough? The following post by my colleague Eddie - Fast and Secured: Performance Impact of SSL gave us a lots of hope. But it discussed SSL between Web Browser and the Web Server. Web Browser (IE) has nice feature of caching SSL state so what depicted below happens less thus improving performance (think of OLEDB Connection pooling and you got the idea):
Well, our beloved Internet Explorer does a great job, what about .Net?
After some research we happily discovered the following:
https://msdn2.microsoft.com/en-us/library/system.net.httpwebrequest.aspx
The Framework caches SSL sessions as they are created and attempts to reuse a cached session for a new request, if possible. When attempting to reuse an SSL session, the Framework uses the first element of ClientCertificates (if there is one), or tries to reuse an anonymous sessions if ClientCertificates is empty.
That was encouraging and I decided I need to see it my eyes, so I set sample code and deployed to my lab domain. I also have used diagnostics technique described in Use Sysinternals DebugView To Diagnose The Application. When I fired up DebugView this is what I saw:
Each pair of records reflects on single Web page access telling me how many milliseconds was spent on each action to complete during the page processing.
Notice first two records - one for Web Service proxy creating and adding certificate to it:
Stopwatch stopwatch = new Stopwatch();
stopwatch.Start();
//GET HOLD ON CERT
X509Store store = new X509Store(StoreName.My, StoreLocation.CurrentUser);
store.Open(OpenFlags.ReadOnly);
X509Certificate2Collection certs = store.Certificates.Find(X509FindType.FindBySubjectName, "w3w1", true);
X509Certificate2 cert = certs[0];
//CREATE WEB SERVICE PROXY
Service1 proxy = new Service1();
proxy.ClientCertificates.Add(cert);
Debug.WriteLine("Web Service Proxy Created: " + stopwatch.ElapsedMilliseconds.ToString());
and the second one is actual Web Service call:
// CALL ON WEB SERVICE
string result = proxy.HelloWorld(cert.Subject);
Debug.WriteLine("Web Service Call Completed: " + stopwatch.ElapsedMilliseconds.ToString());
Notice that all subsequent calls are pretty fast. It should prove that SSL session caching is in place also with .Net as promised. Cool.
Conclusion
While these numbers have been taken on lab environment for super simple scenario it can serve as talking point when considering applying SSL to protect your sensitive data to its way to downstream servers. Also client certificate authentication should be considered as a strongest authentication available today when Kerberos is not available.
Comments
- Anonymous
September 04, 2007
Interesting article, something I have always wondered about with SSL but have never had the time, motive or hardware to test is the performance impact of SSL when using a hardware based SSL accelerator.Might be interesting to gather metrics and compare non-ssl, ssl, and ssl with an accelerator. - Anonymous
September 04, 2007
Good point.My take is like this. If w/o hardware accelelrator the performance is good then with it the performance should only be better.