Stories
Slash Boxes
Comments

SoylentNews is people

posted by n1 on Wednesday June 10 2015, @01:59AM   Printer-friendly
from the safety-in-numbers dept.

Let's Encrypt has announced the generation of root and intermediate certificates, share the public keys, and show the layout of their operational structure. The keys are RSA (the Rivest, Shamir, and Adleman algorithm) for now with ECDSA (Elliptic Curve Digital Signature Algorithm) versions coming later this year.

The root certificates are for the Internet Security Research Group (ISRG) and separately for the Online Certificate Status Protocol (OCSP) for the ISRG. OCSP is described in RFC 6960 and used for revocation of certificates.

The intermediate certificates are for two different intermediate Let's Encrypt CA (Certificate Authority) servers named/numbered X1 and X2. These are cross-signed by the IdenTrust root CA for ease of deployment and use by existing browsers without the need for any modifications until the browsers add the ISRG root CA through updates. The Let's Encrypt intermediate CA X2 is only intended for disaster recovery in case of a non-functional X1. The Let's Encrypt announcement has a schematic of the structure.

The target is (or was) to launch the Let's Encrypt service in the second quarter of 2015 (which ends this month) and they plan on further announcements during the next few weeks.


Original Submission

Related Stories

"Let's Encrypt" gets a Launch Schedule 13 comments

After much work in background and previous update covered here at soylentnews, the guys over at Let's Encrypt have finally given a launch schedule:

Let’s Encrypt has reached a point where we’re ready to announce our launch schedule.

  • First certificate: Week of July 27, 2015
  • General availability: Week of September 14, 2015

While this is a bit off from the original mid-2015 launch date, it's a great start towards encrypted web communications.


Original Submission

Let's Encrypt Has Issued Its First Gratis SSL/TLS Certificate 19 comments

Josh Aas of The Internet Security Research Group reported on September 14:

Let's Encrypt passed another major milestone by issuing our first certificate. You can see it in action here

Our cross signature is not yet in place, however this certificate is fully functional for clients with the ISRG root in their trust store. When we are cross signed, approximately a month from now, our certificates will work just about anywhere while our root propagates. We submitted initial applications to the root programs for Mozilla, Google, Microsoft, and Apple today.

We're thrilled to finally be a live [certificate authority]. We'll be working towards general availability over the next couple of months by issuing certificates to domains participating in our beta program. You can request that your domain be included in our beta program by clicking here.

If you want to get involved with Let's Encrypt, please visit this page.


See our prior coverage: EFF Offers Free Certificate Authority to Dramatically Increase Encrypted Internet Traffic, The "Let's Encrypt" Project Generates Root and Intermediate Certificates, and "Let's Encrypt" gets a Launch Schedule.

Original Submission

Let's Encrypt Gets Automation 15 comments

El Reg reports:

Hoping to expand the pool of Let's Encrypt testers, TrueCrypt audit project co-founder Kenneth White has run up a set of scripts to automate the process of installing certificates under the Mozilla-backed open CA.

White, co-director of the Open Crypto Audit Project, has posted the work at Github, here. He explains that the project is quite simple, consisting of Python scripts to "stand up the official Let's Encrypt certificate management ACME client tool" in the target environments.

These include Debian, Amazon's Linux (for AWS), CentOS, RedHat, and FreeBSD.

[...]White says [...] the official client "can be fragile and error-prone on some systems".

Having had to batter his own head against the client, White [...] says he cleaned up the process in his scripts to make Let's Encrypt more accessible to other users.

He warns against running either the Let's Encrypt client or his scripts in production systems:

"LE is still in beta and has some rough edges", White notes, "including silently invoking sudo and installing quite a few development packages".

