Slashdot Mirror

A self-signed certificate makes two guarantees. First, if the public key you see is the same public key you saw the first time you connected to that host, then a MITM probably hasn't been introduced since your first connection. SSH uses this "key continuity management" (KCM) or "trust on first use" (TOFU) model, as did OS X prior to the introduction of Gatekeeper. Granted, the MITM can harm the first connection to a given host.

But the second guarantee even in the face of day-one MITM is route diversity. The Perspectives extension uses notary servers to act as consensus CAs. This ensures that the public key you're seeing is the same public key everyone else sees for that hostname, which means that if there is a MITM, it's between the server and its only connection to the Internet (the "Lserver" attack in the Usenix 08 paper describing Perspectives).

So the biggest difference between a self-signed certificate and a domain-validated certificate is that the latter prevents an Lserver attack on your first connection.

Tough to detect with MOST browsers. They don't report cert chaining in a way that's useful for this. You COULD check the trust chain everytime you HTTPS. Firefox has the Lock icon to click. Same for Safari.

There are plugins for Firefox that alleviate this:

An indicator of changes in chain-of-trust, etc.
https://addons.mozilla.org/en-US/firefox/addon/certificate-patrol/

https://addons.mozilla.org/en-US/firefox/addon/perspectives/ Way cool "web-of-trust" validation infrastructure, with more info here:
http://perspectives-project.org/
http://perspectives-project.org/firefox/

People STILL ask me why I don't use Chrome or Surfari...

Additionally? Modify your workstations settings to use an authoritative external DNS server. OpenDNS is good... enough. Or your ISP servers from home. Then? Use TOR to browse. Be careful with your bank! They may close web-access to your account if TOR has it appear that you log in from Switzerland and Iceland!

These are not the best counter measures, and don't handle every case. TOR relies on SSL - but on a proxy-port, not 80, so usually outside the scope of these gateways. Depending how your company has it's CA published, they may still look "right" when using external DNS lookups, too.

Tough to detect with MOST browsers. They don't report cert chaining in a way that's useful for this. You COULD check the trust chain everytime you HTTPS. Firefox has the Lock icon to click. Same for Safari.

There are plugins for Firefox that alleviate this:

An indicator of changes in chain-of-trust, etc.
https://addons.mozilla.org/en-US/firefox/addon/certificate-patrol/

https://addons.mozilla.org/en-US/firefox/addon/perspectives/ Way cool "web-of-trust" validation infrastructure, with more info here:
http://perspectives-project.org/
http://perspectives-project.org/firefox/

People STILL ask me why I don't use Chrome or Surfari...

Additionally? Modify your workstations settings to use an authoritative external DNS server. OpenDNS is good... enough. Or your ISP servers from home. Then? Use TOR to browse. Be careful with your bank! They may close web-access to your account if TOR has it appear that you log in from Switzerland and Iceland!

These are not the best counter measures, and don't handle every case. TOR relies on SSL - but on a proxy-port, not 80, so usually outside the scope of these gateways. Depending how your company has it's CA published, they may still look "right" when using external DNS lookups, too.

In other words, the cert for www.google.com would actually be tied to www.google.com instead of having to just come from any one of the dozens of accepted CAs out in the world.

And don't forget the intermediate signing authorities (including governments, large corporations, and even non-profits) granted that power, usually without any restrictions, by said CAs. Unlike the CAs, there is no registry of who these entities are, though a study identified quite a number of them through observing certificates from actual websites.

For instance, the US Government has dozens of certificates giving intermediate signing authority, courtesy of VeriSign.

Besides DNSSEC, there are a couple of other (very similar) initiatives currently operating that aim to better manage trust in certificates:

http://perspectives-project.org/
http://convergence.io/

While we're at it some other addons like Perspectives or Convergence allow you to compare the cert you're receiving to the certs for the same site seen from multiple 3rd party servers across the world. This would allow you to confirm that not only that the certificate hasn't changed, but that the certificate you're seeing is the same one as *insert 3rd party unlikely to be MITMed the same time as you* is seeing.

This of course permits the NSA to do a classic Man-In-The-Middle attack. They give your browser the fake certificate chain and a copy of the website login page, you type things in, they decrypt them, and use them to log in to the real website, they get the results back from the real website, re-encrypt them with the fake certificate chain, and send them back to you. As far as you know you're using the real website, as far as the website server knows they're speaking with a normal browser, but the NSA is capturing everything either side transmits in clear text and can inject fake content in either direction whenever they want.

This is why there are browser addons such as Perspectives which allow you to verify the certificate and will notify you if a certificate's signature changes at any time.

Or Abine DoNotTrackMe, which I marginally prefer over Ghostery because the latter is run by the ad networks (of course, I'd prefer an OpenSource alternative...)

NoScript, Perspectives, Flashblock, BetterPrivacy and HTTPS Everywhere round out the package.

And occassionally PrefBar so I can change my browser UserAgent on the fly, just to mess with 'em...

What we need is a system like http://perspectives-project.org/ .

Now that's interesting.

Nuance is important in security. It's less secure to trust _ANY_ self-signed cert than it is to trust CA-signed certs. I think this is pretty obvious.

Consider the resources required to perform a mitm on each. If I'm a position to do so, I can easily mitm an (unverified) self-signed cert. To mitm a CA-signed cert, I need to both be in a position to do so and have the power to coerce a CA to sign my bogus certificate (i.e., I'm a state actor).

Are CA-signed certs trustworthy? No, not really. Are they more secure than an unverified self-signed cert? Of course.

The solution is a better public key infrastructure for SSL. Perspectives is a step in the right direction. As I said several times later in the discussion, (securely) verified self-signed certs are theoretically the best option, but we have a poor PKI for handling them right now.

