Network News

X My Profile
View More Activity

Firefox Plug-in Offers Clarity on Web Site Security

A new security add-on for the latest version of Firefox is available to help users make better sense of a controversial new feature of Firefox 3 that blocks users from visiting a Web site when the browser detects a problem with the site's security certificate.

The "Perspectives" add-on for Firefox 3, developed by researchers at Carnegie Mellon University, tries to help users make more informed decisions about what to do when the browser warns about a problem with the site's secure sockets layer (SSL) certificate.

Web sites use SSL to encrypt data transmitted to and from the visitor's browser, thereby thwarting any would-be eavesdroppers. SSL certs also offer rudimentary authentication of the identity of the cert holder: Most SSL certs are third-party validated, meaning that some level of checking was done by companies like Verisign or Microsoft to verify that the entity that applied for the cert was the rightful owner of the domain name attached to it.

But for a variety of reasons, a non-trivial number of Web sites use SSL but self-sign their certs. In previous versions of Firefox, users visiting sites that are self-signed would be presented with a pop-up box asking the user to approve or disapprove the untrusted cert. Firefox 3 blocks users from visiting sites with self-signed certs. It also blocks people from visiting sites that have expired third-party validations.

Here's the shortcoming of the Firefox 3 approach that Perspectives is trying to address: While users can click through four different dialog boxes and add the unrecognized SSL cert as an "exception," the average user still isn't likely to know whether or not doing so would be a good idea.

The Perspectives plug-in will automatically override the Firefox 3 security error page without scaring the user if the site appears legitimate. To determine that legitimacy, Perspectives queries at least four different "notary" servers and ask them for their observations about the cert in question. The servers respond with information about which key they see being offered by the Web site in question at the moment, and which keys they have seen in the past for that same domain.

venafi.jpg

According to Firefox developer Jonathan Nightingale, Firefox 2's cert warnings were too easy for users to either ignore or just hit "okay" without considering the security implications. Indeed, according to a study by Venafi security last year, at least 40 percent of all users do just that when presented with a security warning (that number is likely higher: 16 percent said they were "not sure" what they'd do).

"With a self-signed certificate, we don't know whether to trust it or not," Nightingale wrote in a blog post last month. "It's not that these certificates are implicitly evil, it's that they are implicitly untrusted -- no one has vouched for them, so we ask the user. There is language in the dialogs that talks about how legitimate banks and other public web sites shouldn't use them, because it is in precisely those cases that we want novice users to feel some trepidation, and exercise some caution. There is a real possibility there, hopefully slim, that they are being attacked, and there is no other way for us to know."

This blocking behavior of Firefox 3 can be very useful if the user goes to log in to https://www.example and a hacker lurking on the network tries to feed a the user a fake SSL certificate for example.com to intercept and/or redirect any traffic destined for it.

gmailper1.jpg

However, there are plenty of instances wherein Firefox 3 throws up scary warning pages when the user is at a completely legitimate site. Visit https://www.gmail.com with Firefox 3 for the first time and you'll encounter the browser's warning page. The same goes for https://mail.yahoo.com and https://www.us.army.mil, to name just a few.

With Perspectives, if enough of the notary servers agree that the disputed SSL key has been used for that site for a long enough period of time, then the plug-in skips the Firefox 3 warning page and sends the user along to the requested site. If there is anything less than a majority opinion from the notary servers, the plug-in adds a red bar to the Firefox warning page, that reads: "Suspected attack: Perspectives was unable to verify the security of your connection to this website."

I should note that if you are behind a proxy or ultra-restrictive firewall, you may also get this message if Perspectives is blocked from querying the notary servers -- in which case the add-on is likely to be more of a nuisance than a help. Perspectives worked fine for my Firefox 3 install at home, but my computer at work was blocked from visiting the notary servers.

By Brian Krebs  |  September 2, 2008; 1:12 PM ET
Categories:  Fraud , From the Bunker , Safety Tips  
Save & Share:  Send E-mail   Facebook   Twitter   Digg   Yahoo Buzz   Del.icio.us   StumbleUpon   Technorati   Google Buzz   Previous: FBI Warns of Hit Man Scam Resurgence
Next: Number of Bot-Infected PCs Skyrockets

Comments

Anyone who was paying attention to the recently disclosed BGP spoofing attack methods would know that the assumptions this plugin is based on are fallacious.

There is really no excuse for using self-signed certificates any longer. Authority-signed certificates can be had for less than $25 annually.

Posted by: antibozo | September 2, 2008 1:31 PM | Report abuse

I can't get to http://icasualties.org/oif/ page, since I downloaded FF3. Tells me site my have malware. And this sight is run by WAPO, isn't it? It is all nonsense I think...the site is fine.

