4 ms·

There was a GnuTLS vulnerability introduced in 2000 was discovered in 2014 due to an audit. To summarize there was a refactoring that had no accompanying test

by evmar 11y ago

There was a GnuTLS vulnerability introduced in 2000 was discovered in 2014 due to an audit. To summarize there was a refactoring that had no accompanying test coverage that had the effect of inverting a check. Bugs happen to everyone, but the process that led to this one is really concerning. (OpenSSL certainly has bad process too but as the GP mentions, more people are hammering on it.) This blog post has more (including an LWN article about it): http://gehrcke.de/2014/03/gnutls-vulnerability-is-unit-testing-a-matter-of-language-culture/ http://gehrcke.de/2014/03/gnutls-vulnerability-is-unit-testi...

JoshTriplett 11y ago
Every security library has had vulnerabilities, and I'd be more concerned about libraries that don't (since it implies nobody is looking). Does GnuTLS seem significantly more prone to vulnerabilities than other implementations?
- tptacek 11y ago
  I would flag use of GnuTLS in an audit. Sev:lo.
  - JoshTriplett 11y ago
    What would you recommend that isn't derived from the OpenSSL codebase, for C projects that can't use OpenSSL for license reasons? Your recommendation for TLS elsewhere in the thread was: > You should use BoringSLL, LibreSSL, Go crypto/tls, or OpenSSL, in roughly that order. Three of those are based on OpenSSL, and Go crypto/tls presumably only works with Go.
    - tptacek 11y ago
      Porting to Windows and using schannel. Sorry.
      - JoshTriplett 11y ago
        Guess I'll be sticking to GnuTLS then, if there's no better option available for GPLed projects to use.
        walyne 11y ago
        Another option is wolfSSL (https://wolfssl.com/wolfSSL/Home.html https://wolfssl.com/wolfSSL/Home.html) which is GPL-compatible, but also has a commercial license option. They have an OpenSSL compatibility layer, but are not a derivative of OpenSSL. My experience with their software has been very positive, and they have avoided the majority of recent insecurities. Plus they have great support for anyone working on open source projects.

by evmar 11y ago

JoshTriplett 11y ago

Every security library has had vulnerabilities, and I'd be more concerned about libraries that don't (since it implies nobody is looking). Does GnuTLS seem significantly more prone to vulnerabilities than other implementations?

tptacek 11y ago
I would flag use of GnuTLS in an audit. Sev:lo.
- JoshTriplett 11y ago
  What would you recommend that isn't derived from the OpenSSL codebase, for C projects that can't use OpenSSL for license reasons? Your recommendation for TLS elsewhere in the thread was: > You should use BoringSLL, LibreSSL, Go crypto/tls, or OpenSSL, in roughly that order. Three of those are based on OpenSSL, and Go crypto/tls presumably only works with Go.
  - tptacek 11y ago
    Porting to Windows and using schannel. Sorry.
    - JoshTriplett 11y ago
      Guess I'll be sticking to GnuTLS then, if there's no better option available for GPLed projects to use.
      - walyne 11y ago
        Another option is wolfSSL (https://wolfssl.com/wolfSSL/Home.html https://wolfssl.com/wolfSSL/Home.html) which is GPL-compatible, but also has a commercial license option. They have an OpenSSL compatibility layer, but are not a derivative of OpenSSL. My experience with their software has been very positive, and they have avoided the majority of recent insecurities. Plus they have great support for anyone working on open source projects.