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

OpenSSL Audit

cryptoservices.github.io

Post reply on HN
Print view View original

41–50 of 82 posts

Re: OpenSSL Audit

#41

Post by CJefferson »

mp3geek wrote: post #40
technofiend wrote: post #12

Surprised no one has yet mentioned LibreSSL, OpenBSD's fork which happened after the last major bug. http://www.libressl.org/

OpenSSL development far exceeds LibreSSL, I believe they should fix OpenSSL instead of trying to fork it. OpenSSL: http://git.openssl.org/gitweb/?p=openssl.git;a=shortlog vs LibreSSL: https://github.com/libressl-portable/portable/commits/master Seems LibreSSL is a mainly a one-man band?

You are looking at the wrong repository -- that is a portable version of libressl (I agree it's non-obvious how to find the true repository, as it is stored in CVS).

This is closer, and a bit busier: https://github.com/libressl-portable/openbsd

Re: OpenSSL Audit

#42

Post by Aissen »

willglynn wrote: post #21
josephg wrote: post #8

Speaking of OpenSSL, what state are the competing libraries in at the moment? I'd love a version of OpenSSL without all the potentially-insecure legacy code given all the problems its had. Are there decent implementations of OpenSSL in more secure languages like Rust?

Go has a TLS package and dependencies which are almost entirely written in Go: http://golang.org/pkg/crypto/tls/

Go's TLS stack is very nice but beware of the default tlsConfig (containing insecure 3DES and RC4 algorithms): https://wiki.mozilla.org/Security/Server_Side_TLS#Go

Also, it might be vulnerable to side-channel timing attacks: https://www.imperialviolet.org/2013/02/04/luckythirteen.html

Re: OpenSSL Audit

#43

Post by Padding »

xorcist wrote: post #38
AnthonyMouse wrote: post #33

Earlier quoted context omitted.

> Not to say that situation isn't bad, but you can't compare it to C++ because nobody ever thought running untrusted C++ code without some other sandboxing was a good idea. This is actually kind of a point for the other side. You can sandbox code regardless of what language it's written in. Maybe what we need is not better languages but better sandboxes. Even when code is "trusted", if the developer knows it doesn't…

True, and a malfunctioning sandbox is worse than useless. People tend to base security on them. Google did in their AppEngine cloud, but they put a lot of engineering resources and defence-in-depth behind it.

> a malfunctioning sandbox is worse than useless

Are there any sandboxes in existence which are definitely not worse than useless?

Re: OpenSSL Audit

#44

Post by mp3geek »

CJefferson wrote: post #41
mp3geek wrote: post #40

Earlier quoted context omitted.

OpenSSL development far exceeds LibreSSL, I believe they should fix OpenSSL instead of trying to fork it. OpenSSL: http://git.openssl.org/gitweb/?p=openssl.git;a=shortlog vs LibreSSL: https://github.com/libressl-portable/portable/commits/master Seems LibreSSL is a mainly a one-man band?

You are looking at the wrong repository -- that is a portable version of libressl (I agree it's non-obvious how to find the true repository, as it is stored in CVS). This is closer, and a bit busier: https://github.com/libressl-portable/openbsd

I stand corrected regarding the libressl repo, Regarding active development, it still doesn't look that busy.

Sure more people committing but several days with no changes, vs the commit changes on OpenSSL.

Re: OpenSSL Audit

#45

Post by Dewie »

weland wrote: post #37
seanwilson wrote: post #26

Earlier quoted context omitted.

I don't understand this argument. For example, if I use a language that doesn't allow buffer overflows to happen, I've eliminated an entire class of security bugs being caused by programmer error. Why would you not want to use such a language? Performance and existing libraries will factor in to this obviously but I don't understand why you wouldn't consider security built into the language as a benefit. Yes, securit…

> For example, if I use a language that doesn't allow buffer overflows to happen, I've eliminated an entire class of security bugs being caused by programmer error. There are several assumptions behind "if I use a language that doesn't allow buffer overflows to happen" which you aren't taking into account. For instance, are you entirely sure that the implementation of that language's compiler will not allow buffer ov…

From comments I read about that when it was written, it's not clear to me that the author actually demonstrated the same behaviour of Heartbleed. I'm not the person to be the judge of that, but for what it's worth here is the top comment from /r/rust on the topic. Then you can make up your own mind about that.

https://www.reddit.com/r/rust/comments/2uii0u/heartbleed_in_...

Re: OpenSSL Audit

#46

Post by mrweasel »

mp3geek wrote: post #44
CJefferson wrote: post #41

Earlier quoted context omitted.

You are looking at the wrong repository -- that is a portable version of libressl (I agree it's non-obvious how to find the true repository, as it is stored in CVS). This is closer, and a bit busier: https://github.com/libressl-portable/openbsd

I stand corrected regarding the libressl repo, Regarding active development, it still doesn't look that busy. Sure more people committing but several days with no changes, vs the commit changes on OpenSSL.

OpenBSD is about to tag 5.7 for release. During the release window commits normally drop to only include minor changes. Once the tree is tagged all the patches sitting in the developers private trees can go in.

Regarding libressl I'm not sure how it works, but I think the OpenBSD cvs server is a better source that the github repo (http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/), but I'm not sure.

Also I'm not sure that a rapid flow of commits are necessarily a good indicator of quality.

Re: OpenSSL Audit

#47

Post by weland »

Dewie wrote: post #45
weland wrote: post #37

Earlier quoted context omitted.

> For example, if I use a language that doesn't allow buffer overflows to happen, I've eliminated an entire class of security bugs being caused by programmer error. There are several assumptions behind "if I use a language that doesn't allow buffer overflows to happen" which you aren't taking into account. For instance, are you entirely sure that the implementation of that language's compiler will not allow buffer ov…

From comments I read about that when it was written, it's not clear to me that the author actually demonstrated the same behaviour of Heartbleed. I'm not the person to be the judge of that, but for what it's worth here is the top comment from /r/rust on the topic. Then you can make up your own mind about that. https://www.reddit.com/r/rust/comments/2uii0u/heartbleed_in_...

That comment sort of illustrates my point:

> You should note that Rust does not allow unintialized value by design and thus it does prevent heartbleed from happening. But indeed no programming language will ever prevent logic bugs from happening.

Under OpenBSD, that values would not have been uninitialized, were it not for OpenSSL's silly malloc wrapper -- a contraption of the sort that, if they really wanted, they could probably implement on top of Rust as well. What is arguably a logic mistake compromised the protection of a runtime that, just like Rust, claimed that it would not allow uninitialized values, "by design".

Of course, idiomatic Rust code would not fall into that trap -- but then arguably neither would idiomatic C code. It's true that Rust also enforces some of the traits of its idioms (unlike C), but as soon as -- like the OpenSSL developers did in C, or like Unangst did in that trivial example -- you start making up your own, there's only that much the compiler can do.

At the end of the day, the only thing that is 100% efficient is writing correct code. Better languages help, but it's naive to hope they'll put an end to bugs like these when they haven't put an end to many other trivial bugs that we keep on making since the days of EDSAC and Z3.

Re: OpenSSL Audit

#48

Post by nailer »

tedunangst wrote: post #32
hackuser wrote: post #23

Earlier quoted context omitted.

Is there any coordination between OpenBSD and the Linux Foundation? For example, did the Linux Foundation consider adopting OpenBSD's fork rather than auditing and fixing the original? EDIT: What is the status of LibreSSL?

Auditing and fixing the original still improves LibreSSL, although one of the main goals of LibreSSL was to clean things up to make that easier. Last LibreSSL release was 2.1.4 last week, although a minor update should be coming soon. http://marc.info/?l=openbsd-announce&m=142543818707898&w=2 LibreSSL is going to track OpenBSD versions, so now that OpenBSD 5.7 is done, the LibreSSL 2.1.x series is done (except to rec…

libressl's binary is already half the size of openssl. I wonder if the audit is re-doing existing work to some extent.

Re: OpenSSL Audit

#49

Post by nailer »

zobzu wrote: post #24

Wll thats pretty awesome :) I'm hoping we don't have to patch everything tomorrow but.. ;) On a side note - a lot of libs start to implement their own crypto because "OpenSSL code sux its terrible and buggy!" impression. This scares me. These won't get much exposure and will most likely be full of implementation bugs that nobody will ever review - except bad guys and the NSA.

> On a side note - a lot of libs start to implement their own crypto because "OpenSSL code sux its terrible and buggy!" impression.

I don't think they'd do that - it's be far easier to grab libressl or boringssl. If you're aware that openssl is buggy, you're probably aware that writing your own crypto when you're not a cryptographer is worse.

Re: OpenSSL Audit

#50

Post by Dewie »

weland wrote: post #47
Dewie wrote: post #45

Earlier quoted context omitted.

From comments I read about that when it was written, it's not clear to me that the author actually demonstrated the same behaviour of Heartbleed. I'm not the person to be the judge of that, but for what it's worth here is the top comment from /r/rust on the topic. Then you can make up your own mind about that. https://www.reddit.com/r/rust/comments/2uii0u/heartbleed_in_...

That comment sort of illustrates my point: > You should note that Rust does not allow unintialized value by design and thus it does prevent heartbleed from happening. But indeed no programming language will ever prevent logic bugs from happening. Under OpenBSD, that values would not have been uninitialized, were it not for OpenSSL's silly malloc wrapper -- a contraption of the sort that, if they really wanted, they c…

> Under OpenBSD, that values would not have been uninitialized, were it not for OpenSSL's silly malloc wrapper -- a contraption of the sort that, if they really wanted, they could probably implement on top of Rust as well. What is arguably a logic mistake compromised the protection of a runtime that, just like Rust, claimed that it would not allow uninitialized values, "by design".

I really disagree. Rust does not allow uninitialized values by design - end of story. If a piece of Rust code let's uninitialized values bleed through, then it is broken. The semantics of Rust demands this.

(OpenSSL on the other hand only broke/Overrode OpenBSD's malloc - they didn't break C.)

It is news to no one that you can break - break - Rust's semantics if you use anything that demands `unsafe`. That's why anyone who uses `unsafe` and intends to wrap that `unsafe` in a safe interface has to be very careful.

Complaining about Rust being unsafe - in the specific sense that the Rust devs use - by using the `unsafe` construct, is like complaining that Haskell is impure because you can use `unsafePerformIO` to `launchMissiles` from a non-IO context.

> Of course, idiomatic Rust code would not fall into that trap -- but then arguably neither would idiomatic C code.

It's not even a question of being idiomatic. If someone codes in safe (non-`unsafe`) Rust, then they should not fall into the trap that you describe. If they do, then someone who implemented something in an `unsafe` block messed up and broke Rust's semantics.

What if that same thing happened in C? Well, then it's just another bug.

---

I'd bet you'd be willing to take it to its next step, even if we assume that a language is 100% safe from X no matter what the programmer does - "what if the compiler implementation is broken?". And down the rabbit hole we go.

Post reply on HN