Posted by: jonst | September 2, 2008 2:02 PM | Report abuse

jonst, further info about that is here:

http://safebrowsing.clients.google.com/safebrowsing/diagnostic?client=Firefox&hl=en-US&site=http://icasualties.org/oif/

If you want to proceed to the site, just click on "Ignore this warning".

Posted by: antibozo | September 2, 2008 2:10 PM | Report abuse

Just to note, for whatever reason, most all SSL .mil sites use self-signed certs. Unsure why the military, with all their worry over being hacked and what not, don't bother to deploy front-facing, legitimate security.

The other examples use legitimate certs, only the domain name for the cert doesn't match the web site name (login.yahoo.com versus mail.yahoo.com, etc).

Posted by: A note | September 2, 2008 3:29 PM | Report abuse

I don't know about most SSL .mil sites, but the example Bk gives, https://www.us.army.mil/, does *not* use a self-signed certificate. It uses a certificate signed by a non-public CA, with subject name "C=US, O=U.S. Government, OU=PKI, OU=DoD, OU=USA, CN=www.us.army.mil/emailAddress=raymond.wilson2@us.army.mil".

That is, the DOD has their own PKI, and presumably they configure the CA certificate in their SSL clients.

Posted by: antibozo | September 2, 2008 3:45 PM | Report abuse

My bad, cut-and-paste error. The CA's subject is "C=US, O=U.S. Government, OU=DoD, OU=PKI, CN=DOD CLASS 3 CA-7".

Sorry about that.

Posted by: antibozo | September 2, 2008 3:47 PM | Report abuse

Posted by: votetheday.com | September 2, 2008 5:06 PM | Report abuse

What are the four clicks for importing a self-signed cert presented by a web site? I know how to import a cert if I have a copy of it, but FF 3 doesn't seem to present any option like "Trust this cert for this session" or "Trust this cert permanently". Ever since I upgraded to FF 3 I have no idea how to get to a site with a self-signed cert unless I have some way of getting their cert separately. I think this is the worst feature I've seen in FF since 0.5. It's fine to warn me, but give me the option to visit the site if I want to.

Posted by: Mark | September 2, 2008 5:21 PM | Report abuse

@Mark: from the security warning page, just click "add an exception". I actually like this better that the previous incarnation of this feature.

Posted by: Chris Schultz | September 2, 2008 5:35 PM | Report abuse

disclaimer: I am one of the authors of the Perspectives project

Dear antibozo,

In my opinion, both of your comments above are either ill-informed or misleading.

First, you write "Anyone who was paying attention to the recently disclosed BGP spoofing attack methods would know that the assumptions this plugin is based on are fallacious." One must remember that Perspectives also takes key history into consideration, meaning even if an EXTREMELY powerful BGP attacker were to compromise nearly all paths to the destination for a period of time, this recent certificate change could be detected as suspicious.

In addition, if an attacker was that powerful, he/she could easily also fool the email-based verification mechanisms used by many certificate authorities today. Thus, even "trusted" CA's are vulnerable to powerful attacks. The Perspectives project doesn't claim to provide bullet-proof security (no one can at a reasonable price). Instead, tries to strike a good trade-off between cost and security.

Second, you argue that a certificate signed by the DoD is fundamentally different from a self-signed cert. In fact, from a security perspective there is no difference between a "truly" self-signed cert, and one signed by a CA for which the client has no public key. In both cases, such certificates are completely insecure unless the client has previously received key material via some trusted channel.

Posted by: dan wendlandt | September 2, 2008 5:47 PM | Report abuse

@Chris: Thanks for the suggestion, but I don't have the option you refer to. I pasted below the entire text that appears on the security warning page when I go to the GMail link Brian gave in the article.

Besides the text below, I also get eight buttons: Ping Server, Trace to Server, Ping Myself, Trace to Myself, Retry This, Google Cache, Wayback, Whois. As you can see, there is no option to add an exception. Not sure why my FF would be different than anyone else's. I'm running the latest version, 3.0.1, on Windows XP.

Cannot Complete Request

www.gmail.com uses an invalid security certificate. The certificate is only valid for mail.google.com (Error code: ssl_error_bad_cert_domain)

Let's try to troubleshoot the problem:

* Check Internet connection: Your Internet connection seems to be working.
* Try to perform some diagnostic tests:

General troubleshooting tips:

Additional information about this problem or error is currently unavailable.

Posted by: Anonymous | September 2, 2008 9:54 PM | Report abuse

FF3 sucks. I went back to 1.5. Happy again.

Posted by: Rev. Dave | September 2, 2008 10:15 PM | Report abuse

