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.
Introducing s2n, a New Open-Source TLS Implementation
41–50 of 104 posts
Re: Introducing s2n, a New Open-Source TLS Implementation
#42Earlier 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.
Re: Introducing s2n, a New Open-Source TLS Implementation
#43Re: Introducing s2n, a New Open-Source TLS Implementation
#44Can 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.
Re: Introducing s2n, a New Open-Source TLS Implementation
#45Earlier 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.
Re: Introducing s2n, a New Open-Source TLS Implementation
#46Earlier 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.
Re: Introducing s2n, a New Open-Source TLS Implementation
#47Earlier 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 ?
Re: Introducing s2n, a New Open-Source TLS Implementation
#48Re: Introducing s2n, a New Open-Source TLS Implementation
#49Earlier 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.
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> 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"
Yeah, who would name a crypto implementation something stupid like "swan". Oh wait... https://en.wikipedia.org/wiki/Openswan