Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Security The Internet

Moxie Marlinspike's Solution To the SSL CA Problem 189

Posted by timothy from the disaggregate-someone-today dept.
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."
This discussion has been archived. No new comments can be posted.

Moxie Marlinspike's Solution To the SSL CA Problem More

Moxie Marlinspike's Solution To the SSL CA Problem

Comments Filter:

  • Pooling Opinions... (Score:4, Funny)

    by mfh ( 56 ) on Thursday September 08, 2011 @11:06AM (#37340336) Homepage Journal

    I always trust what Blackhats tell me.

    • Well one interesting configuration is to use untrustable notaries (or notaries using untrustable sources), such PRC, DHS, FSB, etc. If any one is trying to trick you with a fake certificate for a MITM attacks, the others are not likely to agree that the certificate is genuine. Unless you believe such state powers would co-operate on getting at your encrypted sessions.

    • Re: (Score:2)

      by Hatta ( 162192 )

      These days the "black hats" are more likely to be trustworthy than the "white hats".

      • Never trust a guy who's hat is too dirty ... or too clean.

            Trust in us gray hats. We say don't trust either option. SSL as identification is worthless. :)

    • Re: (Score:2)

      by thue ( 121682 )

      Eh? Most of what he said was pointing out obvious things. Like a NP-problem: formulating the solution is hard, but verifying that the given solution really is a solution is easy.

  • 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?

    • Re: (Score:3, Insightful)

      by Tribaal_ch ( 1192815 )
      You don't really need to: You are expected to have more than one notary, so you will only trust the certificate if a majority of your notaries say it's legit. It's actually user-settable: a certificate is considered valid if a "majority say yes" or "at least one say yes" or "consensus is required". Having many notaries reduces the probability of MITM attacks, since the paths from notaries to target certificates are multiple, it's very improbable to MITM all of them at once.

      • Re: (Score:2)

        by Dogun ( 7502 )

        More likely:
        If my notaries disagree, let me know. Then you can make a decision - whether it's the BOFA problem (thousands of certs), or a genuine anomoly.

      • 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 [wordpress.com] 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."

        • If you control the *client's* ISP, you can MITM every single last connection to any number of notaries.

          • 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.

            • Re: (Score:2)

              by 0123456 ( 636235 )

              Unless the notaries' public keys (or certificates that verify them) are already on the client's computer somehow.

              But what if those are fake?

              Again, you're replacing a broken but kind of works most of the time system with a hand-waving belief that if you trust more people it will all work out OK.

              • Re: (Score:2)

                by tepples ( 727027 )
                In Perspectives, at least, several notaries' public keys are hardcoded into the download, and the download from mozilla.org is secured with traditional HTTPS. So someone would have to forge a certificate for addons.mozilla.org. I don't know whether Convergence solves this problem; I haven't been able to read the article because it's a video, and I haven't been able to find a transcript of the video on the site.

              • I think the idea is that because you would be using multiple notaries and working from a consensus, even if a couple of notaries were undermined, the system would still be more rigorous then the single-point-of-failure system we have now. I think, to assure statistical rigor, you're going to need several notaries, but by spreading the decision point out along a curve, you make the job of any hacker attempting undermine the CA system impressively harder. Say you had ten notaries. It would mean he would ha

              • Ultimately, all encryption will have to be tracked back to an OS vendor's root certificate. Your actual chain of trust is something like:

                Install OS with root cert->install browser signed with OS cert->receive other root certs from signed browser including browser manufacturer's root cert.

                Any of the 3 certs (OS, browser, other) can be used to anchor downloading more root certs, preferably for notaries, but they all anchor with the OS cert. A good thing to remember the next time you think about ru
    • As I understand it, certificates of active notaries are included in the download of the Perspectives extension for Firefox [perspectives-project.org]. This download takes place over an HTTPS channel with a TLS certificate verifiable to VeriSign.

      • Re: (Score:2)

        by Junta ( 36770 )

        So, it's the CA system (a blessed number of authorities with pre-distributed keys), but without any initial validation of the target by people vouching for it? Brilliant!

        Embrace certificates signed by multiple CAs and poof, you've added the biggest potential value of this approach while taking on none of the negatives/unknowns.

        • Er, Self-Signed certs work, so long as you KNOW you want to trust them. Any attempt to use a different self-signed cert will throw an error, since the cert thumbprints wont match the "trusted" ones.

          • Re: (Score:2)

            by 0123456 ( 636235 )

            Er, Self-Signed certs work, so long as you KNOW you want to trust them. Any attempt to use a different self-signed cert will throw an error, since the cert thumbprints wont match the "trusted" ones.

            And, uh, how do you know to trust the key?

            You've solved the problem of untrustworthy keys by... ignoring it away.

            • 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.

            • At some point you will be downloading either a binary browser, or its source code, or an OS distribution with the browser on it. You MUST be able to trust whatever channel you got them from, otherwise neither SSL nor anything else can work.

              Ditto here, you need to have some initial way to get the keys, which is generally with current browsers visiting the site and manually importing its cert, or with the keys being preinstalled on various browsers, and the browser's hash available on the site for comparison

            • And, uh, how do you know to trust the key?

              You confirm the certificate out-of-band by calling the named entity on the phone or meeting them, and comparing the key fingerprint. Only way to do it, really. That's why it doesn't scale.

            • You're trusting that the key hasn't changed.

              How do you know your mother is really your mother? All you know is that she's (presumably) the same person who you've identified as your mother since you were born.

      • So in other words, the CA system works just fine as a complete root of trust.
        • 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.

    • 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, the

      • Wow... A whole chain of people who never read what they are commenting on.

        It does not prove that X really is X. It proves that the cert you got for X website is the same as the certs others got for X website. It prevents an unnoticed cert swap. There is no "issuing" of the cert. It can be self signed... 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.

      • Re: (Score:2)

        by heypete ( 60671 )

        Interestingly enough, the Swiss Post Office provides that same service [postsuisseid.ch]. One goes to the local post office, shows a valid ID card/passport for identity validation, and can then apply for the certificate (contained in a smartcard, smartcard-on-a-USB-stick, or the "SwissStick" [which has a built-in browser and some other tools]).

        The certs chain back to SwissSign, a widely-deployed CA owned by the Swiss Post Office.

        I have no idea how widely used such certs are in Switzerland (I only moved here a month ago), but

      • This is probably a good idea except for the fact that the USPO is desperately out of cash; there was a report out just yesterday about how they are not able to fund their retirement accounts, and will probably go to 4 day a week service soon. The entire USPO system is going to get re-org'd some time in the not too distant future, and adding a new burden to their portfolio is probably not going to fly any time soon.

      • It certainly underlies the current problem, which is that we've basically opened up cert issuing so widely now that we've undermined the underlying trust. Short of certs you issue yourself, it's getting quite worrisome. The problem, to a degree, is that everyone wanted cheap certs and were pissed off that the old big guys like Thawt and Verisign were charging a lot of money. But the point back then was proof of identity, and not just some guy going on to GoDaddy and buying a cert for $10, or encouraging

  • 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.
    • 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.

      • 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.

        • Of course, in that case, the government can just come in and say "Give us root." Or use the ubiquitous xkcd password recovery technique with a wrench. There is no technical fix for that.

          • Re: (Score:2)

            by Sloppy ( 14984 )

            There's no technical fix for it, because one isn't needed. If a government does that on a country-wide scale, too many people know that it's happening, for it to remain a secret.

    • Re: (Score:2)

      by Svartalf ( 2997 )

      They've said it was derived from Perspectives on the website. I'm curious as to what changes they've made.

      • changes from Perspectives (Score:5, Informative)

        by schwaang ( 667808 ) on Thursday September 08, 2011 @02:04PM (#37342810)

        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.

        • 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.)

  • 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.
    • This is just Enumerating Badness. http://www.ranum.com/security/computer_security/editorials/dumb/ [ranum.com] In other words, it is a game of whack-a-mole where you do not know there is a problem until after lots of people have been fucked. Like in AV software before heuristics.

      • Re: (Score:2)

        by afidel ( 530433 )
        I disagree, a handful of bad certificates have been issued in the entire history of public PKI. If the CA's do their job it should remain this way. Throwing out the entire system because there have been mistakes makes no sense to me. Trust is a difficult subject and I don't see how the proposed system is superior to PKI, asking users who to trust is probably inferior to a hierarchy of responsible parties as users are notoriously bad at filtering bad actors from good.

        • It doesn't throw out the existing system. The existing system can work right along side of it.

        • Correction... A handful are known about. And it is an absolute certainty that more will occur. And they will only be revoked after they are found out, which is usually after they have been in the wild for a while.
      • 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?

  • Sure, I'll download and run code without a crypto hash from a non-HTTPS site.

    • Answer here [slashdot.org].

    • Sure, I'll download and run code without a crypto hash from a non-HTTPS site.

      And you think https is more secure? Have you been reading the news? I think the period should have gone directly after "crypto hash."

  • Web Of Trust (Score:3, Informative)

    by hjf ( 703092 ) on Thursday September 08, 2011 @11:16AM (#37340458) Homepage

    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.

    • Re: (Score:3)

      by sgbett ( 739519 )

      It's mainly because he's called Moxie Marlinspike.

      Only people with cool names can invent things.

    • 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 parti

      • However, things like FUDCon are held in different places each year, and there are enough people who travel to such things that the web of trust can indeed become global. Whether or not this can scale to the billions of non-technical users in the world is another story.

      • Re: (Score:2)

        by DrXym ( 126579 )

        A city-wide web of trust is easy:

        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? I'm sure there would be other ad hoc ways to bestow some trust. e.g. your ISP / host might sign your cert since you're running on their site, or your business suppliers might sign your key and you theirs. Basically the web of trust could have a formal network of signers and an informal network of signers which would form the web of trust.

        I also wonder how b

        • 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

          • Re: (Score:2)

            by DrXym ( 126579 )
            The beauty of web of trust is it opens up all kinds of models. Some people might prefer CAs (which sign PGP keys already), some notaries, some their ISPs, some their business associates, others their vendors / ISPs. Some will charge, some won't.

            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.

            That might have been the intent but in reality it splits websites into two groups - those who are prepared to pay a tax on security and those who aren't. For the sake of a secure web there has to be a cert which perhaps has a different trust model to CAs but still a

    • As far as I can remember there is some kind of mod_gpg for apache that does exactly that. web of trust, but using pgp. its free, and pretty good in fact.
      can't seem to find the link tho, probably didn't really get many users.

    • Re: (Score:2)

      by Animats ( 122034 )

      Agreed. There's this mindset in the "social" community that online social inputs can validate businesses through "crowdsourcing". This has repeatedly failed, because crowds can be sourced. Citysearch, Twitter, and Yelp are full of fake "reviews", many auto-generated so that crawlers will find and count them. This took Google Places into the tank last October. Here's a video from an SEO firm [youtube.com] which shows how bad the situation is.

      The explanation on the site of how it works is " "Convergence allows you to

  • 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'

  • Use TOR (Score:2)

    by crow ( 16139 )

    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 v

    • This way, if you have a man-in-the-middle attack, you will likely detect it.

      Except that it is entirely possible that your Tor exit was performing the MITM, and I would bet that is more likely to happen.

      • Re: (Score:2)

        by crow ( 16139 )

        Yes, but the point is that it is unlikely that a man-in-the-middle attack would catch both your direct connection and a connection routed through TOR. And if the certificates don't match, you know you have a big problem.

        Deciding on what to do if you detect a problem is another matter. Perhaps try a wide assortment of TOR exit nodes to get a better world-wide view.

      • Right. But, the Tor exit is not encrypted to the next hop (typically). So if the bad guy owned the Tor exit (the gov owns more than a few) they will see your traffic plain text.

  • 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.

    • If you name a machine NNN and create a self signed cert for it they confirming machine(s) will ask NNN.example.com for the certificate (in addition to the visitor). The confirming machine will pass it to the visitor, it will be compared, and if they are the same NNN.example.com will work just fine. No authority is needed in the process.

  • 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.

  • 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?

    • There can not be a MITM attack on only one end. The Middle is important. What your probably thinking is a DNS poisoning attack where the victim is going to the site replaced in the DNS record. The fix, according to Moxie, is to cache the certificate from the last visit. This would force the user to make the correct choice to beat a poisoning attack. However, Moxie also allows the use of DNSSEC as one of the verifying choices. DNSSEC, theoretically, is much harder to poison.

      • No, what I'm thinking is when the intercept point is in a place such that *all* connections to the website go through the MITM.

  • It's all very well... (Score:3)

    by Alioth ( 221270 ) <no@spam> on Thursday September 08, 2011 @11:58AM (#37341014) Journal

    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).

    • I don't think that's true. In the talk, Moxie points out that you could have a notary which checks perspective, one that checks the SSL observatory, one that checks DNSSEC, and one that checks CA signatures. It is unlikely a spoofed website could fool all of these. If it did not, (including if all notaries agree on the legit cert), you'd be encrypting your traffic in a way the phishing site would not be able to unencrypt.

  • 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 re

    • You do not need a mediator to manage notaries. You use a mediator to verify certificates for you. There will no longer be a benefit to running a notary outside of helping people that do not know how to create certificates avoid learning the process.

  • I've always trusted self signed certs on machines I know because nobody can request a cert from an unknown entity. I feel vindicated.

  • This will break frequently. And because users are impatient and do not understand security, it will be default_open. In other words: basically worthless.

  • 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/ [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

Slashdot Top Deals

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Close