OK I found out hwy I wasn't seeing the link to add an exception. The extension "Broadband Speed test and Diagnostics" adds its own error page when there is an error loading a page. I'd been using it so long I didn't realize it wasn't the standard FF error page. And the extension doesn't provide a link to add an exception when there's a bad cert. Bad on them.

But I also found that I have to fave the following setting set to true in about:config

browser.xul.error_pages.expert_bad_cert

It's default value is false. Bad on FF for defaulting it this way.

Posted by: Mark | September 2, 2008 10:40 PM | Report abuse

dan,

You may be overreacting to my statement. I did not say that notaries are useless. I said the assumptions are fallacious. I'm sure you take pride in the accomplishment of your project, and that it has been a good experience for you. But I am not convinced it's good for overall security. Bk's article fails to question the methods involved in Perspectives, or point out where it can fail.

I also said that there's no good reason for Perspectives, because *no one* should be using self-signed certificates. I don't regard mechanisms that enable broken SSL/TLS to function as good for security, because it's really no problem to make SSL/TLS work correctly. These aren't the days of $500 certificates any more. There's simply no excuse for self-signed certificates these days; CA-signed certs are dirt cheap now. So putting significant effort into letting people set up more self-signed certificates is pretty much the opposite direction I think we should be going in.

Personally, I'd rather see the kind of effort you folks have put into Perspectives directed at DNSSEC implementation tools and DNSSEC-based PKI, so that certificates are no longer even necessary for most secure applications (instead get public keys from secure DNS). SSL/TLS is broken enough as it is--you yourself point out the flawed verification process--and throwing more energy at the X.509 PKI is the opposite of what I'd like to see.

