SoylentNews is people
SoylentNews
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
(Score: 3, Informative) by NCommander on Thursday July 02 2015, @06:02AM
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
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.