On Mon, Oct 24, 2016 at 02:36:23PM -0600, Warren Young wrote: > On Oct 24, 2016, at 2:16 PM, Joerg Sonnenberger <jo...@bec.de> wrote: > > > > On Mon, Oct 24, 2016 at 09:56:45AM -0600, Warren Young wrote: > >> The only common exception is this recent trend of replacing old, > >> bloated software that grew organically over decades with well-focused > >> fresh alternatives. (e.g. BIND vs nsd/unbound, LibreSSL vs OpenSSL, > >> Postfix vs Sendmail, etc.) > > > > Bad examples. BIND was rewritten from scratch on a regular base > > Really? The only time BIND was ever completely rewritten to my > knowledge was for BIND 9, which is now 16 years old.
Either BIND4 or BIND5 was a complete rewrite as well. > More to the point, nsd + unbound still isn’t as functional as BIND 9, > meaning there are fewer places for bugs to hide. Well, the primary difference is that nsd by design is not caching. That rules out all the cache poisoning attacks, one of the biggest problems in bad BIND deployments. Of course, if you followed DNS best practises, you would have been using authoritive-only servers with BIND as well... > > LibreSSL doesn't fix any of the fundamental issues of OpenSSL > > It fixes at least one, being the OpenSSL had turned into a kind of > crypto dumping ground, so that the library supports virtually every > weird crypto idea that’s ever been tried out around the SSL space for > the past couple of decades. So? The crypto primitives rarely have any issues at all. There is a somewhat questionable recent trend to make all kinds of timing "attacks" a major thing, but that's about it. > LibreSSL strips a whole lot of that out, so that it only supports > modern TLS, no legacy SSL or nonstandard extensions, and then only the > parts that are currently well-regarded, so that a program linked > against it is not vulnerable to any of the bugs in those rarely-used > parts of OpenSSL. I know the marketing language as well. It completely forgets that the primary reason why a lot of software was still using OpenSSL until recently was exactly this compatibility. SSLv3 hasn't even decomposed properly yet. The reality is that if your customer facing web server rejects a non-trivial number of potentially paying customers, people are going to hang the admin. It doesn't matter whether there are some theoretical security issues if a company is losing enough revenue. There are still a lot of devices installed that only support SSLv3. There is a reason why the deprecation process took so long. > There have been cases where a program linked against OpenSSL was vulnerable > but not when linked to LibreSSL: > > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3566 > https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3567 ...and there have been cases where LibreSSL riped things out and broke things by that. > If you simply mean that there is a certain amount of horridness to the > OpenSSL API and that LibreSSH shares this, then yes, that is true. > The only fix is a redesign, which means you break compatibility with > all the programs that currently depend on OpenSSL or LibreSSL. It is not a certain amount. The API is one of the worst thing ever done. LibreSSL hasn't improved things at all by claiming to be OpenSSL 2.x or some other random junk. > Ideally, LibreSSL is just a bridge to something better, but knowing the > way software inertia works, I wouldn’t bet on us getting to that > something-better any year soon. Better alternatives exist. Many of them were not feasible for a long time due to the SSLv3 constraint, but that is finally gone. One of the problems is that dealing with complex highly conditional data structures is a mess in C. It gets worse when people assume that char arrays are NUL-terminated etc. At the same time, library developers want to constraint the input without understanding the way how X509 is used in practise. Correct TLS use is more than just "use this certificate and encrypt that data"... > > Postfix is more secure than (old) sendmail due to a different > > architecture. :) > > Yes, Postfix is a pile of much smaller cooperating programs rather than > a monolithic program as with sendmail, each of which may be debugged > and privilege separated from the rest, which is exactly my point. > (“…well-focused fresh alternative…”) sendmail has also been reworked to fix some of the implementation problems. It is telling that the last CVE is from 2014 and the one before was from 2009. That's a lot better than some of the replacements designed for "security". Which brings back the original point of "mature" != "insecure". Joerg _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