(One thing that is unclear to me about Perspectives is whether it consults notaries for certificates that can be validated via the CA chain. One statement in your paper is, "The client application contacts the notary whenever it receives a key from a service that does not match an existing entry in its cache." This implies to me that notaries are consulted even for validated certificates if they haven't been seen before. On the other hand, elsewhere, the paper states, "However, we believe that PERSPECTIVES provides a simple and cost-effective way to improve the attack resistance of services that currently either use Trust-on-first-use or are completely unauthenticated," which implies that the strategy is used only for certificates that cannot be validated otherwise. Obviously the threat models differ depending on this.)

As far as key history, keys change. Some people use multiple keys for the same subject. So key history may work for a large number of sites, but it will break some of them. Yes, I know you have an elaborate system of tracking multiple keys and trying to develop quorum based on key consistency over time. This is just more complexity that ordinary users won't understand. You're giving them a "trust" slider they can set, but they still won't understand the implications of that setting.

BGP-based route hijacking can go on for a long time without being noticed. We have no information regarding how much BGP hijacking has been going on, if any, so it is simply not possible to make any statements about how "powerful" an attacker would have to be. The basic requirement for an attack is administrative access to a border router for an autonomous system, and there may be plenty of people legitimately in such a position with larceny in their hearts, let alone intruders. Believe it or not, there are a lot of insecure routers out there. A lot of NOCs are even still using telnet.

I have been decrying the email-based SSL verification system for years. Nonetheless, I can't point to a single example where someone has actually gotten a fake certificate for a legitimate domain by subverting this system. Can you? And in the case where the attacker is so "POWERFUL" that he is able to do this, how does Perspectives help? What will help is DNSSEC and DNSSEC-based PKI.

Finally, I did not in any way argue, as you claim I did, that a certificate signed by the DoD is "fundamentally different" from a self-signed cert, or imply that certs signed by an unknown CA are any more secure than self-signed certs. I wrote simply that the certificate for the .mil site Bk identifies is not a self-signed cert. Obviously that is no more secure for a member of the general public than is a self-signed cert. *Equally* obviously, that cert is not intended to provide security for the general public; it is intended to provide security for DoD users who have the DoD CA certificate installed in their clients, and these clients *will* be able to validate it.

Posted by: antibozo | September 3, 2008 12:30 AM | Report abuse

Mark, I do not need to modify the default false setting of browser.xul.error_pages.expert_bad_cert to get the "Or you can add an exception..." link. It shows up by default. Something else must still be interfering with the behavior of your Firefox.

Posted by: antibozo | September 3, 2008 12:36 AM | Report abuse

I also have to wonder why the extension was written in C/C++ rather than chrome Javascript. There's a lot of opportunity for stack and heap overflows in that code, and a whole lot of code to audit. What functions did Perspectives require that were not provided in the XPCOM Javascript interface?

Posted by: antibozo | September 3, 2008 1:47 AM | Report abuse

To answer my own question: for the SSH side of things you wouldn't be able to use XPCOM. Still, a lot of opportunities for a mistake.

Posted by: antibozo | September 3, 2008 1:50 AM | Report abuse

The new version of Firefox blocked input from my virus checker AVG. I chose to keep the virus checker and removed Firefox, which had been my primary browser, from my computer. I was told the reason inputs were blocked by Firefox was so adds could be put on my compter. Comments??

Posted by: Sid | September 3, 2008 7:21 AM | Report abuse

@Sid: Yes. Use the Extension/Add-on called "Adblock Plus".

Posted by: Dan | September 3, 2008 7:51 AM | Report abuse

@ antibozo and dan: Thanks for keeping your dialogue instructive and civil. We all appreciate it.

Posted by: Pete from Arlington | September 3, 2008 11:15 AM | Report abuse

Listed as being out of date and not available for Windows?

Posted by: Dave | September 3, 2008 11:24 AM | Report abuse

Good information---if I could make sense of it. Many (most?) computer users have no idea what all this stuff means. The sentence that mentions "the average user" alludes to this problem. I have been using computers since the mid-1980s and using the World-Wide Web since the late-1990s, and like to think of myself as computer-literate. But I only poorly understand SSL, certificates, and signatures. There is so much change in technology these days that it is hard to keep up. It would be interesting to see what percentage of computer users are aware of the technical issue discussed here AND UNDERSTAND IT. I'll bet the percentage is very low. Gotta go---it's time for me to get educated...

Posted by: Dave Beedon | September 3, 2008 4:57 PM | Report abuse

@antibozo, thanks for the very informative discussion.

I agree with your sentiment that SSL/TLS is broken -- the tradeoff of $25 and cheaper certs from cut-rate CAs that are now "trusted" by the major browsers is that there is no verification. DNSSEC certainly offers more promise for real security.

But, accepting as a premise that SSL/TLS is broken and even "trusted" CAs aren't entirely trustworthy, the "web of trust" approach Perspectives is using appeals to me. It makes sense to score as "more trusted" certs that are long-lived and in widespread use (since many users using an untrusted cert and pinging the notaries are effectively acting as key signers). Yes, it's a band-aid, it isn't real security, and it requires bad, invalid certs to be used for a long time before they become "less bad." But, I think it is still useful in a niche role, and as a band-aid for the reality of regular users out there encountering mismanaged certs every day -- a regular gmail user going to log in and seeing a cert error *might* be savvy enough to contact Google and say "fix your cert!," but he still has to decide whether to risk logging in and using the site that day, and Perspectives helps inform that decision.

@dan, thanks for this project. I have one comment though -- I installed it and tried it out on a few sites I know to have bad/self-signed certs (I deleted my permanent exceptions from Firefox's database first). I was a bit surprised to see them get a happy green checkmark, even though they were new to the notaries so they got an age of "0" (which means, zero evidence to trust them, right?). Maybe the "high security" preference (with minimum age of 2 days) would be a better default?

Honestly, even 2 days/75% seems too short to me. Someone doing a man-in-the-middle or spoof attack might well have the time to overcome that.

Posted by: picasticks | September 3, 2008 5:25 PM | Report abuse

I still use Windows 98 Second Edition with Mozilla Firefox 2.x the latest version currently on 2.x is version 16 and it works great with the occasional crash. I also use Windows XP Professional on a multi-boot computer and mainly like Windows XP Pro. because it can play Itunes unlike Windows 98 Second Edition. You get a few other nice extras with XP but it is not worth the bother or the fact that someone easily hacked it when connected to VPN with APS Network in September 2007 and all the hackers did to Windows 98 Second Edition was cause a denial of service error and that was it. However, the hackers stole information on me and the 1st grade students and now lawyers, DHS and DOD are all investigating and I am slowly but surely gathering all needed material for DHS as well as trying to restore my life from identity theft which takes a lot of time. whew

Posted by: Dan W | September 4, 2008 3:16 AM | Report abuse

Having tested out the extension and reviewed some of the extension and server source code I can say a few more things about the system.

The default behavior is to consult Perspectives for certs that cannot be validated. You can set it to test all certs, however. This clarifies a question I posted earlier.

There are some architectural and code quality issues I would challenge the developers to consider further:

1. The notary services can be used to conduct port scans.
2. Once there are a lot of notaries, it's possible the services could be used to conduct a denial-of-service attack.
3. The transport is UDP, and messages contain no nonce, so notary replies are replayable.
4. The notary forks a separate process for each request which then execs a separate binary to do the actual key probe, with a limit on the number of concurrent requests. Thus it should be fairly easy to DoS a notary. An attacker can fire off a continuous stream of bogus requests to keep notaries too busy to do any useful work.
5. The interprocess message formats are sloppily defined. Some but not all messages require internal null termination; some messages have different maximum sizes than others.
6. The code has a lot of statically defined buffers and corresponding code that restates buffer sizes numerically rather than using sizeof(). This makes code error-prone; when someone changes a buffer size, they have to find all of the places the size was explicitly stated and change those to match.
7. The code contains complete copies of openssl and openssh that have been modified in place, rather than simply relying on an external build of these tools. The changes are not provided as diffs. This makes it difficult to maintain these underlying codebases as new releases address vulnerabilities.
8. Notary queries each leak two bytes of heap memory because sig_len is uninitialized.
9. Notary replies could leak notary stack data because messages are assumed to contain null termination.
10. It is not clear that internationalized domain names are handled properly.
11. Notaries sign MD5 digests in replies, and use MD5 fingerprints for keys. MD5 is no longer considered safe.
12. There are insufficient checks on notary replies. A compromised notary can crash clients, or possibly compromise them.
13. Replies could eventually exceed UDP maximum datagram size as key info data structures grow.

A few suggestions I would make to the developers:

A. Add a nonce to the messages.
B. Redefine the message encoding scheme. Consider using ASN.1 to encode messages. Or consider using DNS to encode and transport messages.
C. Use TCP transport, preferably over HTTP, so that firewalls don't get in the way. Consider simply using HTTPS with preloaded certificates instead of the existing transport and signature scheme.
D. Encrypt requests, and remove service ids from replies (use a secure transaction id instead). A notary eavesdropper can observe each SSL service someone connects to, both host and port; this is more exposure than DNS creates. If someone is using the Perspectives-enabled SSH, an eavesdropper can observe what SSH services that person connects to.
E. Add complete integrity checks on all sizes in messages.
F. Make the scanner functions shared libraries and dl_open them in the main scanner process. You can then use either threads or a simple fork (with no exec overhead) to fire off each probe.
G. Make your SSL scanner a separate program (or shared library entry point) that simply builds and links against the openssl libraries. Don't include a modified version of a possibly out-of-date copy of openssl with your server code.
H. Ditto for openssh (openssh builds a libssh.a; have builder do an openssh build from current source to provide this).
I. Specify the signature and fingerprint digest algorithms in replies, and allow multiple digests. Use SHA256 by default, and be ready for the next digest algorithm.

Posted by: antibozo | September 4, 2008 11:58 AM | Report abuse

Hi antibozo and others,

wow, I step away from a thread for a while and it seems like i have missed a lot (btw, there is a comment from a "Dan W." above that is not me).

Meta-comment: perhaps this discussion is better done via email, not in this cumbersome comment format. Or do you require anonymity for some reason? I'm always up for a spirited debate. My email, and my name, is on the project webpage.

On a high-level, I think we could agree that the SSL/TLS model with HTTPS leaves much to be desired. But I still feel that you're missing what I see as the larger point with respect to the Perspectives project.

Three things I'd like to highlight:

First, you point out that cert's are "dirt cheap" without mentioning that they are dirt cheap only because CA's use simple "email bounce" verifications to grant them. Tell me, if an attacker is running BGP attacks in the core, don't you think they'd be able to hijack prefixes to spoof such emails as well? I think there's a convincing argument that by using probes from multiple network locations and over time Perspectives is actually more difficult for an attacker to subvert than a one-time email verification.

Second, Perspectives is not specific to to SSL/TLS. The fundamental argument of perspectives is that automated network probing can provide a baseline notion of whether a key is valid. This isn't enough security for a big e-commerce site or a bank, but its a lot better than using completely insecure protocols. That's why I always smile when people wave DNSSEC as a response to perspectives. I'd be happy if we every get around to widespread DNSSEC deployment, but I would encourage you to ask yourself: how it actually makes the process of granting certificates significantly easier than it already is today? In my mind, it just turns DNS operators into the certificate authorities. In fact, I wouldn't be surprised if there is some fee that we pay to the tld operator to sign our DNS keys. It might start to look a lot like what we have today.

Third, in addition to the verification cost borne by the CA's and passed on to the customers, there is another cost to the standard CA model. For each domain name they own, server owners must go through the trouble of periodically generating new certs, submitting them to CA's, and then installing the new certs. At the same time, single-name certs break things like DNS aliasing (think www.gmail.com and mail.google.com). Perspectives uses a simpler model that can automatically bind public keys to DNS names, meaning a server could auto-generate a single key and the whole system would work without any manual operations by the server owner.

And now.... on to your comments on the code. I agree that the code (and the build system) are far from beautiful. Such are the realities of one or two people working part-time to get a system up and running. I appreciate whatever help/expertise you are willing to offer.

I'll post your comments on the developer wiki. Some of your comments are already on our TODO list, some are new, and others are design decisions that we've carefully considered and rejected or deprioritized. For example, your MD5 comment: as we note the paper, perspectives requires only second pre-image collision resistance, which is still considered secure for MD5. Only "simple" collision resistance has been shown to be weak. Using MD5 also has the side-benefit that people can manually compare the fingerprints to what they see in the Browser's cert details. I agree, eventually we will want to move on.

Another example, we did not consider replay to be a significant security risk in this scenario, as client's can be configured to reject 'stale' notary replies. Adding a nonce would require a per-query signature by the notaries, which hurts notary scalability). We can argue the finer points of these (and many other) issues, but again i would suggest that you just email us, as it is bound to be more productive. best,

dan

p.s. i think the question of balancing the benefits of "on-demand probing" with the potential risk of abuse is an interesting one. That said, people can already anonymously port-scan using Tor...

Posted by: dan wendlandt | September 5, 2008 2:46 AM | Report abuse

dan, thanks for the response. I'll have some followup on this later tonight or tomorrow.

Posted by: antibozo | September 5, 2008 2:43 PM | Report abuse

dan,

Regardless of whether we eventually communicate by email, I'd like to complete this discussion here in case anyone else is curious.

dan> Tell me, if an attacker is running BGP attacks in the core, don't you think they'd be able to hijack prefixes to spoof such emails as well?

I acknowledged that threat earlier, with this comment: "I have been decrying the email-based SSL verification system for years. Nonetheless, I can't point to a single example where someone has actually gotten a fake certificate for a legitimate domain by subverting this system. Can you?"

Furthermore, we can't disregard the fact that even though cheap certs are cheap, they're not free. Someone who wishes to fake a cert via this method still has to pay for the cert; this makes things more complex.

And besides, if someone actually does this, Perspectives, by default, won't help. The cert will validate so Perspectives won't be consulted.

dan> Perspectives is not specific to to SSL/TLS.

Neither are public keys in DNSSEC.

dan> I'd be happy if we every get around to widespread DNSSEC deployment, but I would encourage you to ask yourself: how it actually makes the process of granting certificates significantly easier than it already is today? In my mind, it just turns DNS operators into the certificate authorities. In fact, I wouldn't be surprised if there is some fee that we pay to the tld operator to sign our DNS keys.

Yes, the DNS operators are effectively the certificate authorities. With SSL/TLS, the DNS name is what is in fact validated against the certificate subject, so the DNSSEC arrangement makes a lot more sense than having a third party be the certificate authority.

As far as ease, putting keys in DNS is far easier than getting certificates. The DNS administrator and the person requiring a certificate are very often the same person, and nearly always within the same organization. And it costs nothing for the organization to publish the public key; they can publish public keys for every service on every host, if they like, along with keys for IPsec between hosts.

DNSSEC-distributed public keys are also superior to the X.509 PKI for a very important reason: I can only publish keys using DNSSEC for zones that I can sign. There's a naming hierarchy imposed that does not exist with X.509. If any of the more than a hundred standard X.509 CAs wants to issue a bogus cert, they can issue it for any DNS name at all. With DNSSEC, the person with example.com can't sign a public key for bankofamerica.com.

A certificate is just a verifiable assertion that a particular public key goes with a particular DNS name, for particular purposes. With DNSSEC, the DNS administrator can make as many of these assertions as he likes, and there is a boundary on his assertions that has the same shape as his DNS authority.

Certainly TLD registries may charge for signing, but this is a single cost per zone. The .se operators are charging 8.5 euros for this in 2008. The .com registries might try to charge more, but they can only get away with so much, because DLV is always an alternative for most customers. I'd rather we not use DLV--it risks creating the CA scenario all over again--but it is useful to put a market cap on what the registries can get away with. And customers who don't need .com can also just go to another TLD for a signed zone. Another market cap could come in the form of regulation from ICANN. We'll see.

dan> At the same time, single-name certs break things like DNS aliasing (think www.gmail.com and mail.google.com).

In which case the public key RR for www.gmail.com could be a CNAME for the public key RR for mail.google.com. Or the public key RR could be retrieved only for the canonical host name--for example. In any case, this is an idiosyncrasy of Google which they could avoid with ease if they wanted to.

dan> I agree that the code (and the build system) are far from beautiful.

My concern with code quality is that the code is simply not ready for prime time, especially in a security application. No offense intended here, but it really isn't. Before the extension ends up in 100,000 people's browsers, and the notary server is running on hundreds of hosts, it needs a certain amount of re-thinking and a serious code audit. There are definite problems.

dan> as we note the paper, perspectives requires only second pre-image collision resistance, which is still considered secure for MD5.

... For the time being. The message format should include a way to provide alternate digests before this goes into production, before everybody on Slashdot starts using it, before a Washington Post article is written. We don't know when the next MD5 domino will fall.

dan> we did not consider replay to be a significant security risk in this scenario, as client's can be configured to reject 'stale' notary replies.

In that case, I really don't understand why you aren't simply using DNS as the transport; then you would get caching. For example, key histories could be served as Base64-encoded TXT RRs under a naming schema like servicetype.port.hostfqdn.notaryfqdn.

dan> i think the question of balancing the benefits of "on-demand probing" with the potential risk of abuse is an interesting one. That said, people can already anonymously port-scan using Tor...

For port scans, sure, there isn't much difference. DoS attacks are another story. Tor isn't an amplifier. Perspectives is. A UDP packet containing a payload with a 10-octet header and a host:port,service-type plus null byte is sufficient to initiate an SSL connection and key exchange with an arbitrary system. This is a very high amplification factor, in the 100:1 order of magnitude. And with the current implementation it's possible to sustain this amplification indefinitely (yes, it is).

I don't have much else to say here; I'll try to email you a few somewhat more sensitive details sometime in the next few days. Take care!

Posted by: antibozo | September 6, 2008 5:24 AM | Report abuse

>There's simply no excuse for self-signed certificates these days;
>CA-signed certs are dirt cheap now.

Yup, which is why phishers are buying them using stolen credit cards ("A commercial CA will protect you from anyone whose money it refuses to take" - Matt Blaze). Actually they can buy $500 certs just as easily, since it's not their money they're spending. That's why Perspectives is needed more than ever, it detects when a suspiciously recent cert pops up, whether issued by a commercial CA or self-signed.

Posted by: Dave | September 6, 2008 5:33 AM | Report abuse

Dave> That's why Perspectives is needed more than ever, it detects when a suspiciously recent cert pops up, whether issued by a commercial CA or self-signed.

Not by default. By default, Perspectives isn't even consulted for certs issued from commercial CAs, because they validate.

Posted by: antibozo | September 6, 2008 5:59 AM | Report abuse

>By default, Perspectives isn't even consulted for certs issued from
>commercial CAs, because they validate.

Oh, that's less useful then. Perspectives should really check all certs because a cert issued by a commercial CA isn't useful against phishing except in the sense that most phishers don't bother buying certs so it can serve as a basic lint filter. OTOH simply checking which registrar handled the domain (see Brian's column of a few weeks ago) also works as an effective lint filter.

In the technical sense Perspectives is a proxied form of key continuity, a key management model that's been used by SSH for some time and which has been analysed by various security people, e.g. Simson Garfinkel in his PhD thesis, there was also a draft IETF BCP on it that seems to have sunk without trace. Having a centralised way of doing this is a nice approach since it doesn't require end-user software to maintain its own database of known keys.

To get traction for this it might be a good idea to do an RFC for the message format to get more clients and servers online. I'm not sure about antibozo's suggestion for using ASN.1, there's a lot of political opposition to this within the IETF for (IMHO) mostly silly reasons but it's going to cause problems in getting it adopted. I think the traditional bucket-o-bits TLV format used for other protocols would be the easiest to get accepted, plain 32-bit big-endian values for everything except byte strings, all text data straight UTF8, keep it as simple as possible, a UDP packet in and a UDP packet back. People can then lard it with crypto as desired once the concept has been proven (personally I'd say just tunnel it over datagram-TLS if you're worried). In any case it's only an advisory service, not the SEC or BBB so you don't need to go overboard with it.

Posted by: Dave | September 7, 2008 5:25 AM | Report abuse

Dave> Perspectives should really check all certs

I agree that would be a more useful default (there is a setting to enable this). It does risk confusing ordinary users, however, since certs do change regularly, and there are some web services that will look strange to Perspectives.

Your idea of checking the registrar is a useful one; also checking the issuer of the cert would be useful. I'm not sure how you could factor these data into the trust score in a way that is both fair (use an end-user scoring system?) and tamper-resistant (don't allow end users to score falsely?).

