Slashdot Mirror

If you are running a utiliy like Convergence or Perspectives to monitor certificates, I'll buy your solution. Otherwise, you're just setting yourself up for a MITM attack.

For an SSL centered project, I find it odd that convergence.io, where you're supposed to actually obtain the plugin, defaults to no TLS and if forced, has a certificate name mismatch.

That, in addition to Convergence being the next big thing ! ! !, followed shortly thereafter by it being completely abandoned, makes the whole thing seem amateurish.

For an SSL centered project, I find it odd that convergence.io, where you're supposed to actually obtain the plugin, defaults to no TLS and if forced, has a certificate name mismatch.

That, in addition to Convergence being the next big thing ! ! !, followed shortly thereafter by it being completely abandoned, makes the whole thing seem amateurish.

NoScript Options>Advanced>HTTPS> Forbid Active Content unless it comes from a secure (HTTPS) connection .

Painful, yes, but it should take care of this kind of attacks, as long as you can trust HTTPS (e.g. with Convergence).

Furthermore, NoScript 2.6.8.37rc2 introduce an experimental "Allow HTTPS scripts globally on HTTPS documents" mode (in Advanced>HTTPS>Permissions) if you value convenience over finer grained security.

Already now I have the trusted third party option. Moxie has started a service offering this: http://convergence.io/

Wooossshhhh!

He (somenickname) is talking about the global CA system where all 1000 CAs are equally trusted, so the NSA only need to convince one to reissue a certificate (based on a private key the NSA provided) in the name of the target website they wish to intercept.

The content consumer has no way of knowing if the SSL cert that is being used for the HTTPS connection is the one using the site owner's private key or the one using the NSA's private key. So this is why simply having a green light because you switched to SSL is security theatre.

But you (kasperd) go on an rant about other matters.

The projects such as SSL Observatory https://www.eff.org/observator... and Convergence http://convergence.io/index.ht... and http://tech.slashdot.org/story... combined with DNSSEC (which somewhat has the same problems as the CA system, but useful to allow deployment for low security websites without paying sign-my-certificate tax).

That page could have a particular certificate, maybe validated using Convergence

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/

Or you could go Convergence and use a distributed, agile trust model.

Little if any talk about http://convergence.io/ — watch the linked bulletproof youtube about why SSL certs are so broken and why this package would be so awesome (if popular).

That said, the way SSL is handled by the browsers is absurd. Not notifying on changes compared to a cached fingerprint, and giving huge warnings on self certification are blatantly obvious errors in judgement. Conflating encryption and identity in one awkward mess has probably done more harm than good. IMHO, it should work a bit like SSH, where the first time you go to a website, you see a little unobtrusive popup saying, "This connection is encrypted.

Yep, completely absurd. Go into your browser security certs and notice that the Chinese root cert "CNNIC" is installed. That means any of those trusted roots can simply create an SSL cert for Google.com and unless you're manually verifying the cert chain every time you connect, you won't know you've been MITM'd -- Big green bar and everything... I like your idea about making things more like SSH, but I'm afraid users will just click through it without reading any warnings anyway. Oh, if only PKI hadn't been invented! Why, then we could just use some session salt nonce HMAC'd with our pre-shared key (password) to set up a connection that no man in the middle can intercept (since they don't have our password, or password hash, etc pre-shared secret). I can do this in JavaScript, (or more favorably with a plugin), but we really need the browsers to just prompt us for the credential to our bank or email BEFORE it ever makes the request or displays the password entry form -- The request comes in, says : "I'm user X, here's my nonce, gimme your nonce server, and we can start encrypting data with HMAC( PW, N1 ) as the key". Public key crypto should have only ever been used at account creation (the only time you need to send the pre-shared secret). I've always known the entire security community was full of morons since they didn't bitch about the foolishness of SSL PKI loudly enough -- Oh, and for the "but muh passwerds!" folks: Built in password manager. Different random password for every site, master password to unlock the keystore. This is 2013 and since it's not standard addition to browsers, I'm not sure folks like you or me CAN do anything about it if we haven't already.

