Slashdot Mirror

So why hasn't GnuTLS gained more traction? Do developers of applications that use TLS see something wrong with the LGPL?

LibreSSL is the one that deserves all the credit and support.

If you're going to talk about deserving and especially with regard to our support, GnuTLS is actually the one.

LibreSSL, like OpenSSL, is just a way to keep X.509 entrenched. As long as we keep using a PKI where each identity is certified by only a single party, and you either completely 100% trust the cert or not, most of the Internet is going to remain vulnerable to MitM attacks. This has nothing to do with code quality and it isn't a slam against the implementors; it's that they are implementing a broken idea.

X.509 is fine for your corporate intranet, but is totally inappropriate for any situation where two parties don't share a common "master." We need to stop using it for the public Internet. GnuTLS at least provides a way for moving forward to the post-1980s Internet, whereas most other SSL libraries (LibreSSL included) are stuck with only being able to solve the problem as it existed many decades ago.

So he tries to persuade people to agree with him, perhaps passionately, perhaps vehemently, maybe even not so nicely ... but (to my knowledge) he has never used force or fraud to coerce people into behaving the way he thinks they should.

It is pretty obvious that you have not worked for him.

You also seem to ignore how treacherous the GPLv3 is.

Think about this: When RMS wrote the GPLv2, linux didn't exist. RMS thought GNU would always be the main free OS out there, and that he would always be its master. Therefore, he designed the GPLv2 to keep GNU free.

Since linux has become more popular than GNU, RMS is trying to destroy linux. The (L)GPLv3 is designed to be specially incompatible with the GPLv2. The word "reuse" appeared in GPL 1 and 2, but has disappeared from GPLv3. RMS is forbiding people from use GPLv3 libraries in GPLv2 programs.

If you released a program under GPLv2+, it would remain GPLv2+; the GPLv2 forces to "keep intact" license notices (section 1). But GPLv3 allows license notices to be modified (section 5b). Therefore, if you release a program under GPLv3+, RMS can publish a non-free GPLv4, and then change all your license notices to GPLv4+, effectively forking a privative derivative of your work.

The GPLv3 is a trap. Don't use it. You have been warned.

In addition to greatly increasing costs (there are no free wildcard certs, and encryption does increase CPU workload, which decreases scalability), it also increases the barrier for writing your own tools to interoperate with the web (HTTP servers, clients, proxies, aggregators, etc.) If you've ever looked at the SSL libraries out there, all but the OpenBSD-only LibreSSL are a complete clusterfuck. This is the GnuTLS API, for instance. I won't even get into the security ramifications like Heartbleed. Whereas HTTP/1.1 can be spoken to by a human being using a telnet terminal, and even Commodore 64's have been made to serve up web pages.

Sadly, modern developers have completely lost touch with the value of making things small and simple.

OpenSSL remains the only portable SSL library that can be used by both open source and commercial developers alike. Which is really a shame, because OpenSSL sucks. All the bad things the libressl people have said about OpenSSL are absolutely true.

We have GnuTLS which is only one year younger than OpenSSL, has a nicer API, is portable to Windows, has a better track record with regard to binary compatibility, a better build system, and can be used by commercial software (it’s LGPLv2.1). Comparison of features with other SSL libraries.

It also has a much worse track record in security, which is why no one uses it as the a primary SSL library and only as a library for operating on certificates.

OpenSSL remains the only portable SSL library that can be used by both open source and commercial developers alike. Which is really a shame, because OpenSSL sucks. All the bad things the libressl people have said about OpenSSL are absolutely true.

We have GnuTLS which is only one year younger than OpenSSL, has a nicer API, is portable to Windows, has a better track record with regard to binary compatibility, a better build system, and can be used by commercial software (it’s LGPLv2.1). Comparison of features with other SSL libraries.

Been tried already; see gnutls. We tried to switch from OpenSSL to gnutls as the preferred SSL library for PostgreSQL a few years back, even got some press coverage documenting the whole thing. But, sadly, OpenSSL has too many quirky APIs to make a transition away from it easy. And anyone who tries to be "bug compatible" creating a replacement to that mess is going to inherit some of the same bad design that needs to be burned with fire.

Calm down, GnuTLS supports SSL, they've just decided that they're happier using GnuTLS as their encryption backend.

Thanks for the insult. It hardly stung.

Unless you worked at Netscape in the mid-1990s, no insult was intended.

All I meant is that by the very early 1990s, we (and by "we" I mean people smarter than me; I was clueless at the time) had a pretty good idea that CAs wouldn't work well outside of real power hierarchies (e.g. corporate intranets). But then a few years later the web browser people came along and adopted X.509's crap, blowing off the more recent PKI improvements, in spite of the fact that it looked like it wouldn't work well for situations like the WWW.

