Slashdot Mirror
Moxie Marlinspike's Solution To the SSL CA Problem
Trevelyan writes "In his Blackhat talk on the past and future of SSL (YouTube video) Moxie Marlinspike explains the problems of SSL today, and the history of how it came to be so. He then goes on to not only propose a solution, but he's implemented it as well: Convergence. It will let you turn off all those untrustable CAs in you browser and still safely use HTTPS. It even works with self-signed certificates. You still need to trust someone, but not forever like CAs. The system has 'Notaries,' which you can ask anonymously for their view on a certificate's authenticity. You can pool Notaries for a consensus, and add/remove them at any time."
I always trust what Blackhats tell me.
The dangers of knowledge trigger emotional distress in human beings.
I havent watched the video, but my first question would be:
How do you know the Notaries are who they say they are? How can you prevent a (wo)man in the middle attack?
The Perspectives add-on uses notaries scattered throughout the Internet to see if the certificate changes for different routes through the Internet, or if it has changed over time. This detects some man-in-the-middle attacks, but it doesn't detect what the Perspectives project calls the "Lserver attack": a man in the middle placed in the server's only upstream connection to the Internet. Users who have posted comments to recent Slashdot discussions appear to think that governments will mount an "Lserver attack" inside the country's firewall.
Isn't this what CRL's are for? I mean some fraudulent certificates have been issued by compromised or seedy CA's, remove the seedy ones from the trust chain and the compromised ones can add the fraudulent certs to their CRL's and improve their security and/or process to make sure it doesn't happen again.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
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.
Sure, I'll download and run code without a crypto hash from a non-HTTPS site.
Go green: turn off your refrigerator.
Web Of Trust, really, are you fucking kidding me? This has been implemented for how long already? Thawte personal certificates for e-mail work like that, with "trusted" notaries and shit.
And this is somehow a NEW AND REVOLUTIONARY idea, because it has a Web 2.0 name like "Convergence"?
Sheesh, the shit one has to put up with.
since the paths from notaries to target certificates are multiple
Not necessarily. The server with the target certificate has only one path to the Internet proper, namely through its ISP. Compromising the ISP, which is trivial for a government that maintains a Great Firewall, allows what the whitepaper about Perspectives calls the "Lserver" attack: "A compromise of the server’s local link lets an attacker inject arbitrary keys when either clients or notaries contact the server."
Answer here.
How do you know the Notaries are who they say they are?
There was a plan, over a decade ago, where the US Post Office would issue certs to people, sort of the way they issue passports now. You'd go to a PO in person, verify you are you, and they issue you a cert on a floppy. (It was that long ago)
Not a completely bad idea. I wouldn't trust any random POcert to be who they say they are, just that Xyzzy today, is the same Xyzzy as yesterday, unless their cert has been revoked.
From there, you set up a chain or web of trust. I know my friend certs, they know people and so on. If a cert is compromised, the Post Office can revoke it and let everyone know.
All ideas^H^H^H^H^Hprocesses in this post are Patent Pending. (as well as the process of patenting all postings)
If you control the *client's* ISP, you can MITM every single last connection to any number of notaries.
XML is like violence. If it doesn't solve the problem, use more.
Web Of Trust, really, are you fucking kidding me? This has been implemented for how long already?
A city-wide web of trust is easy: all participants arrange a key-signing party in the city. But a city-wide web of trust allows authentication of a channel only between participants living in the same city. Far fewer participants regularly travel to key-signing parties in foreign countries, mostly maintainers of high-profile free software projects, so the resulting web of trust will have those people as choke points when trying to establish multiple paths through the web of trust between any two given participants.
And it'll fail when they don't.
I want it to work, but you need to convince some sites to use it first, such as I dunno...
google.com
hotmail.com
facebook.com...
I didn't check any of these sites, but lastpass caused it to error out, and then every ssl cert ever is invalid. So very much kind of pointless currently, and I can't see the SSL cert providers being very friendly to it either?
Once its actually validating a sensible number of sites then I'll give it another try, for now I just stick to my paranoid "don't trust anyone!" self. I mean hell yeah google have ssl..... doesn't mean I trust them ;)
- http://www.milkme.co.uk
Perspectives appears to be a more mature project that also operates on the "route diversity" principle of verifying a server's X.509 certificate through notaries scattered throughout the Internet. Does the article say what advantage Convergence has over Perspectives, and specifically to what extent it solves the "Lserver" problem of a MITM between a server and its only link to the Internet?
This is precisely not required, and does validate those sites just fine. Maybe you should actually RTFA about it before making assumptions?
If you control the *client's* ISP, you can MITM every single last connection to any number of notaries.
Unless the notaries' public keys (or certificates that verify them) are already on the client's computer somehow.
You should watch the video, since it seems like you might not understand how Convergence works. The point is that the site operators don't have to opt in or do anything differently.
A browser plugin is okay to demonstrate the technology, but it doesn't scale and my grandma (bless her heart) won't like it. I'd like to see an OCSP server that uses Convergence under the hood.
1/10. Troll will possibly garner a little rage, but on the whole easy to spot and not terribly imaginative.
You can querry the notaries directly when you start up. If there is no match, than you know there is a lserver attack in place, and you move the box.
Only the operator of the server can do this or even know that an Lserver attack is in progress. And the operator of a server in a given country that mounts a nationwide Lserver attack is likely going to have a hard time moving a box out of the country.
Not even that. I almost posted before you did, because that troll was so much of a failure I was starting to pity it.
The point is that the site operators don't have to opt in or do anything differently.
Other than use it frequently to see if MITM attacks are in progress. If the majority of notaries are reporting a certificate other than the actual certificate for your site, then your server's connection to the Internet is itself being MITM'd.
Citation necessary, just leave your bank account information here so that the admins can verify the big bucks. I'll do it first.
2******************
7**********
3***************
S****
The cool thing is that the software automatically replaces it with stars when displaying.
From the page you linked: "you can see it's rather dumb to try to track 75,000 pieces of Badness when even a simpleton could track 30 pieces of Goodness." There are more than 30 pieces of Goodness in existence; everybody just uses a different set of 30. So what infrastructure allows a home user to enumerate Goodness in a fair, reasonable, and non-discriminatory way?
One way to improve security is to use TOR to get the certificate as well as getting it directly. This way, if you have a man-in-the-middle attack, you will likely detect it.
This doesn't do anything against someone who is hijacking the entire web site (though DNS hacks, for example), but it does help catch one category of possible attacks.
Of course, browsers should also cache certificates and notice when they change, so you would only need to use multiple paths to get certificates when they change or when visiting a site for the first time.
And when will one be able to one's own CA for one's own domain... I'd be prepared to pay good money for verification of my example.com cert, as long as it can sign certs for NNN.example.com, instead of either buying/getting a cert for every single NNN, or getting a wildcard cert for *.example.com. But no, the common name is just a string, nothing learned from the distributed nature of DNS.
I want it to work, but you need to convince some sites to use it first
I'll save a couple of steps by saying "I must be new here".
I want to know why browsers don't extend SSL to support PGP signed certs. Browsers would allow users to browse a web of trust, including perhaps "notaries" to establish whether they trust the site or not. Obviously it wouldn't be suitable for every site, but it would certainly would for personal sites where the hassle of obtaining a CA signed cert means many sites don't even bother with encryption at all.
Just checking to make sure it is the same cert as yesterday, and for all places. No special cert for the hidden proxy in Iran.
Unless it's a reverse proxy, MITMing all sites hosted in Iran.
Comment removed based on user account deletion
I made this comment on the youtube video about a week ago, but perhaps I'll get better responses on /. .
What happens when the MITM is on the website's end of things? The notaries will all get the same information. The CA system is able to work around this (mainly by telling you that the certificate isn't valid). How does a notary system know when all of the notaries are being lied to?
should we just generate a 16,384 bit RSA key pair transferring it with snail mail and building on that?
Or if every so loves AES why not a 16,384 bit AES key?
After all this is hashed out and communications are working proper then it goes live.
This project is all very well, but we want SSL to solve two problems today: prevent MITM attacks (which Convergence can do) and *also* identification (in other words, EV certificates) to prevent phishing or at least reduce the chances of phishing.
Unfortunately Convergence only does one of them (prevent the MITM attacks). A much bigger problem, certainly in the west, is phishing rather than MITM attacks. I'd suggest for many people Convergence still needs quite a bit of work before we can start using it in place of the current method of CAs (which I agree is broken).
Oolite: Elite-like game. For Mac, Linux and Windows
Some could be altering the plugin during download.
And then what we need is an "Auto-Notary-Approval-And-Removal" service so that we don't have to do maintenance on our approved list of notaries.
Moxie is a fairly cool individual, and a better than average sailor.
However, like so many cool people, he was a bit arrogant in person and on thee water.
I would imagine his tech has similar, ahhhhh, moxie!
i trust moxie more than i trust any saas corporation, security consulting company, or government organization.
First step thus is to ensure you know you want to trust them.
A great way to do that would be to verify the fingerprint of the cert with someone you trust. You can do this over the phone if you'd like (and trust the phone).
And then once you mark to trust that one, your browser will only trust that one, not derived certs, not bogus certs that match the same site name but are from other CAs.
http://lkml.org/lkml/2005/8/20/95
Most cities have notaries. Why shouldn't it be possible to turn up at your local notary with your credentials and get them to digitally sign your key?
It should be possible, but it isn't yet.
your ISP / host might sign your cert since you're running on their site
Web hosts such as Go Daddy already charge extra for a certificate, and they charge extra for the dedicated IP address needed to use the certificate. (Go Daddy is known to host upwards of a thousand sites on a single IP address, but Internet Explorer on Windows XP and Android Browser on Android phones still don't support SNI and thus can't see any certificate other than the first certificate on a given IP.) I'd bet ISPs would likewise charge extra for signing customers' OpenPGP certificates in the same way that they charge extra for a static IP.
Many sites run plaintext because trust doesn't matter so much or the hassle of getting a cert is greater than the requirement for trust.
The rise of tools for web session identifier sniffing and replay, such as Firesheep, has caused some sites, such as bugzilla.mozilla.org and addons.mozilla.org, to go all HTTPS all the time.
At the very least it would also allow encryption where none existed before
The rationale I've always seen for throwing up a big warning for self-signed certificates and not for plaintext is that HTTPS in the address bar with an unverifiable public key gives the end user a false sense of security.
Why go to all this trouble? If we have DNSSEC and, store the ssl certificate for each domain in dns as a new type of record then we automatically get a scalable trust network. With this method you don't need any certificate authorities, all domains can use self signed certificates. The browser can simply check that the servers certificate matches the one specified in the DNS which the browser already trusts due to DNSSEC.
Why not use PGP combined with social networks? "All my friends and everybody that works at that bank has signed this key, I suspect that it may be authentic". You can allways trust your friends, relatives and local society more than any CA by the basic principle that it is something you know. My first impression is that this 'Convergence' bring nothing new to the table, only new branding.
The concept is sound, but the practice is probably too lofty to take off (armchair assessment)
The problem I foresee is that users won't change notaries based on trust. Most users click yes to anything, don't know what's going on 99% of the time and have no clue/don't want to know how crypto works on the internet. Asking my mom to manage trust relationships is what I am imagining is ridiculous.
So, you need a mediator to manage notaries for you. Your browser vendor can do it, but trusting them is no more a reasoned argument than trusting a CA.
I'm also curious what the analytical benefits would be of running a notary. You wouldn't be able to know exactly who's trusting you for what, but you would be getting lots of information all the time about what users are doing.
I've always trusted self signed certs on machines I know because nobody can request a cert from an unknown entity. I feel vindicated.
Having to work for a living is the root of all evil.
This will break frequently. And because users are impatient and do not understand security, it will be default_open. In other words: basically worthless.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Following up from an earlier post I made here:
http://slashdot.org/comments.pl?sid=2367988&cid=37009792
To summarize, you'd setup the equivalent of trusted peers in your DNS for your SSL certificates. Those peers would store a copy of every certificate you generate (for free because they're your own servers or a friendly trusted source, or a paid service from one of the big guys) and your end user can double check the certificate from them as well.
Using the Secure DNS, the user's computer will typically have 2 DNS servers to reference independant and if the certificate authority information isn't the same across the DNS servers, the peers are different on each set of DNS records or if the peer doesn't recognize the certificate (or that they're peered), then the certificate cannot be trusted.
Decentralizing on SDNS is the answer. Traditional certificate authorities can still exist on the new system as trusted peers using a paid service, presumably hosting cached information like a CDN to speed up the verification.
You get a little 'Lock++' icon in the right corner (by default) that will tell you the verification status. For instance going to https://mail.google.com/ gets you a list of the current notaries and how they're 'voting'. You can add, edit, remove, or enable/disable notaries at will by providing host:port and a cert. It comes with 'notary.thoughtcrime.org' and 'notary2.thoughtcrime.org' by default, which gives you two entries to play with to start with.
The advanced options are the interesting ones - whether you want to anonymize your authentication requests, whether non-responsive notaries count as pass or fail, and the verification threshold: 'Require consensus', 'Require majority', or 'Require only one'.
There's also a separate download link for you to run as a notary yourself.
We'll see how this works out - this distributed trust thing isn't new, but the key bit is making it this easy, so people can choose who to trust or delegate that authority. And this seems pretty easy.
From the talk, Convergence is based on Perspectives, with some updates:
- Once a client has confirmed a certificate through the notaries, it is cached locally. Future contacts for that site will not need re-notarization until the site's cert is changed. That way your browsing history is not exposed through your notary contacts very often.
- Contact to the notaries can be done through a trusted proxy over SSL, to protect exposure of your browser history.
- The user can choose one or more notaries, and choose to distrust any of them at any time.
- Each notary can use any backend validation method it wants. It could check certs stored in DNSSEC, it could use the existing CA system, the EFF will have one that uses their SSL observatory, etc.
I'm pretty sure I've seen a handful of articles regarding this in the past month since defcon. How is this considered news at all, it's been reported, convergence has been out for awhile, let's get some actual news.
True, but under a Perspectives or Convergence style system, only the host of the extension (Mozilla Corp in the case of Perspectives) needs to actually pay for a CA-signed certificate. The rest can self-sign their own and rely on the notaries for an assurance level roughly equal to that of a domain-validated certificate.
For those in the U.S., Amateur Radio is largely self policing and certifying. To become a "ham" you train, then attend a testing session where your identity is verified, you pass the test, pay a small fee, and then the testing panels submits your information for licensing. What if a CA operated in a similar fashion? - Those wanting a certificate would show up at scheduled certification sessions, verify their identity, pay a nominal fee to cover costs, and dispense with the current CA system. It would be arguably more secure than CA certs are now, and less profit driven. I think community driven CAs, with certs that are accepted and recognized by the various SSL product vendors, would be fantastic.
--- Generation X: The first generation to have SIG lines inferior to their parents... ---
Not compatible with Firefox 7. Won't install.
i was going for funny guys
Each notary can use any backend validation method it wants. It could check certs stored in DNSSEC, it could use the existing CA system, the EFF will have one that uses their SSL observatory, etc.
Ah, this must be the convergence aspect of Convergence, allowing different validation techniques through being technique agnostic. Smart move.
(Re notary specification: Perspectives allows you to configure which notaries you wish to use, but the interface is not polished.)
Notaries' replies can be made secure by having them signed by the notaries (whose certificate are hopefully "well known" in the browser)
Other users have raised concerns that the notaries' certificates are not in fact well-known. The server from which the Perspectives extension is distributed, addons.mozilla.org, has had a certificate forged for it.
The ball's in your court.
The only people who can truely make this happen are the major browser vendors. Until the built in ability to use convergence and direct DNSSEC retrieval of certs along with the CA chain into their browsers, this won't take off. However, it would be very easy to have the CA chain internally as well as the DNSSEC trust chain (and simple self-signed certs) and then use convergence to double-check them. Most users would never know what was going on. Advanced and security concious users could go and actually adjust their trust relationships as they wished. All it would take is one or two of the browser vendors to implement (similar to do-not-track cookies but actually useful) to get the rest to join in.
I do security
The sole benefit of convergence is the ability to trust individual entities less than 100% and require that more than one entity (notary in this case) vouches for the validity of an SSL certificate. The existing CA system would be vastly improved if this simple change was added so that every major root CA is only trusted in proportion to the ability of obtaining an invalid certificate, and multiple signatures would be required on each SSL certificate. This is almost exactly the same case as requiring multiple notaries to validate a certificate except that it retains the offline trust ability that is still necessary for captive portals and also allows sites to use as many SSL certificates as they want for their sites, so long as they get them signed by enough CAs. In the diginotar case, Mozilla could have just dropped the trust in the diginotar root certificate, potentially requiring some sites to acquire additional signatures from other CAs. The (huge) problem is that SSL does not support multiple chains of trust for a single certificate and every SSL stack in the world would have to be changed. Some hacks are probably possible to allow interoperability between new and old servers and clients. Ultimately, signatures are a much more robust cryptographic building block than mandatory online verification.
I don't often tell folks to RTFA, but the amount of uninformed opinion in these SSL discussions is excessive and very counterproductive.
Simply, notaries tell you whether the cert you're seeing is the same cert they're seeing. You then decide on whether that means the site's authenticated.
(Not so simply, the Convergence system is designed extensibly so that notaries can use whatever method they please to return their vote of confidence/no-confidence, be it whether they've seen the cert before, some result from DNSSEC, or even the existing CA system.)
I'm not liking the idea of throwing more money at CAs on the off chance that one of the ones you pay will do their job in a trustworthy fashion.
As for captive portals, the presentation suggested using Convergence over DNS, since captive portals generally pass through DNS.
I give you credit for handling the multiple certs / site case, which Convergence might be confused by. (So far it's rare case outside of big banks.)
El Reg has reported on Google's Adam Langley in reponse to Convergence. Langley says' he doesn't see including it in Chrome because users would never change the default notaries, and Google would have to run their own notaries in order to ensure performance. And that would mean a privacy issue for Chrome as it "phones home" every user's https requests to Google. [Doesn't Chrome already have some kind of anti-phishing Safe Browsing feature that does this anyway?]
However Langley was good enough to open the door to the possibility of future API tweaks that would allow a third-party Convergence extension for Chrome (Chrome doesn't currently have a way for extensions to sit in the SSL cert decision path).
So the design boils down to Chrome phoning home for certificate validation. That has both unacceptable privacy implications and very high uptime requirements on the notary service.
Hah, so he haven't even watched the video, and still comments on it. Impressive.
And the "default notaries" thing could be solved in the same way that they use to protect against phisting sites. A list of notaries that gets regularly queried by the browser.
It's The Golden Rule: "He who has the gold makes the rules."
If we're going to hack a protocol (really? DNS? Why not just implement TLS over DNS while we're at it? Then captive portals will just block *everything*) we might as well hack SSL. I didn't say root CAs would have to be paid CAs. Any notary could be a CA just as easily, the *only* security difference is that there's now a variable level of trust that the user controls. In practical terms, a PKI infrastructure based on certificates is also more scalable. What happens when there are two billion sites (like Moxie hoped) that all need to be queried once a day by every notary? Who pays those bandwidth bills? Certificates also have a major advantage in that they can be signed securely, offline, by hardware if necessary, and then distributed by untrusted servers. Notaries will require the entire software stack to be trusted at all times.
There is one other aspect of notaries that is nice at first glance, and that's the fact that users are in control of which notaries they trust and site admins basically don't have to do anything. The subtle problem, of course, is that some server in China has no chance of getting its real certificate out to any notaries. The Great Firewall will MITM every single connection if the government so chooses. One might argue that this situation is unwinnable; if China never lets the real certificate through it's an effective denial of service attack. It would be better, however, to detect the DoS rather than lose completely to a MITM attack. If site owners are forced to register with CAs who they trust, the MITM attack is eliminated entirely.
Honestly I think you might have missed his point. A larger excerpt of the blog post:
There is some truth to that -- a performance concern leading to a privacy concern.
But given that the notaries are only queried for the very first contact to a secure site (browser uses its cache for future contacts), I wonder if he's overestimating the amount of traffic at the notaries and it's impact on the browser experience. Plus, as you pointed out, users can have their own notary lists like the anti-phishing ones, so if they don't want to trust Google they can pick non-Google servers.
Or Google could fund (perhaps in consortium) an external party to provide high-availability notaries that firewall Google from the privacy issues around notarizing Chrome users' https requests. Convergence can also use an intermediate proxy in order to hide the browser's IP address from the notaries it uses. So long as the default is to use a non-Google proxy to talk to Google's notaries, Google would be safe from privacy accusations on that front.
He goes into a restaurant with 2 friends. One of the has gone back to the car 'cos he forgot something. They witness a person with their birthday having the wierdest restaurant birthday ritual ever (having cream plastered all over their face while they are closing their eyes waiting for a surprise). They tell the restaurant that it is the birthday of the friend who went back to the car.
In Convergence notaries do not poll those sites once a day or ever. Notaries only contact a server when there is a mismatch between what the client reports seeing and what's already in the notary's cache. That means the notary only contacts a site when the site has changed its cert.
I watched the video, but I still don't understand how convergence is better than putting the certificates in DNS with DNSSEC. He says that DNS registrars are not reliable enough, but from the video it looks like convergence ultimately relies on them anyway. e.g.
If I control the DNS entry for paypal.com then I just change its IP address to point at my server. People using convergence will find my server in DNS, get its (self-signed) certificate and send it to the notaries. The notaries will see that it is different from their cached copy, which will trigger them to check for updates. They'll all go to the (compromised) DNS system, get the new IP address, get the fake certificate and return "OK" to the user. What am I missing?