SSL/TLS certificates: Perspectives helps authentication

By Michael Kassner

Takeaway: Self-signed SSL certificates are an authentication nightmare. A group of researchers at Carnegie Mellon developed Perspectives, an application that potentially will remove some of the FUD. I’d like to explain the application and make a case for installing it.

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:

1. Obtain a copy of the certificate using a trusted delivery method, such as e-mail or fax.
2. 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.

How Perspectives works

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 notary client is a Web browser add-on that contacts the notary server for one of two reasons. The certificate for the contacted Web site isn’t in the Web browser’s database or it doesn’t match an existing certificate.

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:

1. I open Firefox and try to access https://www.mpksecuresite.com for the first time.
2. The Web server for www.mpksecuresite.com sends a certificate to Firefox.
3. Firefox and the notary client realize that the certificate is new, so the notary client sends a query to the appropriate notary server.
4. The notary server looks up the certificate entry for www.mpksecuresite.com.
5. After finding the information, the notary server signs the query response with its private key (signature) and sends it back to the notary client.
6. 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.

How does this help?

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.

Final thoughts

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.

Source URL:-Techrepublic.com

SSL: Broken even more

By Michael Kassner

Takeaway: Lately, security conferences have been bad news for SSL. The recently held Black Hat DC 09 was no different, with independent security guru Moxie Marlinspike explaining quite convincingly how he was able to completely bypass SSL security.

In January I wrote an article, SSL: Really broken this time, in which I described how forged certificates could be created if the signing Certificate Authority used the MD5 algorithm for signing. That wasn’t too difficult of a problem to rectify; it just required Certificate Authorities to use SHA-1 instead of MD5. Even so, most people in the know realized that it won’t be too long before SHA-1 has the same problem as MD5

SSLsniff

Well, I’m afraid that cracking SHA-1 is the least of our problems. You may remember Moxie Marlinspike, he’s the developer of a sophisticated hacking tool called SSLsniff. The application exploits vulnerabilities in Internet Explorer, allowing Man-in-the-Middle (MitM) attacks even if SSL connections are used. Microsoft eventually fixed the vulnerabilities by disallowing leaf certificates to act as signing certificates.

Even with the vulnerability fixed, SSLsniff is still a powerful tool. As evidence, SSLsniff was used to demonstrate MitM attacks by the group of cryptographers who discovered the MD5 exploit I mentioned earlier.

SSLstrip

Moxie Marlinspike’s new and improved tool is called SSLstrip. Quite simply, SSLstrip allows an ill-intended attacker to capture sensitive personal information without even worrying about encryption. Moxie Marlinspike decided to sidestep the encryption process once he realized that users almost always request Web pages using the http (unencrypted) prefix. That’s even the case for the more confidential Web sites like those provided by financial institutions as shown below:

After the initial portal page is brought up, https is enabled after some user intervention as the following image shows:

SSLstrip is simply a MitM proxy that advantages this flaw/oversight in the https process by stepping in between the user and in this case the bank’s Web server. Let’s look at the process using me as the guinea pig:

1. I enter the URL http://www.usbank.com into the Web browser.
2. I then type my user name in the appropriate box and hit enter.
3. SSLstrip captures the URL and my username.
4. SSLstrip connects to the USBank Web server and provides my username.
5. SSLstrip then returns the new Web page provided by the bank Web server to my computer.
6. I provide my password and hit enter.
7. SSLstrip once again captures that information and transmits it to the bank Web server. As far as the bank Web server knows, I’m officially logged in.
8. SSLstrip once again passes the new Web page provided by the bank Web server to my computer. I then go about my business.

Something is wrong though, how come the “s” is missing from http in the URL? I thought the bank’s Web site was secure. It’s not there because the SSL connection was setup between my attackers’ computer and the bank’s Web server. I was getting all the correct Web pages sent to my computer, but not over secure channels. Guess who now has my log in credentials?

I realize that an observant user would more than likely be aware of the sleight of hand taking place here, but then I suspect that many more will be fooled by this. For more details about the exploit, please view Moxie Marlinspike’s Black Hat presentation New Tricks for Defeating SSL in Practice(pdf). He did a great job explaining the entire process.

Even sneakier

In Moxie Marlinspike’s presentation, he points out a few other techniques that can be applied to make the unsecure Web page look more convincing. Most Web browsers display the favicon supplied by the Web server right next to the URL in the address bar. What SSLstrip allows you to do is replace the favicon with one of your choosing.