Previous: The "Let's Encrypt" Project Generates Root and Intermediate Certificates
Let's Encrypt Has Issued Its First Gratis SSL/TLS Certificate


Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Insightful) by frojack on Wednesday June 10 2015, @02:35AM

    by frojack (1554) on Wednesday June 10 2015, @02:35AM (#194344) Journal

    I've been waiting for this to get off the ground.
    It will be interesting to see if their certs will be blessed by all the other guys or they are going to give them the same cold shoulder they gave self signed certs (except Google's of course).

    --
    No, you are mistaken. I've always had this sig.
    • (Score: 0) by Anonymous Coward on Wednesday June 10 2015, @03:04AM

      by Anonymous Coward on Wednesday June 10 2015, @03:04AM (#194353)

      Thanks to Snowden, word is out that there is a peeping-tom in town.

      And everyone is pulling their blinds....

  • (Score: 5, Interesting) by sigterm on Wednesday June 10 2015, @02:48AM

    by sigterm (849) on Wednesday June 10 2015, @02:48AM (#194347)

    The ISRG Root CA uses a 4096 bit RSA key, which is likely to be resistant to brute-force attacks for the foreseeable future, unless someone actually manages to build a relatively large quantum computer. However, I was a bit surprised to learn that for some strange reason, the intermediary CAs have been issued 2048 bit keys.

    Sure, 2048 bit RSA keys are expected to hold up against attacks until around 2030, assuming nobody discovers a weakness in RSA in the next 15 years, AND no major, unexpected advances are made in parallel computing in the same time period. Now, that's a pretty big assumption, and I'm not sure I'd want to bet my business on it.

    But the surprising bit is that there's so little to be gained by using 2048 bit intermediary keys as opposed to 4096 bit keys, as long as the Root CA is using a 4096 bit key anyway. If a device can't handle a 4096 bit RSA key, it won't be able to validate the certification path regardless of the length of the key used by the server or intermediary CA, as long as it points back to a root with a 4096 bit key.

    Well, a key that's half as long is going to be significantly easier/faster to validate, but even with a 4096 bit key, a modern CPU is still able to perform a few thousand validations per second. And you'd only have to validate a certificate once every time you visit a web site, since SSL/TLS re-uses existing encrypted connections for consecutive requests to the same server.

    (BTW, the root certificate is valid until 2035, so why not go a bit overboard and use a 8192 bit key, just to be absolutely sure? Oh yeah, that's right; Apple broke 8192 bit key support back in 2006: https://discussions.apple.com/message/3650856#3650856 [apple.com] ...and they still haven't fixed it: https://discussions.apple.com/thread/3961444 [apple.com] )

    • (Score: 3, Interesting) by frojack on Wednesday June 10 2015, @03:13AM

      by frojack (1554) on Wednesday June 10 2015, @03:13AM (#194355) Journal

      But does it really matter?

      Lots of people thing SSL is pretty much owned by the NSA and GCHQ.
      http://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-codes-security [theguardian.com]
      http://www.theregister.co.uk/2011/04/11/state_of_ssl_analysis/ [theregister.co.uk]
      http://blog.cryptographyengineering.com/2013/12/how-does-nsa-break-ssl.html [cryptographyengineering.com]

      --
      No, you are mistaken. I've always had this sig.
      • (Score: 3, Informative) by sigterm on Wednesday June 10 2015, @03:31AM

        by sigterm (849) on Wednesday June 10 2015, @03:31AM (#194359)

        SSL is not necessarily "owned" by NSA, GCHQ or anybody else, unless we use weak/flawed cryptographic algorithms/software. In fact, the articles you provided links to, explains this: An adversary will need to steal keys, use side-channel attacks or issue fraudulent certificates (for use in Man-in-the-Middle attacks) in order to efficiently decrypt SSL traffic.

        A short key on an intermediary CA makes the latter scenario more plausible. A successful attack against an intermediary CA key will not help an attacker decrypt traffic to/from an end entity, but it will enable the creation of fraudulent certificates.

        So while the NSA may use National Security Letters to strong-arm the Let's Encrypt initiative into issuing a fake certificate for a specific MitM attack regardless of key size, a short key size could make brute-force attacks possible, and then everyone with access to sufficient computing power could issue fake certificates for any domain.

        (Personally, I'm not all that worried about the Chinese or the Russians reading my emails, since unlike the NSA/CIA/GCHQ they don't have the power to arrest or "disappear" people in the western world. But when it comes to encryption backdoors in general, I really don't think the principle of "the more, the merrier" applies, hence I'd like keys to be longer than just the bare minimum required as of right now.)

        • (Score: 2) by Gravis on Wednesday June 10 2015, @04:48AM

          by Gravis (4596) on Wednesday June 10 2015, @04:48AM (#194380)

          SSL is not necessarily "owned" by NSA, GCHQ or anybody else, unless we use weak/flawed cryptographic algorithms/software.

          "not necessarily" is just pedantry. when it comes to encryption, it's either secure or it's insecure (aka owned).

          check out this wikipedia chart [wikipedia.org]. SSL 2.0 and SSL 3.0 are both insecure and have been replaced with TLS.

        • (Score: 0) by Anonymous Coward on Wednesday June 10 2015, @07:17AM

          by Anonymous Coward on Wednesday June 10 2015, @07:17AM (#194424)

          or issue fraudulent certificates

          The thing is, SSL does not care which CA issued the certificates. So even if you choose the most trustworthy Norwegian CA, the NSA can just get their fraudulent certificates from a different one.

          Check the list of certificate authorities your browser accepts by default. It's huge. Any of them can issue certificates for any domain. Rumor has it that two of those actually are the NSA. And even if not, every single one that is in the USA can be used via National Security Letters. And the CA is not allowed to tell anyone when this happens.

          Still looking at the list? Ok, now look for China. They can do the same thing, and they probably don't even need a National Security Letter to do it.

          SSL is broken by design, and cannot be fixed. We need to start over.

          • (Score: 2) by Yog-Yogguth on Friday June 26 2015, @11:25PM

            by Yog-Yogguth (1862) Subscriber Badge on Friday June 26 2015, @11:25PM (#201871) Journal

            This is a late reply/comment (desperately trying to catch up, only now have I started reading the comments to my own submission) and /I don't disagree with you at all/ but just in case Norway wasn't used as a random $country or in case somebody mistakenly thinks there's anything particularly good or better going on there I wanted to point out —not only— that Norway is a Nine Eyes member but that recently there's been something odd going on there:

            1. A story which looks like a preemptive diversion to the second item below (or maybe it was pure power play, in full public view no less) and which was being pushed rather aggressively but quickly sort of flopped due to the strangely meek and unhealthy reaction it got. The story centered on a “nutty” Norwegian parliamentarian being “too” (i.e. “at all in any way”) friendly with Russians. The rather worrying and completely undemocratic response of seemingly every single Norwegian politician in all parties including both the “nutty” one as well as the Prime Minister herself was that they all fell over in eager and servile boot-licking agreement with the ‘superficially reasonable’ directives/dictates coming out of the Norwegian Police Security Service (NPSS/PST Politiets Sikkerhetstjeneste).
            2. The story the powers that be most likely wanted to divert attention from came a day or two later with the newspaper Aftenposten publicizing details of their findings including reports from the company they hired and opinions from various sources regarding the IMSI catchers/fake mobile phone base stations operating in Oslo last December (I have started writing this up as a submission but haven't managed to complete it yet, hopefully I'll get it done this weekend).

            TL;DR: don't count on Norway :(

            --
            Bite harder Ouroboros, bite! tails.boum.org/ linux USB CD secure desktop IRC *crypt tor (not endorsements (XKeyScore))
        • (Score: 2) by VLM on Wednesday June 10 2015, @03:24PM

          by VLM (445) Subscriber Badge on Wednesday June 10 2015, @03:24PM (#194551)

          unless we use weak/flawed cryptographic algorithms

          Isn't it known to be broken by everyone? Big Bro shows up with a NSL says all your data belongs to us; including live; send bill for time to this address?

          The only use I know of that isn't broken so far for https is idiot marketing people buying 50 domain names for one company and putting https on all of them. Paypal is famous for this, there's some paypalstories dor com or something like that BS marketing site or something which is possibly the only you'll see a URL out on the scam-ternet that claims to be, and actually is, paypal, and yes that one site is legit with a verified paypal.com SSL cert?

          Every other possible attack group either powns the server, powns the browser, powns the OS, powns the corporate legal dept with a NSL ... There's not many attack vectors left for non state bad guys to use.

  • (Score: 2) by hendrikboom on Wednesday June 10 2015, @02:53AM

    by hendrikboom (1125) Subscriber Badge on Wednesday June 10 2015, @02:53AM (#194348) Homepage Journal

    What is the "Let's Encrypt" project, and what's different about it?

    -- hendrik

    • (Score: 5, Informative) by sigterm on Wednesday June 10 2015, @02:59AM

      by sigterm (849) on Wednesday June 10 2015, @02:59AM (#194351)

      It's a Certificate Authority that can issue server certificates to web servers and mail servers, just like StartSSL, VeriSign, GoDaddy and others. The difference is:

      a) Unlike VeriSign and GoDaddy (but like StartSSL), the certificates are free, and
      b) Unlike everybody else, the Let's Encrypt initiative has developed a fully-automated solution

      If you own a domain name, you can get a certificate for free using just open network protocols. Renewals can be done automatically as well. That really is a big deal.

      • (Score: 0) by Anonymous Coward on Wednesday June 10 2015, @05:28AM

        by Anonymous Coward on Wednesday June 10 2015, @05:28AM (#194391)

        Although, looking at the tools - written in Go, using Docker.. This "fully automated" solution sounds like a hack, or at best something that works on Docker-enabled Linux distributions only.

        Quite limited.

        They're re-implementing all the tools to generate certificates and keys and so on, so it will take a few years for bugs and security issues to be ironed out.

        This is not the promised land... yet.

    • (Score: 2) by frojack on Wednesday June 10 2015, @05:24PM

      by frojack (1554) on Wednesday June 10 2015, @05:24PM (#194592) Journal

      What is the "Let's Encrypt" project, and what's different about it?

      AH, would have been great if the submitter had thought of your question.....

      The one link answer:
      Follow this link to the explanation page: https://letsencrypt.org/2014/11/18/announcing-lets-encrypt.html [letsencrypt.org]

      But also:
      Historical time line Here in Wikipedia [wikipedia.org].

      --
      No, you are mistaken. I've always had this sig.
  • (Score: 0) by Anonymous Coward on Wednesday June 10 2015, @03:40AM

    by Anonymous Coward on Wednesday June 10 2015, @03:40AM (#194361)

    Still haven't signed up for a Soylent account yet, I suppose I should while the gettin's good, but...

    Anyway, cursory inspection shows that the primary key servers will still be located in California, or at least the USA. Won't this be a problem for obvious reasons? Or am I missing something?

    • (Score: 0) by Anonymous Coward on Wednesday June 10 2015, @03:52AM

      by Anonymous Coward on Wednesday June 10 2015, @03:52AM (#194362)

      To add to this, being someone who is hardware rather than software educated, how does this help the average internet user?

      • (Score: 2) by dyingtolive on Wednesday June 10 2015, @05:21AM

        by dyingtolive (952) on Wednesday June 10 2015, @05:21AM (#194388)

        By my bleary, past my bedtime comprehension: In theory, it would remove the cost of entry barrier for https connections. To the end user, it could make it so that it doesn't pop up scary warnings about self-signed certs on your browser/mail client. As such, you could also literally encrypt "the web".

        --
        Don't blame me, I voted for moose wang!
      • (Score: 0) by Anonymous Coward on Wednesday June 10 2015, @07:32AM

        by Anonymous Coward on Wednesday June 10 2015, @07:32AM (#194428)

        Mozilla (developers of Firefox) has decided that everybody must use HTTPS, although the security underlying HTTPS is broken by design (any CA can create a certificate for any domain, so all e.g. the NSA needs to do is create their own certificate for your domain to MITM any connection to your server).

        The only point in HTTPS is to extract money for certificates. But Firefox is supposed to for the free and open web, so they can't be seen doing that. This project is simply to give you certificates for free, so you can keep running your server after Firefox starts demanding HTTPS.

        That this makes the whole HTTPS only thing a pointless exercise seems to have gone right over their heads. The only possible explanation I can see is that corporations likely won't be using these free certificates, so when they are forced from HTTP to HTTPS (not every corporation is a web shop), they will be paying for authentic Verisign certificates.

    • (Score: 5, Insightful) by sigterm on Wednesday June 10 2015, @03:57AM

      by sigterm (849) on Wednesday June 10 2015, @03:57AM (#194365)

      You're just missing one piece of the puzzle: that the Public Key Infrastructure on the Internet is vulnerable to attacks from governments and bad actors with access to ANY generally-trusted Certificate Authority.

      If the Let's Encrypt initiative was hosted on Iceland, the NSA could still obtain a fraudulent certificate from any of the other CAs in the world, several of which are in the US of A and falls under their jurisdiction.

      The main problem with PKI is that there's no way to limit the authority of a CA. You either trust it implicitly, or you don't. It would be nice if a CA could be restricted to just a section of the DNS namespace (for instance, why should a Chinese CA be allowed to issue certificates to .gov domains?) or prevent a CA from issuing certificates to domains which already have valid certificates from another CA, but sadly this just isn't possible under the current system.

      • (Score: 0) by Anonymous Coward on Wednesday June 10 2015, @06:53AM

        by Anonymous Coward on Wednesday June 10 2015, @06:53AM (#194418)

        The main problem with PKI is that there's no way to limit the authority of a CA. You either trust it implicitly, or you don't. It would be nice if a CA could be restricted to just a section of the DNS namespace (for instance, why should a Chinese CA be allowed to issue certificates to .gov domains?) or prevent a CA from issuing certificates to domains which already have valid certificates from another CA, but sadly this just isn't possible under the current system.

        I think most of us around here know this already, and I run Perspectives (not that it seems to help since their servers crash all the time and several sites like Google use so many certs as to not be trackable). There was that one project (Convergence? something like that) but it seemed to die from lack of interest.

        Sooooo...the billion dollar question (literally, I think): what do we replace PKI with?

      • (Score: 0) by Anonymous Coward on Wednesday June 10 2015, @07:10AM

        by Anonymous Coward on Wednesday June 10 2015, @07:10AM (#194420)
        I use Certificate Patrol on Firefox.

        However it needs some improvements like support for multiple certs per site (some sites use many different certs).

        Perhaps one day I'll try to see if I can add the feature myself, but I'm not an expert so...
      • (Score: 0) by Anonymous Coward on Wednesday June 10 2015, @08:44AM

        by Anonymous Coward on Wednesday June 10 2015, @08:44AM (#194443)

        Yes, the CA system is broken, but

        1. That's only a problem for active attacks, which are risky because there's a chance of getting caught.
        2. More importantly, the browser vendors are working on fixes like Public Key Pinning [wikipedia.org].
    • (Score: 0) by Anonymous Coward on Wednesday June 10 2015, @07:19AM

      by Anonymous Coward on Wednesday June 10 2015, @07:19AM (#194425)

      It doesn't matter. Any CA can create certificates for ANY domain, so as long as even one CA is in the USA (or the UK or China), the whole system is broken.

  • (Score: 4, Interesting) by NCommander on Wednesday June 10 2015, @06:45AM

    by NCommander (2) Subscriber Badge <michael@casadevall.pro> on Wednesday June 10 2015, @06:45AM (#194415) Homepage Journal

    I've never heard of them before, but if this pans out, I know who's going to be signing soylentnews.org's next SSL certificate. When they fully go live, I'll replace dev.soylentnews.org's self-signed certificate as a trailrun (as well as implementing HSTS and HPKP there in the nearish future).

    --
    Still always moving
  • (Score: 2) by kaszz on Wednesday June 10 2015, @04:18PM

    by kaszz (4211) on Wednesday June 10 2015, @04:18PM (#194566) Journal

    Unless there's a control panel in the browser to permit the user to declare which CA that has permission to issue a certificate for which site(s) in a firewall style control list [soylentnews.org]. The SSL/TLS CA system will still be wild-wild-west. In addition fingerprint pinning should be a default capability.

    Also any CA violating this permission list should alert the user immediately. And users need multiple sources of CA revocation lists. Any CA with legal or HQ placed within the three current superpowers is broken by default assumption.

    • (Score: 2) by NCommander on Wednesday June 10 2015, @10:02PM

      by NCommander (2) Subscriber Badge <michael@casadevall.pro> on Wednesday June 10 2015, @10:02PM (#194700) Homepage Journal

      HPKP solves the problem IMHO much better. The site tells the browser which keys or certificates that are allowed to sign it. The CA is reduced to establishing the trust of the first connection from the browser, afterwards, it doesn't play much of a roll in ongoing security. HPKP/HSTS preloading in browsers allow sites to be stapled in advance of that first connection. In case of mismatch, the browser refuses to complete the TLS connection. Once rehash fully stablizes and I work out all the logistics, we'll be rolling it out here.

      --
      Still always moving
      • (Score: 2) by kaszz on Friday June 12 2015, @12:59AM

        by kaszz (4211) on Friday June 12 2015, @12:59AM (#195205) Journal

        But if the site is MITMed then it can tell your browser that "hey that sleazy CA there is fine for signing this bogus site!" ..
        Browser based permission list is probably preferable because it will set a firm limit on any CA.

        • (Score: 2) by NCommander on Friday June 12 2015, @06:17AM

          by NCommander (2) Subscriber Badge <michael@casadevall.pro> on Friday June 12 2015, @06:17AM (#195286) Homepage Journal

          Once you make first connection to the site, the HPKP and HSTS data is stored, and can not be changed unless it ages out, or the browser sees a new header on a TLS connection created with a pinned key. If its preloaded in the browser, then its always good. Short of a TLA successfully hijacking one of the pinned keys, MITM is impossible with bog standard browsers which support these two protocols. The only downside is HPKP is new, and I don't think offical support has trickled down in Firefox (yet). Chrome supports it in the latest stable if I remember my research correctly. IE doesn't.. Without the specific certificate *or* key (depending on what is pinned), the connection is refused. While I think CAs should have some scoping rules, how are you going to explain to most folks a site broke and they have to change their CA "firewall" (for want of a better term).

          You're going to have certificate authorities in the United States that will have authority to sign stuff in the com/net/org zone. Even if you blacklisted all the government run CAs, a warrant could easily get them a valid cert that matched your firewall.

          --
          Still always moving
          • (Score: 2) by kaszz on Friday June 12 2015, @08:11AM

            by kaszz (4211) on Friday June 12 2015, @08:11AM (#195308) Journal

            Even if you blacklisted all the government run CAs, a warrant could easily get them a valid cert that matched your firewall.

            But it would force them to use a CA outside of their jurisdiction to get a matched CA outside of com/net/org/us. Which complicates matter for them a lot more. And even then, there's no telling which of those CAs that are allowed to sign anyway. Because the domain space may be further partitioned by a user.

            But at the core of it. It's complete backwards that the Chinese government can sign certificates for US banks and similar situations.