Live data from Hacker News

Introducing s2n, a New Open-Source TLS Implementation

blogs.aws.amazon.com

41–50 of 104 posts

Re: Introducing s2n, a New Open-Source TLS Implementation

#41
post #39

Earlier quoted context omitted.

I think that's kind of the point. If your web server's TLS stack is trying to validate client certificates, you're doing it wrong.

There's nothing wrong with client certs (other than insane complexity). However ultimately s2n is likely to need to support operation as a client too at which point things like certificate validation etc. will be needed and the amount of code will increase.

Insane complexity is exactly why supporting client certs is a bad idea.

Re: Introducing s2n, a New Open-Source TLS Implementation

#42
post #39

Earlier quoted context omitted.

I think that's kind of the point. If your web server's TLS stack is trying to validate client certificates, you're doing it wrong.

There's nothing wrong with client certs (other than insane complexity). However ultimately s2n is likely to need to support operation as a client too at which point things like certificate validation etc. will be needed and the amount of code will increase.

Practical use of client certs usually implies support for renegotiation too.

Re: Introducing s2n, a New Open-Source TLS Implementation

#44
post #5

Can you use this library without having to use its IO capabilities? My biggest issue with OpenSSL is that it also tries to do IO, but does it in a not too well-performing and non cross-platform way.

At least with OpenSSL you can implement your own BIO objects and do the I/O yourself if you want/need to. It's not the cleanest or best-documented interface in the world, but it's certainly usable.

it is usable. But I think you would be hard pressed to find a more widely used piece of software that has absolute terrible documentation. The only real way to figure it out is to read the code or read the examples.

Re: Introducing s2n, a New Open-Source TLS Implementation

#45
post #23

Earlier quoted context omitted.

libcrypto includes the OpenSSL ASN.1 code, which is worrying as all hell, e.g.: https://git.openssl.org/?p=openssl.git;a=blob;f=crypto/asn1/... Or any file in that directory.

Oh man, that code is just horrible. No comments on some of the functions, no comments on the input parameters and return values pretty much throughout. I really thought OpenSSL was in a much better shape.

Code that implements standards should be read with the standard open next to it. This code: https://git.openssl.org/?p=openssl.git;a=blob;f=crypto/md5/m... looks like awful garbage, until you compare it to https://www.ietf.org/rfc/rfc1321.txt , and then you realize you don't really want comments or anything else cluttering up the implementation.

Re: Introducing s2n, a New Open-Source TLS Implementation

#46
post #23
post #18

Earlier quoted context omitted.

Nobody is particularly worried about libcrypto. There would be little point in reimplementing it's functionality.

libcrypto includes the OpenSSL ASN.1 code, which is worrying as all hell, e.g.: https://git.openssl.org/?p=openssl.git;a=blob;f=crypto/asn1/... Or any file in that directory.

I overlooked that, I was thinking of the crypto primitives there.

Re: Introducing s2n, a New Open-Source TLS Implementation

#47
post #24

Earlier quoted context omitted.

The bitcoin piñata recently ended, and they wrote a blog post about it: https://mirage.io/blog/bitcoin-pinata-results

It's interesting, but isn't 10BTC($2500) prize too low to tell us anything about how secure is this ?

I don't know the answer to that question, but that's about 2/3rds the price of a single billable day for cryptographic pentesting.

Re: Introducing s2n, a New Open-Source TLS Implementation

#49
post #39

Earlier quoted context omitted.

There's nothing wrong with client certs (other than insane complexity). However ultimately s2n is likely to need to support operation as a client too at which point things like certificate validation etc. will be needed and the amount of code will increase.

Insane complexity is exactly why supporting client certs is a bad idea.

Certainly true if you don't need them. However since code using the library as a TLS client is already partially present, support for certificate verification is definitely going to need to be added.

At the moment, I'm not that impressed with the testing since even making it build actually requires patching it! This is just due to one of the examples, but from the git history it's been broken since January.

Re: Introducing s2n, a New Open-Source TLS Implementation

#50
post #10

> s2n is short for “signal to noise” Anyone else think this was a contraction of the a11y, i18n, a16z or f6s variety?

Here are your options: sawn scan seen sewn shin shun sign skin soon sown span spin spun stun swan "Yeh, we're not vulnerable, because we've been using the swan library"

> "Yeh, we're not vulnerable, because we've been using the swan library"

Yeah, who would name a crypto implementation something stupid like "swan". Oh wait... https://en.wikipedia.org/wiki/Openswan

Post reply on HN