Dave> key continuity, a key management model that's been used by SSH

SSH, however, is used by expert users, and host keys hardly ever change. Certs change frequently, and everyone uses SSL/TLS.

Dave> I'm not sure about antibozo's suggestion for using ASN.1, there's a lot of political opposition to this within the IETF... I think the traditional bucket-o-bits TLV format used for other protocols would be the easiest to get accepted

I'm unaware of this opposition you refer to. ASN.1 is good enough for SNMP, LDAP, X.509 certs, Z39.50, etc. It also has an XML encoding (XER) if you're keen to maintain readability.

As far as TLV, really, ASN.1 is just a formalization of that strategy, and it comes with an unambiguous, compilable, message schema language.

In any case, my ASN.1 suggestion is just a response to the loosely structured message format used in Perspectives; I think if you look at the source you'll agree that formalization of some kind is needed.

Dave> keep it as simple as possible, a UDP packet in and a UDP packet back

If replay truly is a non-issue (I'm not convinced so far), then using DNS TXT RRs is clearly a superior strategy AFAIC; they could be text formatted for readability if that is desired. Clients can just use the resolver for all comms, and caching comes for free.

Another strategy is an XML-based web service running over HTTPS. This has much more comm overhead on the notary and the client, but that effectively counters the amplification problem. Since all the crypto could be handled by the SSL/TLS layer, this would also allow a pure chrome Javascript extension, so the plugin could be platform independent.

Posted by: antibozo | September 7, 2008 12:37 PM | Report abuse

>I'm unaware of this opposition you refer to.

Try getting any IETF group to adopt ASN.1 today :-). The standards you mention are all legacy OSI-era leftovers.

