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

 
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: 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
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (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.