Stories
Slash Boxes
Comments

SoylentNews is people

posted by takyon on Thursday July 02 2015, @03:00AM   Printer-friendly
from the order-of-magnitude- dept.

Amazon has announced a new TLS implementation. From the ZDnet article:

Rather than try to cover all of SSL/TLS's full range of extensions, s2n, with its mere 6,000 lines of code, focuses only on encryption. This means that Amazon is not trying to replace OpenSSL. Schmidt wrote that "Amazon remains committed to supporting [OpenSSL] through our involvement in the Linux Foundation's Core Infrastructure Initiative."

Instead, s2n replaces the functionality of only one of OpenSSL's two main libraries: Libssl, which implements TLS. There is no s2n equivalent to libcrypto, OpenSSL's general-purpose cryptography library. Thus, s2n can take the place of "libssl," but not "libcrypto."

takyon: For comparison, about 70,000 lines of code in OpenSSL are involved in processing TLS.


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, Interesting) by kaszz on Thursday July 02 2015, @03:30AM

    by kaszz (4211) on Thursday July 02 2015, @03:30AM (#204071) Journal

    Somehow I like it.
    It will break compatibility but also introduce KISS.. Keep It Simple Stupid. The question is if it will be complete enough to do end-to-end encryption. Then there's also the use case of clear text but with authenticated data for use with cache mechanisms, this may be missing?

    Let's not get started with the CA mess where any CA may sign for any other CA. If we only could have TLS based on DNSSEC.. (or .onion etc?).

    Perhaps a start in the right direction at least?

    • (Score: 5, Informative) by gnuman on Thursday July 02 2015, @03:46AM

      by gnuman (5013) on Thursday July 02 2015, @03:46AM (#204073)

      If we only could have TLS based on DNSSEC

      We could. It's called DANE

      https://wiki.mozilla.org/Security/DNSSEC-TLS-details [mozilla.org]

      https://tools.ietf.org/html/rfc6698 [ietf.org]

      • (Score: 3, Informative) by NCommander on Thursday July 02 2015, @06:02AM

        by NCommander (2) Subscriber Badge <michael@casadevall.pro> on Thursday July 02 2015, @06:02AM (#204115) Homepage Journal

        I've got issues with the DANE spec that even after we roll out DNSSEC, I'm not sure I'll add TLSA keys to the domain.

        The three largest problems involve DNSSEC validation itself, the chain of trust and how DANE ties to the certificate chain.

        Under "normal" DNSSEC, the chain of trust is validated from the TLD to the top level domain, and then onwards down the train. This validation is done by the DNS server your computer uses, i.e., your computer asks your ISP for soylentnews.org, and if the client set the DNSSEC bits (assuming we had a signed tree), that response will either return if the record was present but unsigned, or if signed. If validation failed, an error code is returned. THe problem is that the end user does not actually validate the chain of trust itself (nothing technically prevents it from doing so by directly requiring RRSIG records), but if you can compromise a DNS server your client uses, you can defeat DNSSEC since no operating system as of writing validates the chain independently. Admittedly, not an insurmountable problem since clients could just verify RRSIG themselves, and not my primary complaint with DNSSEC. DJB's DNScurse solves this issue, but requires online signing, and as such is not suitable for the root zones/servers.

        Secondly, to validate a DANE record, a chain of trust must be established. As I previously indicated, clients do not normally check the DNSSEC chain themselves, depending on the upstream server to do so, which makes it relatively forge the record by returning the AD bit when returning the TLSA chain. To make matters worse, you still need to draw a chain of trust from the TLD downward, which means whoever controls the private keys for the registar has complete control on downstream keys; it would be straightforward that if one of the root keys were leaked or compromised to forge the DNSSEC chain + TLSA record even if the client manually validated it. This issue could theoretically be mitigated by the use of DLV records, which establish "trust anchors". As such, if a resolver knew that soylentnews.org wanted be its own trust anchor, it could publish its own DLV record and push it for inclusion in the central registry; unfortunately, just like HSTS preload, this design can not scale, and was only meant as a stopgap until the DNS roots themselves were signed.

        Third, DANE validates the certificate chain itself itself, *NOT* the underlying key. Essentially, you're saying that soylentnews's SSL certificate is only valid if its signed by *this* provider. Thus it can only be used with pre-existing CA certificates, or with self-signed keys. HPKP did the right thing by pinning the chain to a specific private/public key set; by signing the certificate chain itself, you're limited to the CA that pin, or causing all non-DANE clients to generate the usual self-signed warning. It solves the wrong problem. I was hoping an extension to DANE's modes would solve the issue, but as of right now, I haven't seen much progress in modifying it :(

        Given that Chrome removed DANE support, and Firefox only supports it via an add-on despite teh standard now being around two years, I don't see wide hopes for this wildly being adopted. Hell, I installed the DNSSEC/TLSA validator, and aside from test sites, DNSSEC deployment is suprisingly non-existent. While I still intend to sign soylentnews.org once we migrate to our own BIND instance, I do so knowing that unless something fundamentally changes in how operating systems validate DNSSEC today, its not going to do much.

        --
        Still always moving
        • (Score: 0) by Anonymous Coward on Thursday July 02 2015, @07:55AM

          by Anonymous Coward on Thursday July 02 2015, @07:55AM (#204133)

          In addition to the problems you list, here's a good blog post covers what's wrong with DNSSEC [sockpuppet.org]. And here's the Mozilla [mozilla.org] and Google [google.com] bugs saying they won't support it.

          One detail is that my understanding of TLSA records is that like HPKP let you reference any key in the chain, which could be the CA's key (master or intermediate) or your own.

    • (Score: 2) by frojack on Thursday July 02 2015, @03:58AM

      by frojack (1554) on Thursday July 02 2015, @03:58AM (#204079) Journal

      You do have to wonder how much of those 70,000 lines are handling corner cases that have been shoveled into OpenSSL that are not needed by most applications. I'm tempted to break out a verse from the Mikado and suggest that for the most part "They never would be missed".

      --
      No, you are mistaken. I've always had this sig.
    • (Score: 0) by Anonymous Coward on Thursday July 02 2015, @05:11AM

      by Anonymous Coward on Thursday July 02 2015, @05:11AM (#204104)

      It does sound like it will eventually be a great addition. But, I suspect that this lean implementation is probably ignoring things like side channel attack mitigation and such. Crypto code seems to have a lot of crufty looking stuff intentionally added to do things like take a constant amount of time if success or fail etc. Even if this doubles in size to handle all the mitigation, it will still be lean-ish.

    • (Score: 2) by davester666 on Thursday July 02 2015, @05:12AM

      by davester666 (155) on Thursday July 02 2015, @05:12AM (#204105)

      Just great. They just release a new code base, and the first thing they get is feature creep.

      • (Score: 2) by kaszz on Thursday July 02 2015, @11:15AM

        by kaszz (4211) on Thursday July 02 2015, @11:15AM (#204163) Journal

        Do you have any particular feature in mind?

  • (Score: 0) by Anonymous Coward on Thursday July 02 2015, @12:12PM

    by Anonymous Coward on Thursday July 02 2015, @12:12PM (#204176)

    Things that matter for geeks, ffs!

    • (Score: 3, Informative) by Anonymous Coward on Thursday July 02 2015, @12:46PM

      by Anonymous Coward on Thursday July 02 2015, @12:46PM (#204198)

      Apache Software License 2.0