Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Encryption Electronic Frontier Foundation Networking The Internet

Launching 2015: a New Certificate Authority To Encrypt the Entire Web 212

Peter Eckersley writes: Today EFF, Mozilla, Cisco, and Akamai announced a forthcoming project called Let's Encrypt. Let's Encrypt will be a certificate authority that issues free certificates to any website, using automated protocols (demo video here). Launching in summer 2015, we believe this will be the missing piece that deprecates the woefully insecure HTTP protocol in favor of HTTPS.
This discussion has been archived. No new comments can be posted.

Launching 2015: a New Certificate Authority To Encrypt the Entire Web

Comments Filter:
  • quick question (Score:5, Insightful)

    by Anonymous Coward on Tuesday November 18, 2014 @02:34PM (#48412815)

    how can one verify that this future "certificate authority that issues free certificates to any website" hasn't issued a cert to the NSA for your domain? is it possible?

    • Presumably there will be a collision detection mechanism that nixes the old certificate and alerts you to such changes by e-mail.

      Yes, there are ways around it, but that's true of any CA.

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        The fundamental problem is the whole concept of a "Web of Trust." How or why should I trust that a collision detection mechanism is in place, functioning properly, and has not been manually overridden? We've come full-circle to "I just have to blindly trust."

    • Re:quick question (Score:5, Informative)

      by Peter Eckersley ( 66542 ) on Tuesday November 18, 2014 @03:02PM (#48413011) Homepage

      Actually the US Department of Defense and dozens of other governments have their own CAs with which they could issue a certificate for your domain, if they wished to. Here's a map [eff.org] we made of them using our SSL Observatory [eff.org] datasets.

      Nonetheless we should be able to use publication mechanisms such as Certificate Transparency [certificat...arency.org] to ensure that any compromise or compulsion of the Let's Encrypt CA could be quickly detected.

    • Re:quick question (Score:5, Insightful)

      by tignet ( 1303483 ) on Tuesday November 18, 2014 @03:13PM (#48413085)

      How can one verify that a different CA doesn't issue a certificate for your domain name to the NSA? It's happened before (including sub CAs getting compromised so new certificates could be created at will).

      In order for traditional PKI to work, there needs to be a point of trust -- the certificate authorities. That also means trusting anyone that controls the certificate authorities (who may have the power of secret laws, subpoenas, and gag orders). If you don't trust the authorities, then you cannot trust PKI.

      There can be public/private encryption without a centralized authority (SSH keys, PGP, etc). However, then it's up to each person to individually verify the authenticity of every other key. The certificate authority performs that role, so long as you're willing to trust them.

    • And how is that worse than using HTTP?

      • Re:quick question (Score:4, Informative)

        by mlts ( 1038732 ) on Tuesday November 18, 2014 @03:44PM (#48413331)

        HTTPS requires active MITM attacks to eavesdrop. If one looks at the trail afterwards, there isn't any real way to glean the session key the two machines created... to get that key, Charlie has to actively step between Alice and Bob and capture their pieces, while pretending to be the other person. If both use some signature mechanism, Charlie is SOL.

        What might have been better is early on, have Web browsers accept self-signed SSL certs, and show some grey icon for that. Certs validated and signed by a CA, a blue icon. EV certs, green. Couple that with a mechanism that detects an unexpected certificate change, and this could provide a decent level of protection, while making it obvious to the user that if they are concerned about security, do transactions with the green or blue color present.

        • Re:quick question (Score:5, Insightful)

          by userw014 ( 707413 ) on Tuesday November 18, 2014 @04:04PM (#48413481) Homepage

          ...

          What might have been better is early on, have Web browsers accept self-signed SSL certs, and show some grey icon for that....

          Web Browsers DID used to accept self-signed certificates (and certificates signed without a known CA - or cert-chain.) People just clicked through and accepted them willy-nilly. That was a poor security model. Although the existing security model of having a swamp of independent Root Certificate Authorities (per browser) is not too great either, but at some point you have to establish whom to trust - and for most of us, it's the browser vendor. (Some of us prune the Certificate Authority list and distribute the new list with software imaging technologies....)

          • Currently, a browser will happily accept an unencrypted connection or an encrypted one with a certificate tracing back to (in this Firefox browser) a certificate from of of 92 authorities (some of which have multiple certificates), some of which aren't in English and most of which I've never heard of. With that many authorities, it seems like a reasonable bet that at least one is compromised and doesn't know it. The browser will have conniptions and claim loudly that the sky is falling if it encounters a

    • Comment removed (Score:5, Insightful)

      by account_deleted ( 4530225 ) on Tuesday November 18, 2014 @03:16PM (#48413109)
      Comment removed based on user account deletion
    • by jbolden ( 176878 )

      EFF and Mozilla are included. I think that's a stretch.

    • by lillgud ( 951277 )
      Irrelevant.
      The "certificate authority that issues free certificates to any website" can actually be one or many of the CAs that is popular today. This is just a new protocol for the way to get a certificate signed by one of these CAs. So if some CA issues as a cert to the NSA for your domain right now there is nothing here that prevents that CA for doing it when using this new protocol.
    • Re:quick question (Score:5, Informative)

      by phantomfive ( 622387 ) on Tuesday November 18, 2014 @03:29PM (#48413213) Journal
      You can't. That gets at the root of the primary problem, and why web traffic isn't encrypted already.

      There are two issues, encryption and trust. When you connect to Google.com, how do you know that you've really connected to Google.com? Right now, because Verisign (or somebody) has vouched that the certificate comes from Google.com (ip address by itself isn't enough). Without that vouching, there are all kinds of MITM/redirection attacks that can happen.

      From a theoretical standpoint, encryption without trust is no more secure than plaintext transmission. However, from a practical standpoint, encryption blocks out a lot of script kiddies who sit on a wireless network with wireshark (incidentally, there is no way to verify that a WiFi SSID corresponds to a given base station, so if you're on WiFi you are almost always vulnerable to MITM attacks). The EFF, Mozilla, Cisco, and Akami are trying to raise the bar on the difficulty of the practical attacks.

      So we're moderately reducing the ease of the theoretical attack, but the big problem is still there, "is this website trusted, or just encrypted?" Traditionally no browser has had a way to distinguish, but it looks like Mozilla is going to, so that's a good thing.

      We still have the problem of trust though. It's probably the toughest problem in all of the fields of security and encryption.
      • by devman ( 1163205 )
        HTTP STS is supposed to help mitigate Wifi pharming attacks and has already been deployed by a few major sites, the real long term solution for this is DANE though.
      • From a theoretical standpoint, encryption without trust is no more secure than plaintext transmission.

        From a theoretical standpoint you've used trust and security in the same sentence, whereas they are are two completely independent concepts.

        Secure communications means people don't randomly eaves drop.
        Trusted communications means the people who read them are the people who are supposed to read them.

        Without an encrypted channel you have zero security. Every idiot snooping on the wire can read what you wrote.
        With an encrypted channel but no trust, you have some security. You need to directly involve a middle

    • Re: (Score:3, Funny)

      by Anonymous Coward
      This is a New Sertificate Authority, not the NSA.
    • or have the tragedy of the commons devalue the ssl certificate
    • by hawguy ( 1600213 )

      how can one verify that this future "certificate authority that issues free certificates to any website" hasn't issued a cert to the NSA for your domain? is it possible?

      How can one verify that any "certificate authority" hasn't issued a cert to the NSA?

      But if your domain is currently running HTTP because you don't want to pay for an HTTPS certificate, giving the NSA a backdoor to decrypt your website doesn't seem like much of a drawback. Not that matter for most people, if the NSA wants to see your data, if they can't get it from you, they'll get it from your ISP.

  • CAcert (Score:5, Informative)

    by danbob999 ( 2490674 ) on Tuesday November 18, 2014 @02:37PM (#48412829)
    We already have a free certificate autority: CAcert. The problem is that their root certificate is not included by default in major web browsers. Why would that be any different? I guess since Mozilla is involved Firefox will get it. But why don't just they allow CAcert? And what about Google and Microsoft?
    • Comment removed (Score:5, Insightful)

      by account_deleted ( 4530225 ) on Tuesday November 18, 2014 @02:41PM (#48412869)
      Comment removed based on user account deletion
      • Re: (Score:3, Insightful)

        Depending on 'big names' can reduce the trust factor to near zero, and rightfully so. How do 'big names' benefit from our privacy? Where is the incentive to secure it? This is a monolithic industry. Supply and demand are silly illusions. 'Big names' are subject to big laws from big people and the whims of big money, obviously, that's what made their names so big. And now we expect them to bite the hand? I don't think so...

        • Re:CAcert (Score:4, Insightful)

          by jbolden ( 176878 ) on Tuesday November 18, 2014 @03:25PM (#48413173) Homepage

          How do 'big names' benefit from our privacy?

          Akamai wants you consuming lots and lots of video. Cisco wants you chewing up bandwidth like crazy. They benefit. But yes if push comes to shove between you and Homeland Security, you lose.

    • Re:CAcert (Score:5, Informative)

      by Martin Blank ( 154261 ) on Tuesday November 18, 2014 @02:50PM (#48412937) Homepage Journal

      A lack of sufficient auditing capability is what has kept CACert out of most browser CA bundles.

      StartSSL.com provides free entry-level certificates with some level of verification, enough at least to satisfy the major browsers.

  • Fantastic. (Score:5, Insightful)

    by KermodeBear ( 738243 ) on Tuesday November 18, 2014 @02:46PM (#48412905) Homepage

    This is a fantastic effort that will help people such as myself. I run sites across a dozen or so hosts, but they don't generate income and I really don't want to drop all that money into certificates. If I can get free certificates from a good CA then I'll gladly bump all my sites over to HTTPS.

    Thank you!

  • by denis-The-menace ( 471988 ) on Tuesday November 18, 2014 @02:46PM (#48412909)

    Replace Cisco, and Akamai and then maybe I'll be convinced it's better than the current situation. But it's still oxymoronic service: A central authority that *REQUIRES* trust for people who don't trust anybody.

    And what do you do for countries with draconian Cert laws like England? (They want a copy of your root cert)

    The resulting entity would have to be incorporated in Iceland or something. FAR away from 5-eye's dragnets.

    • by akpoff ( 683177 )

      Cisco's involvement makes sense. They're pushing hard into "Internet of Things". They won't want the bad publicity or financial risk of delivering unsecured configuration UIs. Sure, they could install self-signed certificates but browser warnings about self-signed certs will generate support calls. If they can get the root cert into the other browsers (and as one poster above noted, it seems likely with this line-up), free certificates for the asking solves the problem.

      Akamai, not sure what they get out of

    • by dnavid ( 2842431 ) on Tuesday November 18, 2014 @03:53PM (#48413403)

      Replace Cisco, and Akamai and then maybe I'll be convinced it's better than the current situation. But it's still oxymoronic service: A central authority that *REQUIRES* trust for people who don't trust anybody.

      First, if you don't trust Cisco and Akamai to that extent, how do you intend to avoid transporting any of your data on networks that use any of their hardware or software?

      Second, I think a lot of people really have no idea how SSL/TLS actually work. There's two forms of trust involved with SSL certificate authorities. The first involves the server operators. Server ops have to trust that CAs behave reasonably when it comes to protecting the process of acquiring certs in a domain name. But that trust has nothing to do with actually using the service. Whether you use a CA or not, you have to trust that *all* trusted CAs behave accordingly. If Let's Encrypt, or Godaddy, or Network Solutions, is compromised or acts maliciously they can generate domain certs that masquerade as you whether you use them or not. As a web server operator if you don't trust Let's Encrypt, not using their service does nothing to improve the situation, because they can issue certs on your behalf whether you use them or not - so can Mozilla, so can Microsoft, so can Godaddy.

      The real trust is actually on the end user side: they, or rather their browsers, trust CAs based on which signing certs they have in their repositories. Its really end users that have to decide if they trust a server and server identity or not, and the SSL cert system is designed to assist them, not server operators, to make a reasonable decision. If you, as an end user decide not to trust Let's Encrypt, you can revoke their cert from your browser. Then your browser will no longer trust Let's Encrypt certs and generate browser warnings when communicating with any site using them, and you as the end user can then decide what to do next, including deciding not to connect to them.

      Seeing as how the point of the service is to improve the adoption of TLS for sites that don't currently use it, refusing to trust a Let's Encrypt protected website that was going pure cleartext last week seems totally nonsensical to me, unless you also don't trust HTTP sites as well and refuse to connect to anything that doesn't support HTTPS.

      Lastly, if you literally don't trust anybody, I don't know how you could even use the internet in any form in the first place. You have to place a certain level of trust in the equipment manufacturers, the software writers, the transport networks. If all of them acted maliciously, you can't trust anything you send or do.

      I don't necessarily trust the Let's Encrypt people enough to believe they will operate the system perfectly, and I don't believe they are absolutely immune from compromise. But I do think the motives of people adding encryption to things currently not encrypted at all is likely to be reasonable, because no malicious actor would be trying to make it easier to encrypt sites that have lagged and would otherwise continue to lag behind adopting any protection at all. Even if they are capable of compromising the system, that is quixotic at best. Even in the best case scenario they would be making things a lot harder for themselves, and in the long run getting people accustomed to using encryption with a system like this can only accelerate the adoption of even stronger encryption down the road.

  • by Anonymous Coward

    Have Apple, Microsoft, Google and Opera all pledged to add certificates for Let's Encrypt - and not just for future browser releases? Otherwise, we lose all of our IE12, Safari, Mobile Safari, Android, Chrome, and Opera users with these certificates.

  • strawman? (Score:4, Insightful)

    by JustNiz ( 692889 ) on Tuesday November 18, 2014 @03:13PM (#48413087)

    Why should we believe that HTTPS (or i suppose more accurately TLS / SSL) hasn't already been compromised (i.e. by the NSA)?

    • by NoKaOi ( 1415755 )

      Why should we believe that HTTPS (or i suppose more accurately TLS / SSL) hasn't already been compromised (i.e. by the NSA)?

      So, the straw man you're referring to is the idea that if the NSA can break it, then it's useless?

    • Why should I care? The NSA is tracking my move. That's a given. However in terms of my own personal life should I be more afraid of the NSA reading my credit card number and emptying my account (they have this info already), or should I be afraid of some 15 year old script kiddy doing it?

      Security has a lot of granularity between everyone can read anything I say, and uber security not even the NSA can hack.

  • I thought part of the reason for the cost of certs was the identity portion of the server. It's not just encryption, it's making sure that Citibank is Citibank not Bob DeHacker. I didn't see much talking about this, just about encryption.

    At some point, somebody needs to pay for identity verification. Maybe a group of companies does it for free for a Better Net, but there will be a cost someplace.

    • The amount of identity verification required is very small. StartSSL is fully compliant and included in browsers by default, but it's very simple and takes only a few minutes online.

      Bob DeHacker isn't going to be able to get an accepted cert for a MITM attack for a major company. Really, these days, the only thing that lights up the address bar green is EV-SSL. Your standard HTTPS site just puts in a tiny padlock in the address bar. And nobody's going to buy a certificate for a MITM attack on a site tha

  • ...do we really need to encrypt the entire web? (It's like TV stations boasting that they broadcast the News in high-def. Seriously, it's the News.) Do I (should we) care if the traffic to/from many (most?) sites is encrypted? No.

    What I'd rather have is sites not requiring a fuck-ton of Javascript, usually from other sites, to display anything or to work / navigate in even the simplest fashion. Content sites that use Javascript to display article text is particularly annoying.

    Just my $.02.

    • by Strider- ( 39683 )

      Exactly. I work in an environment with very limited bandwidth (1.8Mbps private satellite link servicing ~80 people). SSL by default is the bane of my existence. Right now, I've got Cisco WAAS deployed, and it adds about another 30% of effective capacity to my link, and often more. If everything goes encrypted by default, then I lose all of that. I get no caching gain, no compression gain, nothing, unless I MITM the link, which is evil and causes no end of support headaches.

      Encrypt what needs to be encr

  • Sure, they do business selling code-signing certs, wildcard and SAN certs but I have to believe that a not insignificant part of their business is selling boring, single-name certs for web servers.

    If you can suddenly get SSL certs for your web server for free and have them work like a paid certificate (wide-spread browser and device support) won't a lot of people do just this?

    Or will it be some kind of "we need support" thing where people keep buying them because of corporate policy and the "only" users wil

    • Some people will stick with the established CAs for better compatibility with older browsers or for the green extended validation bar. It's also not clear whether this service will support stuff like wildcard certs (heck it's not even clear right now how they are planning to validate certificate requests).

      but yeah if this takes off it's going to be a tough time to be a CA.

      • NM read in more detail, it seems they will be validating based on the ability to put a file on an unsecured webserver (which will make life a whole lot easier for a man in the middle close to the server).

    • Yes they will. Just like cable companies, they will get the best laws that money can buy.

      I predict in 10 years: money is privacy
      No money == no Certs == No privacy

      After all, money is speech (Thanks, you corrupt USSC!)
      No money == STFU

      • by swb ( 14022 )

        Yes they will. Just like cable companies, they will get the best laws that money can buy.

        When I posted my original comment I didn't think of this, but it's not hard to CAs to start claiming they provide a beneficial security service by validating certificate buyers, helping to keep bad guys from running encrypted web sites to sell drugs, defile white women and support terrorism.

        Maybe they will agree to some kind of "national security compromise" that enables regulation of CAs and their continued monopoly status, of course in exchange for giving the NSA backdoor access.

    • by thogard ( 43403 )

      When your in the business of selling random numbers, don't be surprised when someone undercuts you.

  • Let sites create their own keys and sign them (or not) by anyone they feel like. This could include CAs but equally it could include other sites they do business with to build a web of trust. And the browser should use SSL observatory to compare and cache these keys and present a simple checklist of what protection the site has against attack, its level of trust etc.

    The existing model is broken by the fact that CAs are not always trustworthy, the certs they issue to most sites are worthless as tokens of t

  • So I'm just going to send everythign in plain text instead. That'll show em.

    If you need true secure communications, in as much as any such might be possible, there are other solutions for that, which don't involve any kind of central authority. (As soon as you have a central authority, you have the weakest link of attack for a larger target.)
    This is encryption for everyone else, so passwords aren't being sent in the clear willy nilly by everyone who connects to their favorite sites from public wifi spots,

    • by Rashkae ( 59673 )

      Replying to my own comment, reading some of the other comments that were posted since mine, I see have some reading up to do on this new fandangled SNI thing.. That's one problem barrier down :)

  • They are the encryption experts after all, who better to trust for your SSL certificate needs?

  • Any estimates on how much power will be needed to run the crypto so a bunch of static web sites can put an S in the URL?

    • by kingbyu ( 682024 )
      Indeed, there is a lot of traffic on the web that has no need to be private. This slashdot page for example. But encrypting communications takes extra CPU cycles, and extra CPU cycles take extra energy, and will require more servers. Sure there is a lot of web traffic which should be encrypted, but the rest of it shouldn't be, for the sake of the environment and for the sake of that battery powered device in my pocket.
      • Actually, there's a pretty damn good reason why Slashdot *should* be private:

        You (and I) are logged into this site. That means a unique identifier tied to our Slashdot accounts is sent to the server (in a cookie) with every request we make. This lets Slashdot know who we are, primarily for when we post a comment. The problem is, this unique identifier is sent in plain text; anybody on the same network as you or anywhere in the network between you and Slashdot's servers can see it.

        Now, I don't know about you

    • Re: (Score:3, Informative)

      according to google, essentially NO extra cpu (in real terms) is needed anymore.

      citation:

      https://www.imperialviolet.org... [imperialviolet.org]

      quote:

      If there's one point that we want to communicate to the world, it's that SSL/TLS is not computationally expensive any more. Ten years ago it might have been true, but it's just not the case any more. You too can afford to enable HTTPS for your users.

The more they over-think the plumbing the easier it is to stop up the drain.

Working...