By doing this many more people will be fooled as they have been told to look for a closed lock and if it’s there then they can be assured that they are safe.

It’s even possible for the attacker to supply a real SSL connection to the requesting computer with a URL that’s almost identical to the one asked for. The difference being a few extra characters at the end. Moxie Marlinspike explains in the next slide:

Change the Web browser

We humans are creatures of habit; I doubt that anyone would argue that. Knowing that, I honestly can’t say that I’d catch the deception every time myself. One good thing is that this dilemma has been talked about by others. I was fortunate that TechRepublic’s managing editor Jason Hiner alerted me to George Ou’s article HTTPS web hijacking goes from theory to practice.

The article explains that developers need to give Web browsers enough intelligence to know whether the connection should be SSL encrypted or not and if encryption isn’t occurring to disallow the connection. George also mentions that Google is working on this very problem in their early versions of the Chrome 2.o Web browser. Hopefully other Web browser developers will follow suit.

Final thoughts

First, I’d like to thank Black Hat for the use of their logo and Moxie Marlinspike for the use of his presentation slides in this article. I also admire his wanting to make everyone aware of this potentially serious attack vector.

I realize that this exploit is one that requires inattentiveness on our part. Fortunately, most people I talk to mention that they wouldn’t get caught by this. Just to test that theory, think back to the last time you went to a Web site that used SSL. Did you check the URL? Were you sure that the traffic was encrypted? I didn’t.

Worried about security issues? Who isn’t? Delivered each Tuesday, TechRepublic’s IT Security newsletter gives you the hands-on advice you need for locking down your systems and making sure they stay that way. Automatically sign up today!

Source URL:-http://www.techrepublic.com/blog/security/ssl-broken-even-more/872

Google Search over SSL has an oops

By Michael Kassner

Takeaway: Google now provides SSL encryption capabilities for their search function. But, there is a problem that you need to be aware of.

Google now provides SSL encryption capabilities for their search function. But, there is a problem that you need to be aware of.

————————————————————————————–

According to Google’s Web Search Help blog, the search giant has decided it’s important to keep search inquiries from the prying eyes:

“With Google search over SSL, you can have an end-to-end encrypted search solution between your computer and Google. This secured channel helps protect your search terms and your search results pages from being intercepted by a third party. This provides you with a more secure and private search experience.”

TechRepublic’s Chad Perrin recently penned an article about the benefits of SSL-encrypted Web searches. He also advises caution as some searches are not protected by SSL Security encryption and under certain circumstances SSL is vulnerable.

When I learn that an application claims to use SSL, I like to check and make sure for myself. Sometimes there are surprises and when it comes to security; that’s not a good thing. I fired up Wireshark and, as stated above, the search traffic was gibberish as shown below:

That’s great. But I did see something in the packet traffic that I didn’t understand, so I went to Laura Chappell’s Web site. I have taken several of her classes and consider her one of the foremost experts when it comes to analyzing packets. I did not find what I was looking for, but I did come across quite a surprise.

Cached Link

In their search results, Google has what they call a cached link:

In theory, using a cached link makes sense, as explained by Google:

“Google takes a snapshot of each page examined as it crawls the web and caches these as a back-up in case the original page is unavailable. If you click on the “Cached” link, you will see the web page as it looked when we indexed it. The cached content is the content Google uses to judge whether this page is a relevant match for your query.”

To their credit, if the cached link is clicked on, you will know it. Google prominently displays a window explaining the loaded page is a snapshot of the actual Web page and may not be current:

Ms. Chappell found out that the cached link traffic is not encrypted. I went back to testing, and sure enough, if the cached link is clicked on, it reverts back to http. Notice the URL in the above slide.

Search query sent unencrypted

That’s to be expected, but what’s not expected is that the original search information is sent to the Google Web-cache server in the clear. Let’s see if we can capture that. The first slide below is the response to my DNS query for webcache.googleusercontent.com. That’s where the cache is located:

The next slide is that of the traffic my computer is sending to webcache.googleusercontent.com. As you can see, the highlighted packet contains my original search query:

Final thoughts

According to Google’s above statement, all search traffic is supposed to be encrypted between our computers and their servers. It’s not in all cases, and I felt it important to make sure everyone is aware of that.
  

Source URL:-http://www.techrepublic.com/blog/security/google-search-over-ssl-has-an-oops/3775