Additionally: People who searched for "Tinfoil Origami" also clicked on Convergence.

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.

http://convergence.io/ is the real solution

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.

http://convergence.io/details.html

SSO requires a) an authority for maintaining credentials

Yup, and akin to certificate authority trust model issues, you don't want to place ultimate trust in anyone - for unlimited time. A good SSO solution would need a distributed trust model similar to Convergence

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

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

Agree on the idea for open-source specification for social networking. Would be cool and if done right would increase privacy. The need for the United Nations to maintain a directory is misguided. A system like http://convergence.io/ would do fine combined with a public/private key system granted to friends that can be revoked if needed.

It's great the CA/Browser Forum, made up of the most prominent Certificate Authorities, is taking steps to standardize their rules for certificates. Many rules in the PDF are technical and exact, which will help with software enforcement.

However, even this necessary step of not issuing public certs for non-FQDN hostnames and reserved IP addresses won't take effect until late 2016!

As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName
extension or Subject commonName field containing a Reserved IP Address or Internal Server Name, the CA
SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and
that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a
certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject
commonName field containing a Reserved IP Address or Internal Server Name. Effective 1 October 2016, CAs
SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field
contains a Reserved IP Address or Internal Server Name.

If we're going to spend time and resources updating our browsers and operating systems to enforce some of these requirements and properly query certificate revocation lists, we may as well throw out the entrenched CA model and try something else.

Or we could just use a solution that was already thought out pretty well, doesn't require massive infrastructure change, actually addresses the problem (i.e. as end users we have to trust the entire certificate chain, and ultimately the CA).

http://www.convergence.io/

And go listen to Moxi's defcon talk about this.

Is Convergence foundering due to a lack of buy-in from trustworthy allies?

In your BlackHat 2011 talk you announced Convergence as a new way to establish trust on the internet to replace the SSL/Certificate Authority approach that has been shown to be so broken with the recent compromises of CAs like Comodo and Diginotar. Yet potential allies, some of whom admit that SSL has failed to meet its purpose and needs fixing, have not bought in to Convergence. Notably these include Google's Chrome security people and apparently the EFF (who has proposed a different solution instead).

While the list of Convergence notaries is still growing, there is so far a lack of support from the kind of allies like the EFF who could lend credibility and tip momentum toward widescale adoption of Convergence as a solution to the SSL/CA problem. Is Converence wilting on the vine?

"I'd love to see something like Firefox support go further and use a lib like this so unsigned certs could instead describe a web of trust via PGP and modify the manner in which Firefox presents such certs to a user. CAs are the biggest racket on the web and are IMO the biggest impediment to https being the default protocol for web activity."

I give you Convergence: http://convergence.io/

And the OWASP Keynote where it was presented: http://www.ustream.tv/recorded/17457016/

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.

I used to be in favor of patching things with DNSSEC, until I thought about it. I didn't really think about it until I saw moxie's blackhat talk. I happened to see it live, but not at blackhat. It's great. I think it's also a bulletproof argument against the CAs and DNSSEC. The protocol itself can be fixed (the security attack), but the current CA system pretty much can't be in a way that would satisfy me after seeing the talk.

http://www.youtube.com/watch?v=Z7Wl2FW2TcA

http://convergence.io/ (this is only a prototype, it could be rolled into openssl or whatever, with caveats, some day)

I think Convergence is better. The EFF should put up their own notary and just join Convergence instead of having their own separate way of doing the same...

I have already switched and added a bunch of random notaries. Everyone can just self sign and the notaries do the rest. Man in the Middle? Most notaries will warn your data differs. If a notary sucks, kick it and add another. Simple and clean.

Some say Convergence is the answer. I haven't been able to make it work, personally, so it's probably not ready for prime-time. Also, I don't like the name.

i'm sorry but do you not understand the basics of a Man In The Middle attack? and the value of a fake cert in that scenario?