Unsurprisingly, it didn't work well. Organizing certificate trust differently than how real people handle trust, 1) allows bad CAs to do real damage, and 2) undermines peoples' confidence in the system.

A very nice way of saying this, is that in hindsight, the predicted problems are turning out to be more important than we thought most people would care about. ;-) It's almost as though now (no fair! you changed the requirements!!) people want SSL to be secure.

Keeping the same organization but with new faceless unaccountable trust-em-completely-or-not-at-all root CAs won't fix the problem. Having "root CAs" is the problem, and PRZ solved it, over 20 years ago.

I expect you to start the project shortly.

It's a little late to start, but I do happen to still be running an awful lot of applications (web browser being the most important one) which aren't using it yet.

There are alternatives, although I can't comment on how they compare with OpenSSL.

GnuTLS (LGPLv2.1)

Mozilla Network Security Services (Mozilla Public License)

PolarSSL (GPL2 and proprietary).

MatrixSSL (GPL and proprietary

We need a GNU/SSL fork too. GPL forever!

It exists, and is called GnuTLS. All the developers I've worked with who've looked at it and OpenSSL say it is worse than OpenSSL, although I don't remember the particulars of why. Feel free to support it if you prefer a GNU alternative.

gnuSSL? Although TLS should be supported, so maybe gnuTLS?

Been there, done that

GnuPG implements RFC4880. See also the OpenPGP alliance. GnuTLS implements SSL, TLS and DTLS. See also OpenSSL and PolarSSL.

Your userland software may or may not link against GnuTLS. It's probably more likely to link against OpenSSL.

It's important to understand the mechanisms involved with software that provides facilities for securing information both locally and in transit to others. It's nearly as important to do a bit of research on said mechanisms before engaging in discussions on them.

Right. Because it's not as if they found a bug in GnuTLS security the other week, that compromises HTTP security in many Linux apps. A bug that may or may not have been planted by the NSA, but either way has been undiscovered for 9 years.

A bug in a single library is not the end of the world. If anything the fact it was found means it can be fixed, which as it happens: it was.
Time to detect is meaningless. Some bugs exist today that have been there since the initial code was written. Not all of it is intentional. Treating it as if the developers knew about it and were conspiring against you, just because of how long it took to find the bug, is beyond idiocy.

Also mentioning the NSA having potential involvement is a scare tactic, shame on you.

There is nothing about Linux that makes it safer from government hacking.

That is true. No system exists that is safe from a determined individual or group that has the resources and ability to destroy / compromise it.

In fact the openness that allows many people, who's actual identities are not know to anyone, to contribute code makes it more vulnerable than a closed commercial OS.

So you personally trust every single closed source commercial developer for every piece of software you use then? How well do you know them? What makes them known to you so well that you would trust them to work in your best interests despite any form of compromise, coercion, blackmail, or other incentives? Do you honestly believe that they will always work in your best interests? Or do you think that because you paid them once that they are in your debt for life?

Do you know every single vulnerability that the software you use has and take precautions against it? Other than security through obscurity, what makes you think any software you use (closed or open source) is any more secure than any other software?

At least with a closed commercial OS you have to actually be an identifiable person working for the company to submit changes. Or risk posing as one. And there are people who are paid to do the boring testing and audits. Apple's equivalent of the GnuTLS bug was discovered in a matter of months, not years.

Once again verifiable to WHOM? No one but YOU will defend your best interests 100% of the time. A company is just as vulnerable to goverment meddling as an open-source project. Are you standing there watching every line of code being written, compiled and written to media? Examining each opcode that the system doing it is executing as well as the I/O generated? Placing blind faith in some random person who works for some random company is foolish. Just as placing blind faith in some random developer on the net commiting code to some random project is foolish. If you want security you have to verifiy it yourself. (I'm intentionaly ignoring the difficulity in doing that with software, but the point still stands as the act of doing so is not impossible just difficult.)

What makes you think that the testing (if it is done) is accurate and honest? Yes, just because they can be dishonest does not mean they are, but at the same time the opposite is true too.

Again time to detect is meaningless. To say that Apple is superior for finding their bug sooner than gnutls found theirs is pointless. What matters is that the bugs were fixed, not how long it took to find them after the fact. No one wins by saying "I found a bug in X amount of time!". Everyone benefits by saying "This bug is no longer an issue, as it has been fixed."

Yes, not everyone is out to get you. At the same time saying one thing is secure over another just because of how it MAY have been made, is blind faith and can be taken advantage of. You should really take the whole situation into account before making such claims, you (and all of us) will be better off for it if you do.

Captcha: threats

So when Apple's proprietary encryption software suffered a problem, Apple users could do nothing but wait for Apple to deliver a fix; there's nobody else that are allowed to fix Apple's proprietary software but Apple. And when that fix ostensibly arrived, Apple users had to hope it wasn't bundled with some malware too (as is often in proprietary software).

This bug was caught during an audit—"The vulnerability was discovered during an audit of GnuTLS for Red Hat.". Nobody but the proprietor can audit proprietary software. But with free software, users have the freedom to audit the code they run, patch that code, and run their patched code; users can choose to fix bugs themselves or get someone else to fix bugs for them. And users don't have to always trust the same people to do work on their behalf. Users can also choose to wait for a fix to be distributed, and then they can choose to check that fix to make sure it doesn't contain malware. For all we know some users have long spotted and fixed this bug in GNUTLS. Since all complex software has bugs bugs are unavoidable. We're better off depending on people we choose to trust. Software freedom is better for its own sake.

I got annoyed at the slashdot comments last time there was security hole in OpenSSH and wrote this page (copy pasted below). I count OpenSSL as insecure software - we need a secure replacement. GNUTLS looks somewhat better, but I don't trust it too much either.

Why is some software more secure than others?

How do you measure software security?

Here's my definition on what is secure software.

Intro

I get really tired of seeing these kinds of comments every time some widely used software has security holes:

• No software is secure. The difference is how quickly they fix it.
• It's good that they were found. Now we have less security holes.
• Popular software gets more security audits which is why they seem to have more security holes.

While they may be partially true, I think they're also very misleading and disparages the hard work that some secure software authors have done.

Simplicity Is Security

The difference between secure and insecure software is really the coding techniques being used by it's authors. Authors of secure software do everything they can to prevent accidental mistakes from ever happening. Authors of insecure software just fixes the accidental mistakes. There are very few secure software authors.

Auditing insecure software doesn't make it secure. Sendmail is a good example of this. It's been audited countless times by competent people. The simplest mistakes were catched easily long time ago, but a few very difficult to find vulnerabilities were found only recently.

How do secure software authors then avoid the kind of security holes that are difficult to find? By keeping the code simple. The code doesn't get secure by polluting it with tons of security checks. It gets secure by keeping the security checks in as few places as possible.

Auditing secure software is easy. You can just quickly browse through most of the sources without having to stop and look at it carefully. Everything just looks clean, simple and correct. vsftpd is a good example of this.

Sure, it's still possible that secure software has some security holes occationally. It just happens a lot less often (if ever) and usually the problems are less critical. For example none of the security holes in Postfix have lead to arbitrary code execution or being able to read other peoples mails. Denial of Service attacks are nothing compared to them.

(some examples in the web page not included)

I got annoyed at the slashdot comments last time there was security hole in OpenSSH and wrote this page (copy pasted below). I count OpenSSL as insecure software - we need a secure replacement. GNUTLS looks somewhat better, but I don't trust it too much either.

Why is some software more secure than others?

How do you measure software security?

Here's my definition on what is secure software.

Intro

I get really tired of seeing these kinds of comments every time some widely used software has security holes:

• No software is secure. The difference is how quickly they fix it.
• It's good that they were found. Now we have less security holes.
• Popular software gets more security audits which is why they seem to have more security holes.

While they may be partially true, I think they're also very misleading and disparages the hard work that some secure software authors have done.

Simplicity Is Security

The difference between secure and insecure software is really the coding techniques being used by it's authors. Authors of secure software do everything they can to prevent accidental mistakes from ever happening. Authors of insecure software just fixes the accidental mistakes. There are very few secure software authors.

Auditing insecure software doesn't make it secure. Sendmail is a good example of this. It's been audited countless times by competent people. The simplest mistakes were catched easily long time ago, but a few very difficult to find vulnerabilities were found only recently.

How do secure software authors then avoid the kind of security holes that are difficult to find? By keeping the code simple. The code doesn't get secure by polluting it with tons of security checks. It gets secure by keeping the security checks in as few places as possible.

Auditing secure software is easy. You can just quickly browse through most of the sources without having to stop and look at it carefully. Everything just looks clean, simple and correct. vsftpd is a good example of this.

Sure, it's still possible that secure software has some security holes occationally. It just happens a lot less often (if ever) and usually the problems are less critical. For example none of the security holes in Postfix have lead to arbitrary code execution or being able to read other peoples mails. Denial of Service attacks are nothing compared to them.

(some examples in the web page not included)

Despite fact OpenSSL is so widely used, there exist a project to make GPLed replacement for it - GNU Transport Layer Security Library.

It is useful for all those people, for whom BSD license is not enough free. I think that TLS (the new name for SSL, BTW) library is mandatory for GNU/Operating System. And because of GNU it has to be GPLed - now it means reimplemented from scratch.
I also fear, that it will be binary incompatible with OpenSSL - if so, it wouldn't gain popularity. It should be drop-in replacement.

But we will see - right now you can test it or go and help developing this crypto library.