This post is about secure internet protocols, and mainly about a bizarre phenomenon that prevents us from using SSL security in many situations where it would be useful. What is bizarre is that I don’t think anyone intends it, but there seems to be a natural reaction that leads to less secure systems.  While some might attribute this cynically to element who want to make money, I don’t think that is the real driver in this case.  Instead, it seems to be natural tendency toward the “security purist” who would rather be completely open and unprotected than to be partially safe.

Background

SSL – Secure Sockets Layer is a way to connect two computers together such that the traffic between them is encrypted.  Thus, it is private, and can not be understood by any machine between the two that are carrying the traffic.

HTTPS – This is just HTTP over SSL, a private way to fetch a web page.  Used when you access any business on the web.  Modern browsers show a lock icon, or some other way to indicate that the connection is protected.

There is a good argument that says that any web site that carries personal information should be accessed with HTTPS: your email (GMail, etc), your social site (Facebook, etc).

Is there a performance hit?  Yes, but given computing power today it is worth it.  15 years ago, in 1996, it was reasonable to worry about the extra processing required when encrypting data packets while sending/receiving.  But today processes are a hundred times more powerful.  A lot of types of software (i.e. Windows in general) has gotten much more complex and elaborate over the years, but data encryption is a simple calculation which has remained the same while processing power has increased.  The extra overhead of encryption is no longer worrying about.   Also, there is an initial exchange while setting up the SSL link, but the average access speed has increased as well, making this inconvenience very small.  The added benefit of privacy is so much greater that it easily out weighs the costs.

My job as a system architect means I am thinking about systems that people will be using in 5 to 10 years time.  The proliferation of computing devices (tablets, iPads, iPhones, Androids, web sites, personal clouds) means that the average person will be using dozens (if not hundreds) of these devices in the future.  Much like the “ubiquitous computing” concept proposed by John Seely Brown.  I personally think you will have agents deployed and working for you on these devices, and those agents will want to communicate to each other.  So there you have my vision of the future: a personal cloud and a swarm of agents exchanging your personal data all over the place.

To protect your privacy, to prevent a rogue coffee shop owner, or a deviant hotel employee from knowing your private details all the traffic should be over SSL, which nicely and neetly solves the problem of privacy.

Levels of Security

In prototyping such systems, I immediately ran into a huge roadblock.  SSL provides several types of protections:  it provides encryption which keeps the data private, and it also provides verification that the system is who it says it is.  Consider three levels of security:

• Level A – no encryption, no verification
• Level B – encryption, no verification
• Level C – encryption and verification

Level A is what you get if you use the regular HTTP web today: your traffic is unprotected, any server machine along the way can see what you are sending and there is no guarantee that the server you are communicating with is indeed the you think.

Level C is what you want to use when you do a business transaction.  You want the credit card number, or the password, to be sent over an encrypted channel so that nobody else can eavesdrop and steal your identity.  You also want some assurance that you really are connected to the “Wells Fargo” server, and not a man-in-the-middle pretending to be them, and stealing your information.

How do you verify that Wells Fargo is Wells Fargo?  Well, this requires a certificate authority.  Someone (a real person) has to contact a signing authority saying that a particular machine (IP address) is hosted by the company, and that they want to prove this.  The signing authority takes some steps to assure that this really is a person from the company, and not someone pretending.  This assurance can never be completely free or automatic.  It costs $400 to a couple thousand dollars to get a certificate that is provably trustable.

The swarm of agents working on behalf only need Level B: privacy.  Nobody is going to pay $400 to get a certificate to prove that your iPad is your iPad.  There are simple ways for you to have this assurance without a certificate. For example “matching” like you do for your blue tooth device.  This means of “matching” does not work for a public business site, but it is fine for your personal swarm.

Level B is also known as “self-signed.” What this means is that the person who set up the server, created a random pair of keys.  Those keys can be used to keep the traffic private, but nobody can guarantee who it was who created the keys.  The call is private, you just don’t know for sure who is on the other end of the line.

What is the Problem?

This is where it gets bizarre.  The Java libraries simply refuse to connect at Level B.  You can connect easily and exchange information at Level A, and it is easy to connect as well at Level C giving you full encryption along with host and certificate validation.   But, an attempt to connect at Level B is simply refused.  In response to an attempt to connect, an Exception is thrown, completely blocking the ability to connect and read data.

This is strange because clearly Level B is safer than Level A.  If you need to log in, passing a password over the line, it is far better to have that line encrypted, than to have the password exposed to every system between.