in any decent MITM attack - if i'm trying to spoof google for you - then any request from you for google will go through me and i will respond with the right answer, currently under this scenario the 3rd party trusted CA on your local machine is the only way an end user has to verify that what i say is true or false.. compromising the CA in this case allows me to make a cert that your local machine will think what i say is true.

what you are wanting is something that Moxie Marlinspike thought up called convergence

http://convergence.io/

Basically moving away from a single CA signing and allowing for more than one verification path. In this case the only way to MITM would be to compromise all of your trusts.

Gee... If only someone else had an idea... http://convergence.io/

Good security practices are fine (and should be absolutely requisite for CAs), but do nothing to address the real problem with CAs, which is anchored trust. I hope that all of the browsers move to implement Convergence.

Actually, yes. http://convergence.io/ However, it also is not perfect, just better. Just catching that troll behind you there...

Marlinspike's approach, implemented in a Firefox extension presented at DefCon '11, is to do away with the notion of CAs altogether in SSL, replacing it with a distributed network that reports on the certificate they see. Basically, if the certificate you see agrees with the rest of the network, then you're not being spoofed.

He had previously explained the properties a replacement to the CA system had to demonstrate in order to be viable

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)

Self-signed certs, distributed verification system. Try it out now:

http://www.networknotary.org/firefox.html

http://www.convergence.io/

Have you been living in a cave?

There has been a lot of push at the recent DEFCON conferences, and associated conversation since, to look at alternatives to the current CA system. Moxie Marlinspike has been pushing a remote-view notary system called which is currently a Firefox plug, and Dan Kaminsky has been pushing for DNSSEC.

There has been an awful lot of discussion about the technical details of SSL certificates on the Security StackExchange (Stack Overflow cousin) website, including the related blog post I penned: A Risk-Based Look at Fixing the Certificate Authority Problem.

Screw that, i moved to Convergence.

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

Enjoy.

It would be great to have SSL fixed but it won't happen. The reasons are (same as Flash, HTML5 and Java, IPV6): 1) has a monetary interest in the technology 2) The public/private sectors have adopted this as defacto standard 3) Haters hate change in the name of "secure"

The only way to change this is to implement a work-around which excludes the current 'key masters' and makes the previous technology obsolete (like HTML5.. ok, mostly obsolete).

Marlinspike's proposed replacement avoids that issue by making the change something that can be implemented on the user side without any action on the part of standards bodies or site owners. Really, the only players who have to implement the technology in order for it to work are the browser makers, and they can even make it optional.

Another aspect of it that I like is that it facilitates the use of self-signed certificates. Also, it's worth pointing out that his suggestion isn't so much a "replacement" for the CA system, but a stand-beside additional validation method. So for sites that use a CA you can get both checks. For sites with self-signed certs, you only get the Convergence validation.

Supposedly.

One problem I see is that the information provided on the Convergence web site is completely insufficient to understand how it works. The "Details" page doesn't really provide much. Here's my guess as to how it works:

• There are a set of servers scattered around the net which can be queried to validate a certificate. These can be run by anyone.
• The way one of these validation servers checks a certificate is (I think) by making a request to the site and looking at the certificate they receive from it. Perhaps they also check it against the certificate they've received from that site in the past, and perhaps the servers talk amongst themselves.
• Your browser has a list of such servers, and whenever you visit a site for the first time, it queries several (all?) of them to see if they got the same certificate from the site that you did.

Assuming my guesses are right, I think the core idea is clever and potentially very useful, but I see some flaws (which Marlinspike may well have completely addressed with his design -- but it's not clear how based on the minimal information I've seen).

• The approach defends against man-in-the-middle attacks unless the attacker has also compromised the link between the site being validated and the validation servers. This means that MITM attacks mounted "close" (in terms of network topology) to the user will be basically impossible (modulo the next point), but attacks mounted close to the site will be very likely to succeed. To make the security good, you also need to ensure that the client is using a well-distributed set of validation servers.
• The approach assumes that the client can trust its communications with the validation servers. This seems simple enough, though; when you configure a list of validation servers you also configure their certificates, much the same way you add a CA to your browser configuration. Then when the browser talks to the validation server it uses SSL and checks that the server cert matches the configured value.

