I.T. Security and Linux Administration

Nov 16 2011   12:10PM GMT

2048-bit SSL Keys

Eric Hansen Eric Hansen Profile: Eric Hansen

Citrix put out an interesting white paper recently detailing the reasoning behind using 2048-bit SSL keys instead of the (technically) de-facto 1024-bit keys.  While the white paper is also to market and sell their own products, it does raise some interesting points…but, most importantly is there really a need to raise the bit-strength of our SSL keys?

As a disclaimer to this entry, I am not going to comment on the statements made in the white paper in regards to upgrading to 2048-bit keys using their products.  I am instead going to focus on their remarks made in direct connection to SSL and 2048-bit keys themselves.

The first thing that struck me is Citrix saying that 2048-bit keys require anywhere from 5 to 30 times the processing power to handle the cipher than using 1024-bit keys.  I just wonder where they come up with this information.  If you have a lot of connections a second going to and fro your SSL-enabled website then yes, I can see the server struggling to handle the connections on a timely basis.  However, the majority of these sites already have load balancers in place (Facebook, Google, Microsoft, etc…) or are under heavy load during specific periods (the abundance of e-Commerce websites).  The only way I can see this really affecting end-user experiences is on an Intranet within a huge company (i.e.: Ford), but there would have to be an asinine amount of network traffic directed at that one server to even begin causing an issue there.

Another interesting bit of information they propose is to have an always-on SSL solution.  Basically what this means is that every connection is forced to go through SSL.  Now, this (if proper network management is not in place) will definitely cause issues in performance issues, as even images and such will be requested via SSL.  But again, this only really poses a problem if improper network configuration is in place.  I would also like to point out that in the white paper, they mention that “Facebook offers their users the choice of encrypting every page using SSL.”  Yes, Facebook (after a very long wait) finally set up SSL, but there is an issue with that now.  Most (if not all?) of the applications/games/etc… on Facebook’s servers will not work if you are viewing Facebook with SSL.  That right there renders browsing Facebook with SSL pointless if you are going on there to play games or what have you.

Next, if you look at page four, figure 3, I believe the data representation is a little skewed.  I know the current Web 2.0 generation is in a (micro)blogging fad and all, but I would still like to think that having my bank’s entire website SSL-forced (or at least enabled) is more of a priority than having Facebook or Google+ entirely encrypted.  What does it mean if someone tampers with your data midstream when you are posting on your wall compared to trying to transfer (or even just authenticate) in your bank account system?  Now I could be wrong on reading the data presented, but it looks just like this to me, and I feel they are either trying to pull the wool over our eyes, or saying social media is more important at work than bank transactions.

Really, I don’t see a need for 2048-bit SSL keys by reading this white paper.  Does it offer more security?  Yes, by a landslide.  Does it have a trade-off?  Doesn’t everything in I.T.?  But what is the real reason?  The only places I can see 2048+ key strengths being useful is in governmental situations and where highly sensitive information is being transferred (and I don’t view Facebook wall posts to be sensitive information).

 Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: