91–100 of 104 posts
Earlier quoted context omitted.
Nobody is particularly worried about libcrypto. There would be little point in reimplementing it's functionality.
They aren't?
Both are bad, but I'd say that "remote root" trumps "side channel attack".
If I counted right: OCaml TLS: ~4400 LoC OCaml X509: ~1550 LoC OCaml ASN1: ~1400 LoC OCaml nocrypto: ~5250 LoC Total ~12600 LoC but you get a fully self-contained implementation, having only some crypto code in C and the rest as pure OCaml: https://mirage.io/blog/why-ocaml-tls https://mirage.io/blog/announcing-mirage-25-release
Also note that s2n links with OpenSSL (or LibreSSL, BoringSSL) for the ciphers and ASN.1 functionality. At first I was really surprised/impressed/worried that they managed to pull off an ASN.1 parser in C along with TLS is just 6,000 lines of code. Alas, they did not. So, when they mention the 500,000 lines of OpenSSL, they are probably actually using a good 20,000+ of it for ASN.1 and all of the ciphers. Yay marketi…
Earlier quoted context omitted.
No, sorry. The insane complexity is on the requirements. If you need client certs, anything you do to satisfy the need will be at least as complex.
Yes, but 99.999% of web servers don't need client certs.
Earlier quoted context omitted.
Also note that s2n links with OpenSSL (or LibreSSL, BoringSSL) for the ciphers and ASN.1 functionality. At first I was really surprised/impressed/worried that they managed to pull off an ASN.1 parser in C along with TLS is just 6,000 lines of code. Alas, they did not. So, when they mention the 500,000 lines of OpenSSL, they are probably actually using a good 20,000+ of it for ASN.1 and all of the ciphers. Yay marketi…
Still using it for ASN.1 is quite sad, given ASN.1 is where a fair few security bugs have been. If I'm not mistaken, this includes CVE-2015-0286, CVE-2015-0287, CVE-2012-2110, CVE-2009-0590, CVE-2009-0789, and CVE-2006-2937 from the last decade (and more if you go further back). The ciphers are pretty damned solid — the ASN.1 code… not so much. I'd argue that the ASN.1 parsing and the like is one of the areas that so…
However, he does not want to give it away.
ASN.1 is a rather hairy standard overall, but AFAIK only a part of it is needed for TLS.
Earlier quoted context omitted.
No! Let's have many implementations all with completely separate code bases. Then when the next security bug is found it won't affect the whole internet.
I can see that side of it, but when N >> M I don't really see how that helps things significantly. N = number of https sites M = number of tls implementations
Earlier quoted context omitted.
Sadly, we're not so flush with cash that we can significantly up the prize, which was itself a donation from the user community. It was quite amusing when some kind users donated Bitcoins into the piñata though :-) We really like the idea of continuing the self-service security bounties, irrespective of their size. One of the nice things about unikernels is that it makes it easy to link in logic like this -- in a con…
Self service security bounties seems like a very smart idea. Would self-service security bounties enable a distributed bounty ? where each site developer puts a relatively small bounty in his site and his bounty offers him a certain qualification in the eyes of customers , but from the hacker standpoint , if you hacked one , you hacked them all and hence you can collect multiple bounties ?
Earlier quoted context omitted.
Self service security bounties seems like a very smart idea. Would self-service security bounties enable a distributed bounty ? where each site developer puts a relatively small bounty in his site and his bounty offers him a certain qualification in the eyes of customers , but from the hacker standpoint , if you hacked one , you hacked them all and hence you can collect multiple bounties ?
Isn't that pretty much what we have already with things like openSSL? Find an exploit and suddenly you've exposed everyone. I don't think public bounties would change any of the dynamics around this situation.
Also , pinata exposes all hacks in public, unlike today.
Earlier quoted context omitted.
Sadly I think you still need -lnsl -lsocket on solaris :(
Touché! (I think only -lsocket is required for send(2) though -- unless I'm misremembering, -lnsl is just for DNS lookups.) Still, there's relatively few portability issues these days: 1. Some platforms don't define MSG_NOSIGNAL. (You can work around this via setsockopt.) 2. Some platforms don't define CLOCK_REALTIME. (On platforms which don't provide that, you should be able to use gettimeofday.) 3. Some platforms d…
Earlier quoted context omitted.
Touché! (I think only -lsocket is required for send(2) though -- unless I'm misremembering, -lnsl is just for DNS lookups.) Still, there's relatively few portability issues these days: 1. Some platforms don't define MSG_NOSIGNAL. (You can work around this via setsockopt.) 2. Some platforms don't define CLOCK_REALTIME. (On platforms which don't provide that, you should be able to use gettimeofday.) 3. Some platforms d…
Autotools for these pretty simple things is an okay approach, but then people tend to go overboard, and that's when it gets horrible (or autoconf itself breaks libxnet detection cause it gets some quoting or who knows what wrong in some release). My personal pet peeve is people detecting endian in obtuse ways that totally fails during cross-compiling when there's the perfectly fine ntoh family.