Another issue that comes up is how to know what set of validation servers to use. Obviously users aren't going to configure this, any more than they configure their list of SSL CAs. The clear solution is the same one used for the CA list -- let the browser makers vet the validation servers and provide a default list, pre-configured. The user can alter it, but generally won't. If a validation server proves untrustworthy or unreliable, it can simply be removed in an update. Given the use of multiple validation servers, removing an untrustworthy one would be an important but not particularly urgent change. This is the "Trust Agility" Marlinspike speaks of... you can stop trusting someone who proves th

Have scanned the comments, am not seeing discussion of Notaries.

If you're not talking notaries, or you're saying 'Moxie didn't describe his alternative', it just means you missed (or were asleep / hung over) at the Defcon panel by Marlinspike & Diffie (and questions from Hoyt Kesterson, a former chair of x.509 standards). Go back and reread the 2nd link, especially the last few paragraphs. Moxie's April blog entry didn't get into Convergence, which is an attempt to flip the model upside down.

Everyone talking about trust and signing parties, congratulations: you pretty much independently arrived at M&D's conclusion about them. Ditto MITM. Ditto DNSSEC (both as a spooky single point of failure and the flaw of shoehorning too much shit into DNS records).

In a nutshell, what drove Moxie nuts was watching as there were NO REPERCUSSIONS when Comodo screwed things up terribly. And since web browsers can't/won't just arbitrarily screw all the corps that buy Comodo crap by dumping Comodo from their CA list, nothing will change.

So, he flipped the model around. Users... well, actually, clients... get to revoke trust relationships. And we would do it via the idea of Notaries. The notary pool might vary based on nationality of users (many people in countryX may not care enough to have a notary that focusses on vouching for countryZ websites), or it might introduce a bit of paranoia: As the panelists mentioned and Naked Security restates, clients might even choose a mutually-distrustful set of Notaries to trust: the US Dept of Homeland Security and a branch of the Peoples Republic of China.

Here's my notes on how Convergence works: an SSL page gets the cert from the website, and requests the cert in parallel from notaries. If there's no match or if one of them flags it, you'd get an alert: distrusted by NotaryX. The distrust mechanism is immediate (a Notary can revoke and know that all future use of that cert will be flagged), and if a notary refuses to revoke a cert after a monumental screwup like Comodo's, the users or client-code developer can comparison-shop and find a notary that recognizes the flip-around in nature of their job (vouching for the validity of 3rd-party certs TO US, not trying to keep getting payments by those who currently buy certs).

FWIW, I wasn't completely convinced by Moxie, though not because of Kesterson's good question (What stops this from becoming another economic race to the bottom, like where SSL certs are bought on price, since the buyers evidently aren't technoliterate enough to grok SSL and flee Comodo like they should). Mine's along the line of Schneier's axiom on how crypto is hard: even an easy and promising alternative needs a bit of hard scrutiny to make sure it isn't just creating a different set of problems.

(whew, talk about tl;dr)

One last thing: when the defcon vids get published, this one's worth watching just for Whitfield Diffie's bit on Defcon presentations needing a glass of scotch whisky vs authenticity of his remarks. Priceless.

Out of 140+ comments here only two mention Convergence. Yours, and a kind of incidental mention earlier. Even I missed it because I focused only on Marlinspike's old blog article.

Focus, people: Convergence

Look it over and see what you think.

This points that the last bastion of security (secure transport layers provided by the transporter) is no longer viable. MITM is apperently practical on most wireless networks, even the adnvaced cellular ones. In that case, you MUST authenticate every location every app goes to. This means EVERYONE needs certs. I wish there was more info on Moxie's new tool because it may be an absolute necessity in the very near future. (Unless the CAs are going to start giving out free certs.)