>If replay truly is a non-issue (I'm not convinced so far), then using DNS TXT
>RRs is clearly a superior strategy AFAIC; they could be text formatted for
>readability if that is desired. Clients can just use the resolver for all
>comms, and caching comes for free.

The problem with going to DNS RRs is that you're now getting into the keys-in-the-DNS dream that's gone unfulfilled for... actually I don't know when it was first proposed but it has to have been ten years at least. It's a political issue rather than a technical one, the nice thing about Perspectives is that you're not invading someone else's turf, you don't have to persuade anyone to change their DNS servers or protocol handling or anything else, you set up your Perspectives server and it's up to the users whether they want to play or not.

>Another strategy is an XML-based web service running over HTTPS.

The problem is that HTTPS setup overhead is quite significant so it'd really only be feasible when you have a high enough lookup volume that you can set up a persistent tunnel. This is why I suggested having the basic draft cover only the query/response and leaving security to another layer, you'd need to trade off response time, authentication, DoS resistance, confidentiality, and various other things in situation-specific ways.

For the simplest-case use to counter phishing I think the only significant threat from phishers would be a DoS on the servers, i.e. use a botnet to disable checking of your phishing site after it goes online. So an anticlogging mechanism like Photuris' cookies (not the broken IKE variant) would probably be enough for the baseline, and then you could add signing and encryption and whatnot at another layer, depending on what your threat model was.

Posted by: Dave | September 9, 2008 11:06 AM | Report abuse

Dave> The problem with going to DNS RRs is that you're now getting into the keys-in-the-DNS dream

There wouldn't be any keys in the DNS. Just signed notary responses. The client would still have a public key statically configured for each notary, but the public key would be associated with a base FQDN rather than an IP address.

Dave> the nice thing about Perspectives is that you're not invading someone else's turf, you don't have to persuade anyone to change their DNS servers or protocol handling or anything else, you set up your Perspectives server and it's up to the users whether they want to play or not.

I don't see how using DNS as the transport is any different. The only thing you need is for one person to put in a delegation pointing the base FQDN at the notary; then you just do normal lookups. The notary just answers DNS queries. No one else needs to change anything.

So, for example, if you're checking an SSL/TLS cert for www.example.com:443 using notary notary.example.net, you'd look up TXT RRs for 2.443.www.example.com.notary.example.net. Your nameserver would do the work, and cache the result. You parse the TXT RR and verify the signature against the local public key for notary.example.net. You could have a forwarder in front of the notary, as well, to cache its results. Such a notary would be trivial to implement, and the client becomes a lot simpler at the same time. Firewalls won't get in the way. You can test your notary with nslookup or dig. It's a no-brainer.

Dave> The problem is that HTTPS setup overhead is quite significant so it'd really only be feasible when you have a high enough lookup volume that you can set up a persistent tunnel.

Not really. You know you're already going to have HTTPS overhead with the site you're connecting to in the first place; this doesn't affect plaintext web access. I don't see it as a performance problem for the client really; your typical HTTPS access involves a bunch of distinct web servers anyway (i.e. mashups, media, etc.). It's just more load on the notary. This is good, in a way, because of the amplification attack I mentioned. See my earlier comments.

Posted by: antibozo | September 9, 2008 2:58 PM | Report abuse

The comments to this entry are closed.

 
 
RSS Feed
Subscribe to The Post

© 2010 The Washington Post Company