In my last article "SSL/TLS Certificates: What you need to know," I wanted to make sure that Internet users were aware of self-signed SSL certificates and what it meant to authorize them without a thorough verification process. In my infinite wisdom, I then proceeded to explain how to go about verifying the certificates:
- Obtain a copy of the certificate using a trusted delivery method, such as e-mail or fax.
- Compare the certificate in question to the copy received and see if the details are identical. If so, then the certificate is valid.
That sounds like a lot of fun, doesn't it. No one has the time or inclination to do all that just to visit a HTTPS Web site, including me.My bad
Ironically, while doing some on-line research after I published the article on SSL/TLS certificates, I happened to find myself staring at Firefox's "Unknown Authority" window. I'm muttering to myself: Man, I don't have time for this, and I OK'd the certificate. Whoa, it hit me like a ton of bricks, and to be honest I felt rather guilty. Here I am writing about certificate insecurity and I don't even listen to myself. I immediately decided to find a way to resolve this.TR members to the rescue
It didn't take long for a potential answer to surface. Members Kevin Feyer and Seanferd both enlightened me about efforts by a group of Carnegie Mellon researchers. I'm very excited after reading the researchers' white paper "Perspectives: Improving SSH-style Host Authentication with Multi-Path Probing" (pdf). First, the paper is very readable, to a point where I can even understand it (kudos to the authors). Second, although it's not infallible, the solution has a lot of possibility.
I'm still testing, trying to make sure the application does what it claims. So far so good, and because of that, I wanted to bring the application to the attention of TechRepublic readers. As I see it, there's no downside, and it has the potential to mitigate issues pertaining to certificate verification.Perspectives: Better than "TOFU"
Researchers Dan Wendlant and Ethan Jackson along with advisers Dave Anderson and Adrian Perrig of Carnegie Mellon are the developers of Perspectives, a novel and simple-to-implement idea for certificate authentication. I'm not able to improve on their definition of Perspectives, so here's what they say:
"The popularity of "Trust-on-first-use" (TOFU) authentication, used by SSH and HTTPS with self-signed certificates, demonstrates significant demand for host authentication that is low-cost and simple to deploy. While TOFU-based applications are a clear improvement over completely insecure protocols, they can leave users vulnerable to even simple network attacks.
Our system, Perspectives, thwarts many of these attacks by using a collection of "notary" hosts that observes a server's public key via multiple network vantage points (detecting localized attacks) and keeps a record of the server's key over time (recognizing short-lived attacks). Clients can download these records on-demand and compare them against an unauthenticated key, detecting many common attacks.
Perspectives explores a promising part of the host authentication design space: Trust-on-first-use applications gain significant attack robustness without sacrificing their ease-of-use. We also analyze the security provided by Perspectives and describe our experience building and deploying a publicly available implementation."
I must admit acronyms and I have issues, but TOFU quite easily defines a concept that I spent several paragraphs in a previous article trying to explain. To reiterate I'd like to revisit why TOFU is not in anyone's best interest:
- Automatically accepting a certificate creates conditions where the user becomes vulnerable to malicious attacks anywhere along the data path.
- On subsequent connections, if the received certificate is different from the cached certificate, the user must still determine whether the certificate is valid or not.
Perspectives consists of three distinct components: the notary authority, notary servers, and notary clients. In order to understand the process, let's take a look at each individual component:The notary authority is the overall controller that determines which notary servers are authorized to service notary clients. The notary authority creates a daily listing of authorized notary servers and their public keys. This listing is signed using the notary authority's private key and pushed out to all of the notary servers that it's responsible for. The notary server consists of two components -- a probing module and a database storage module:
- The probing module constantly monitors the Internet; looking for services that use certificates. If one is found the probing module pretends to be a client wanting to set up a secure link. The probing module takes the connection setup only to the point of where it receives the service's public key. At that point, the probing module drops the connection, since it has the information it needs.
- The database storage module is a repository containing signed (notary server's private key) entries for each service that the probing module is monitoring. Each entry consists of certificate information, the type of protocol used, and ways to contact the service. After time, the entry builds a history of observed parameters.
The following diagram (courtesy of the Carnegie Mellon researchers) depicts the interaction between the notary client and the notary server as well as the interaction between the probing module and network services such as Web sites that use SSL.
The next diagram (courtesy of the Carnegie Mellon researchers) is an example of the information sent from the notary server to the notary client in response to the notary client's initial certificate query.
With all the pieces now understood, let's walk through a complete transaction:
- I open Firefox and try to access https://www.mpksecuresite.com for the first time.
- The Web server for www.mpksecuresite.com sends a certificate to Firefox.
- Firefox and the notary client realize that the certificate is new, so the notary client sends a query to the appropriate notary server.
- The notary server looks up the certificate entry for www.mpksecuresite.com.
- After finding the information, the notary server signs the query response with its private key (signature) and sends it back to the notary client.
- The notary client has the public keys for all the notary servers that it uses, so it can verify that the query response from the notary server is valid and not from a spoofed notary server.
How the preferences are set up in the Perspectives client will determine how the client presents the information to the user. The following image is one example of how the preferences can be configured.
Perspectives provides a secure method for Internet users to obtain information about certificates published by services such as SSL Web sites. The information includes historical data from multiple notary servers, creating what may be considered a quorum, and allows Internet users to make an informed decision as to whether the certificate is valid or not. The following image is an example of the Perspectives application warning that the notary server's quorum duration is only 1.39 days (the configuration specifies two days). So it flagged the HTTPS Web site, allowing the Internet user to make a more informed decision as to whether to accept the certificate or not.
Making better decisions because of additional information is what makes Perspectives so appealing. The Carnegie Mellon researchers also did a great job of making Perspectives very configurable. Perspectives can be as granular or automated as you want. That should eliminate angst among users who just want to be secure and get their work done.
I use and recommend Perspectives. If there are some concerns, please refer to the researchers' paper on Perspectives. The paper goes into much more detail and should answer any questions you may have.
Michael Kassner has been involved with wireless communications for 40 plus years, starting with amateur radio (K0PBX) and now as a network field engineer for Orange Business Services and an independent wireless consultant with MKassner Net. Current certifications include Cisco ESTQ Field Engineer, CWNA, and CWSP.
Michael Kassner is currently a systems manager for an international company. Together with his son, he runs MKassner Net, a small IT publication consultancy.