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

31–40 of 112 posts

Re: OpenSSL Security Advisory

#31

Post by fredmorcos »

nine_k wrote: post #21
hannob wrote: post #13

Earlier quoted context omitted.

What never ends? Low severity memory safety bugs in a large C codebase? Probably not. You may think this is a lot. It's not. This largely appears a lot because OpenSSL treats a lot of very low impact issues as vulnerabilities. A lot of other projecs would rather start arguing that this is not exploitable, should never get a CVE etc. This is a good sign. OpenSSL is taking security seriously by treating even low impact…

Exactly. With C, it will effectively never end. Libraries like that would probably benefit most from using a language with strict static analysis, like Rust. Tools Of similar nature for C do exist, but probably they are harder to apply, and likely not free.

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 attributed to enough fingers banging at a keyboard over a C program, but because C forces the programmer that _wants_ to write a secure program think about all the issues, the universe and everything.

So please, pave the road and show us the safer OpenSSL-rust you have. Until then good luck and thank you for your feedback.

Re: OpenSSL Security Advisory

#34

Post by jerf »

fredmorcos wrote: post #31
nine_k wrote: post #21

Earlier quoted context omitted.

Exactly. With C, it will effectively never end. Libraries like that would probably benefit most from using a language with strict static analysis, like Rust. Tools Of similar nature for C do exist, but probably they are harder to apply, and likely not free.

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 SSL implementations in memory-safe languages exist.

Note that "but are they as well road-tested" or similar such things would be moving the goal posts. Not necessarily wrong or bad objections, but different objections. Probably nothing, not even the other C implementations, is as well "road tested" as OpenSSL, but, then again, OpenSSL hasn't exactly passed that road testing with flying colors now, has it?

Re: OpenSSL Security Advisory

#35

Post by seanwilson »

fredmorcos wrote: post #31
nine_k wrote: post #21

Earlier quoted context omitted.

Exactly. With C, it will effectively never end. Libraries like that would probably benefit most from using a language with strict static analysis, like Rust. Tools Of similar nature for C do exist, but probably they are harder to apply, and likely not free.

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 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 attributed to enough fingers banging at a keyboard over a C program, but because C forces the programmer that _wants_ to write a secure program think about all the issues, the universe and everything.

This reasoning doesn't make sense. Use a language that makes a bunch of security flaws impossible (barring OS and compiler bugs anyway) so that you can concentrate properly on the possible security flaws left. Why deliberately make life hard for yourself if there are other language choices (assuming there are other choices to C in what you're doing)?

Even the best developers make mistakes. When you're picking your stack for security sensitive work you should be picking the stack that minimises the chance of mistakes and the impact of those mistakes. C is at high risk of making mistakes and those mistakes have a high chance of being exploitable.

Re: OpenSSL Security Advisory

#36

Post by fredmorcos »

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…

(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 points so well (due to being widespread, battle tested, really simple, or what have you), that most of the time it's safer (read: more secure) to tread dangerous well-understood territories carefully than uncharted ones only promising to be safe.

Re: OpenSSL Security Advisory

#37

Post by caf »

nine_k wrote: post #21
hannob wrote: post #13

Earlier quoted context omitted.

What never ends? Low severity memory safety bugs in a large C codebase? Probably not. You may think this is a lot. It's not. This largely appears a lot because OpenSSL treats a lot of very low impact issues as vulnerabilities. A lot of other projecs would rather start arguing that this is not exploitable, should never get a CVE etc. This is a good sign. OpenSSL is taking security seriously by treating even low impact…

Exactly. With C, it will effectively never end. Libraries like that would probably benefit most from using a language with strict static analysis, like Rust. Tools Of similar nature for C do exist, but probably they are harder to apply, and likely not free.

Is the "Severity: High" issue here the kind of thing that would be caught by Rust's static analysis, though? The bug isn't a case where the language rules are broken, but rather a failure to set a reasonable limit on the resource consumption that a client can cause.

Re: OpenSSL Security Advisory

#38

Post by Manishearth »

bjourne wrote: post #24
nine_k wrote: post #21

Earlier quoted context omitted.

Exactly. With C, it will effectively never end. Libraries like that would probably benefit most from using a language with strict static analysis, like Rust. Tools Of similar nature for C do exist, but probably they are harder to apply, and likely not free.

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

> so appealing and easy to jump into unsafe territory.

I've almost never seen unnecessary unsafe code being used in Rust. I've seen it very few times for performance, but it's carefully done.

Re: OpenSSL Security Advisory

#39

Post by Esau »

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

Question: on LibreSSL systems, is the binary still named openssl? I only ask because I seem to recall OS X having LibreSSL now but I still have a openssl binary.

Re: OpenSSL Security Advisory

#40

Post by gbrown_ »

Esau wrote: post #39
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

Question: on LibreSSL systems, is the binary still named openssl? I only ask because I seem to recall OS X having LibreSSL now but I still have a openssl binary.

> Question: on LibreSSL systems, is the binary still named openssl?

Yes.

Post reply on HN