There is a way to work around this problem with Java, but it is very heavy handed: disabling all trust verification before the connection is made.  See “Working Around Java’s SSL Limitations” for a discussion of this.  This essentially blinds the program to whether the certificate is valid, but this is better than not being able to communicate at all. A much better approach is needed.

Consider Microsoft’s Outlook mail client.  HTML mail can be sent where the images are hosted on a server.  If the images are hosted on a plain unsecured HTTP server (that is, Level A) they will be (optionally) displayed.  If the images are hosted on a fully secure server (Level C) they will be (optionally) displayed.  But, if the images are stored on a self-signed server (Level B) they will not be displayed at all.  Instead, you will get an error message saying that there is no valid certificate.  What is really bizarre is that in the Level A case, there is no valid certificate either!  It seems as if the ability to verify a certificate becomes a requirement to verify a certificate, but it is perfectly happy to display if there is no ability to verify a certificate.

Browsers seem to handle this situation a little better.  Internet Explorer will display this warning.  Notice that it gives you the option to “Continue to the website (not recommended)”.  If you do continue on, it colors the address bar red and adds a prominent Certificate Error button that you can press to get details.

Mozilla does  a very similar thing when it warns that the connection is “Untrusted”.  There is a button saying “Get me out of here!” which is the clearly encouraged default action, and only if you say “I understand the risks” and ignore a stern warning that someone might be tampering with your connection, you can “Add Exception” to a list of sites where this is OK.  This situation is described on the Mozilla site as an error at best that you need to inform the web site owner about.

These warnings seem completely out of place.  Remember how Level B is safer than Level A in all situations?  These warnings don’t get displayed when you make a completely unprotected Level A connection to a random server!  Imagine that you run a free web site, and want to make web browsing safer by adding HTTPS, but don’t want to purchase a certificate.  Adding this level of security is more likely to frighten people away, than anything else.  Get me away from this evil site!  But why?

Is it a Conspiracy?

A cynic might suggest that this is a plot by the certification vendors to make it very uncomfortable to use self-signed servers.  They get people to contribute to the open source initiatives adding “unjustified suspicion” to any support for a Level B connection, because it is good for business.  Those more cynical suggest that it is the evil government that discourages HTTPS deployment so that it can more easily engage in illegal snooping. I don’t really think either of these is the case.

I think what is at work is the principle of the “Security Purist.”  That is, if you are adding security, you can not stop half way, because any shortcut in security is an opening for criticism or possibly a lawsuit.  If you offer no security, then things are OK.  But if you offer any promise of security, then you must go all the way.

It is very hard to argue for support of Level B connections.  Part of the problem is that people are still thinking of a Web 1.0 world, where a few big companies provide all the servers on the web.  Getting a certificate for a large, commercial site is not really an issue.  But in a fully Web 2.0 world, where everyone is a content publisher, and everyone has their personal web site, getting a certificate is an expense that is hard to justify.

Consider some of the non profit organizations I work with.  You can get a hosting site for your web site for around $5/month, but adding HTTPS to that normally costs an additional $10/month more.  The additional expense of course is for getting and maintaining the certificate.  Most low cost web sites (for schools, etc) can not afford the additional expense, so all their users are forced to interact in a completely unsecured and non-private way.  Generating and installing a self-signed key is about 10 minutes of work and costs nothing, but if you do that, users are scared away for not reason at all.  The site would be safer, but there is a huge disincentive.

If you look at the big picture, for a robust, safe Internet, all traffic should be SSL encrypted.  It would be much harder for terrorist to listen in and discover things.  It also would reduce the amount of accidental disclosures of private information.  It would make implementation of HIPAA privacy standards easier.  It would be a step in reducing identity theft.  Even those who believe that this incremental protection is very small, it is a fact that Level B connections are safer in all circumstances than Level A connections.

Action Items

Here is what needs to be done:

• The stigma of a self signed server should be removed.  A self signed HTTPS connection (Level B) should appear to the user substantially the same as an unsecured HTTP connection (Level A).  Level B is safer in all situations than a Level A connection, but this is really an infrastructure difference, a choice of the web server provider, and not one that the user should be too concerned about.
• Level C connections should continue to be clearly distinct to the user from A or B.  Level C has some trust assurance that the lower levels don’t have, and that is important for commerce.
• Encourage the use of safe connections.  The “No Certificate” indicator should appear both for Level A and Level B connections.  Additional details should explain in the case of Level A that there is no SSL connection and no certificate to verify.
• Support libraries should not prevent Level B connections.  Instead, there should be a property of the connection that indicates certificate validity, which can be queried by the calling program.
• Educate web site operators and users that self-signed server is safer in all circumstances than a completely unprotected server.