Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenSSL Security Advisory

openssl.org

Post reply on HN
Print view View original

41–50 of 112 posts

Re: OpenSSL Security Advisory

#41

Post by omginternets »

fredmorcos wrote: post #36
jerf wrote: post #34

Earlier quoted context omitted.

It's not Rust, but: https://golang.org/pkg/crypto/tls/ I know it says "partial" implementation, but it's quite good even so, and has had everything I need. It doesn't do SSLv2, but nowadays that's more virtue than vice. Erlang has an independent SSL implementation as well; it binds to OpenSSL but as I understand it just uses the heavy-duty math parts, not the protocol parts, which are instead written in Erlang. Non-C…

(Just my opinion) I completely agree with everything you point out. The argument I am bringing up is not about implementation, it's about "if they didn't use C, they would have less (security) problems": No. C is the way it is towards secure coding because there are compromises to satisfy other dimensions. is either making huge sacrifices in these other dimensions or is at best an experiment. We understand C's weak p…

What are the sacrifices being made by, say, Rust?

I'm only superficially familiar with Rust, but my understanding was that it was basically "C with strong memory guarantees". I naively thought that its entire purpose was to avoid such trade-offs.

Re: OpenSSL Security Advisory

#42

Post by robryk »

Why is the severity of the first vulnerability high? It allows a denial of service on the server's side by a client and nothing else. The second vulnerability seems to be very similar in severity, except that it can be used both against clients and servers, and yet it is of just moderate severity. What am I missing?

Re: OpenSSL Security Advisory

#43

Post by gbrown_ »

cm3 wrote: post #25
dijit wrote: post #6

Luckily I moved everything to openbsd's libressl which is /mostly/ compatible. I wonder if this bug affects them, typically the HIGH's haven't[0] It really feels like every other week there is a bug in OpenSSL and after following along with the libressl blog I understand why- the code is an absolute mess[1] [0] http://undeadly.org/cgi?action=article&sid=20150319145126 [1] http://opensslrampage.org/page/49

Assuming we stay with a library written in C, a better approach would be for everyone to try to move to what's in BoringSSL, which deliberately removed most stuff, more than LibreSSL. If we still stay with C, Ring would be a good replacement, which is partially/primarily written in Rust. That said, LibreSSL's TLS abstractions look like a welcome improvement if you need a C API.

> a better approach would be for everyone to try to move to what's in BoringSSL

Google don't recommend you do this.

https://boringssl.googlesource.com/boringssl/

  BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.
  
  Although BoringSSL is an open source project, it is not intended for general
  use, as OpenSSL is. We don't recommend that third parties depend upon it.
> which deliberately removed most stuff, more than LibreSSL

LibreSSL has taken fixes from BoringSSL but it has the aim of maintaining API compatibility to the point where most applications using OpenSSL should "just work" for the most part. I've not tried building against BoringSSL but form reading their documentation it seems like the API is very much a moving target.

Re: OpenSSL Security Advisory

#44

Post by jaryd »

justinmayer wrote: post #32

As far as I can tell, patched OpenSSL packages for affected Debian/Ubuntu releases are not yet available. https://security-tracker.debian.org/tracker/CVE-2016-6304 https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2...

You'll typically see these come through USN (Ubuntu Security Notices) as they're available.

http://www.ubuntu.com/usn/

Re: OpenSSL Security Advisory

#45

Post by bluejekyll »

jerf wrote: post #34
fredmorcos wrote: post #31

Earlier quoted context omitted.

I hope I don't come across too harsh. Is HN still really up for that argument? Yes, we know the downsides of C. But the upside is that _we know the downsides of C_. Constantly complaining about C isn't going to get anyone anywhere. It's been shown over and over again that secure C coding is possible and doable and feasible and exists in the real world. Some of the most secure software is written in C, and that's not…

It's not Rust, but: https://golang.org/pkg/crypto/tls/ I know it says "partial" implementation, but it's quite good even so, and has had everything I need. It doesn't do SSLv2, but nowadays that's more virtue than vice. Erlang has an independent SSL implementation as well; it binds to OpenSSL but as I understand it just uses the heavy-duty math parts, not the protocol parts, which are instead written in Erlang. Non-C…

> It's not Rust, but: golang

This is a false choice. Go and Rust are not replacements for each other. They both have qualities which make each better suited for different environments.

Rust is actually capable of replacing all uses of C, Go's runtime will generally be an impediment to using it in certain cases.

Also I would argue that there are entire classes of bugs that are still available in Go that are not in Rust, that make it less suited for security. Null pointer exceptions, and unchecked errors are the two that come to mind.

Re: OpenSSL Security Advisory

#46

Post by pdevr »

>"Servers using OpenSSL versions prior to 1.0.1g are not vulnerable in a default configuration [..]"

In case anyone is using older versions, like we do in our production environment.

Re: OpenSSL Security Advisory

#47

Post by deweerdt »

beezle wrote: post #33

Wonderful. Glad I recently added OCSP support to servers. Arg! So does this affect TLSv1.2 only servers that do NOT support client renegotiation of any type?

This is the only claim that i've found saying that throttling (or disabling, for that matter) renegotiation would prevent the issue: https://twitter.com/Unreal_IRCd/status/778975019829489664

The advisory makes it sound like that would be the case, but it would have been great if that was explicitly stated.

Re: OpenSSL Security Advisory

#48

Post by bjourne »

danarmak wrote: post #30
bjourne wrote: post #24

Earlier quoted context omitted.

It won't end with Rust either since it is so appealing and easy to jump into unsafe territory.

Easy is not the same as necessary. At least high-security projects like OpenSSL could enforce a policy of not using unsafe code, and it's easy to validate that there's no unsafe code or that the few known instances are very well vetted.

You could do the same with C code -- it is getting everyone to follow the policies that is the hard part. Even compiling Rust code in release mode instead of debug removes some essential safety features. Should be clear by now that "policies" just doesn't work, but no, project are repeating the exact same mistake over and over again. :)

Re: OpenSSL Security Advisory

#49

Post by amenod »

fredmorcos wrote: post #36
jerf wrote: post #34

Earlier quoted context omitted.

It's not Rust, but: https://golang.org/pkg/crypto/tls/ I know it says "partial" implementation, but it's quite good even so, and has had everything I need. It doesn't do SSLv2, but nowadays that's more virtue than vice. Erlang has an independent SSL implementation as well; it binds to OpenSSL but as I understand it just uses the heavy-duty math parts, not the protocol parts, which are instead written in Erlang. Non-C…

(Just my opinion) I completely agree with everything you point out. The argument I am bringing up is not about implementation, it's about "if they didn't use C, they would have less (security) problems": No. C is the way it is towards secure coding because there are compromises to satisfy other dimensions. is either making huge sacrifices in these other dimensions or is at best an experiment. We understand C's weak p…

I would agree with you if it wasn't for Rust. If you don't know it yet, I would advise you read up about it - it is ideal for replacing C, being equal at speed and better at safety from common programming errors.

Re: OpenSSL Security Advisory

#50

Post by rurban »

turingbook wrote: post #23

>This issue was reported to OpenSSL by Shi Lei (Gear Team,Qihoo 360 Inc.) A Chinese hacker

No. See https://en.wikipedia.org/wiki/Qihoo_360

A very popular chinese anti-virus company which fashions the US freemium model, with advertising on their homepage being the biggest revenue, and a market cap of $11.42B. Not a hacker.

Post reply on HN