The Perspectives notary system could be updated to include mail servers. Then everyone, including organizations like Google, could check notaries to make sure they weren't getting MITM'd.

So this graph is publish by the ICSI. They're getting into the "notary" game: http://notary.icsi.berkeley.edu/

They reference Perspectives as the pioneer of this scheme and also mention Convergence.

ICSI's Certificate Notary offers itself as different: "our notary collects certificates passively from live upstream traffic at multiple independent Internet sites, aggregating them into a central database in near-realtime." I'm not sure this is an improvement.

That's why the model going forward is going to be something like

http://convergence.io/
http://perspectives-project.org/
http://patrol.psyced.org/

Eep. Well, it expired 3 days ago. But yeah.

According to Perspectives, it's been consistent for the past 176 days. Good enough for me.

Another CA system is broken article?

Consider an alternative model based on notaries:

• Perspectives
• Convergence

Other resources of note: Moxie Marlinspike's article on "trust agility", his Black Hat Conference talk on this topic.

• Perspectives
• VMD
• Chimera
• Foldit

Etc.

But my question is, how much of this software will see the light outside the universities?

Impossible to answer. What defines a serious project versus someone's pet project or proof of concept? Then of those, how do you measure success? How many Sourceforge projects "see the light" outside Sourceforge?

Is there any list of successful software created entirely inside universities' labs that became widely used?

This is the question you seem to be getting an answer to in the forum here. Hopefully it helps.

As I understand it, certificates of active notaries are included in the download of the Perspectives extension for Firefox. This download takes place over an HTTPS channel with a TLS certificate verifiable to VeriSign.

So here's an alternative idea: Require multiple CAs.

Instead of doing it the "extended validation" way which is more money for not a whole lot more service from the same provider, it'd be much better to have multiple CA signatures on a single cert.

What you are proposing is roughly what the Perspectives project has implemented.

Just to provide some links to the "alternative approach" mentioned in the summary:

* The Perspectives Project spearheaded the concept of independant notary servers instead of a chain-of-trust.

* Convergence is another spin on the same concept, by Moxie Marlinspike in fact. (Not sure if it's compatible w/ Perspectives, but I think it is)

There's also Perspectives which asks "notary servers" what certs they've seen at that site over time so you can compare what other people are seeing. Of course, this requires that you be able to reach a notary server outside of your network, which may not always be possible.

Couldn't agree more. Links for the lazy: Convergence and Perspectives.

Enjoy.

How about this for the bootstrapping problem: A charity like the EFF could host a verifier that would connect and verify the SSH key or equiv. A simple firefox addon could alert you if a brand new website you've never visited before reports a SSH key different than the one the EFF verifier reports.

Also known as the Perspectives project.

To some extent this is just reimplementing the ongoing trust model problems of SSL CAs into a new introducer service.

That project tries to solve it by having many verifiers, and a certain percent of them have to match.

This exists! More or less. The Projectives Project

http://perspectives-project.org/

There's a Firefox extension. You can have it automatically override sites with security errors.

Security discussions often end up lacking the details needed for real progress. People who know better rarely seem to be involved from what I've seen. Knowledgeable need to speak up and educate the policy makers.

SSL is just fine for communication; identity it is as only as good as the signers -- which are not so good and just in it for the easy money. Browsers make money from being in the con game which also causes progress to be slowed. The best identity solution I have seen so far leverages the existing tech and is a Firefox add-on already: http://perspectives-project.org/

Me, I've been bugging my state officials (you should too) that we need the government involved as a signing authority. Not because its flawless (I bet it out performs the private signers easily) but because every BUSINESS already must register their corporation (LLC too) and they should get more than just a TAX ID and some paper. They should get a signed cert. This can be be used for multiple things not just SSL certs which support multiple signers. At least then one can see that a gov has recognized their corp in addition to whatever other signers are involved.

All the above uses existing tech. If you want to get into identity and encryption for the next generation, then I would suggest decoupling different forms of security not only in discussions but also in the implementations. Nothing says that one can't have an identity system verify the keys used for any form encryption-- the two do not need to be combined as if they were addressing the same problem..

I've been using the following to help me validate certificates:

http://perspectives-project.org/

They have a bunch of systems that monitor SSL certs for changes. They call them "notaries". You can run a notary, too.

It helps to make sure the cert you're seeing is what everyone else is seeing and no one is doing a man-in-the-middle attack on you.

There are better ways to establish identity than the "word of (a fallible) God" model, though.

A simple and extremely useful variant could simply ensure that the person on the other end is the same one that were on this address the last time.

Another is a net of trust-like model where you ask one or more trusted third parties to confirm that they're seeing the same guy that you are, like the Perspectives extension does. If done properly this is infeasible to execute a local man-in-the-middle attack against.

They could do an SSL MITM attack, I doubt their buddies in the government would mind, but to prevent that you could use Perspectives.

In order to avoid man-in-the-middle attacks, a solution like verifying the other part's public key by a different route could be used.

I can think of three sorts of "different routes", none without drawbacks:

• Using a CA that offers X.509 style hierarchical PKI can be expensive.
• Using a web of trust can be expensive if you aren't already a frequent flyer. Without attending key signing parties far from home, your key will be connected primarily to other keys in the same city, meaning the number of keys reachable from your key isn't going to grow very large. Or what am I missing?
• Perhaps by "routes" you meant diverse routes through the Internet, as used by the Perspectives extension. But this won't help when the MITM is between a host and its upstream on the same stub network, such as between the server and its colo's backbone connection or between you and your ISP's backbone connection. In that case, every route sees the same MITM.