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

BearSSL – Smaller SSL/TLS

bearssl.org

Post reply on HN
Print view View original

201–206 of 206 posts

Re: BearSSL – Smaller SSL/TLS

#201

Post by pcwalton »

bandrami wrote: post #197
pcwalton wrote: post #193

Earlier quoted context omitted.

I don't mean "isomorphic" in that every Rust feature has a corresponding C feature. I mean that you can replicate every runtime C feature in Rust, and vice versa. The advantage of Rust is that you get a lot more safety guarantees and ergonomic features out of the compiler than you would with C.

Are any of those safety guarantees important to a crypto project, though? Even heartbleed wasn't a "buffer overrun" in the memory safety sense of that word: the client was asking for and receiving the contents of memory that the server had every right, from a safety standpoint, to read from.

Absolutely. You're confusing Heartbleed and Tedbleed.

https://tonyarcieri.com/would-rust-have-prevented-heartbleed...

Re: BearSSL – Smaller SSL/TLS

#202

Post by oconnor663 »

bandrami wrote: post #184
oconnor663 wrote: post #21

Earlier quoted context omitted.

A lot of people are arguing that new projects like this should use Rust. Like https://github.com/ctz/rustls .

But rust has the exact same problem: if it's "safe", it's ironically not "secure" because the algorithm no longer controls its own memory operations. If you can't say, for instance, that the key is never swapped out, then it's not secure. But if you can say the key is never swapped out, you're at a level of direct memory control that is no longer "safe".

I think "memory that is never swapped to disk" would fit nicely into Rust's ownership/borrowing model. It would probably just be a variant on Box that makes more guarantees, but which exposes the same safe interfaces? Having a safe API built on top of unsafe calls is more or less how everything in Rust works (maybe how any safe language works?), when you drill down far enough.

That said, I guess you'd have to be careful to avoid creating something like a NoSwapBox, because the NoSwap property would only apply to the (ptr, capacity, length) triple of the vec, and not to its actual heap allocation that you probably care about. Maybe the answer there is something like requiring that the contents of NoSwapBox implement Copy, or some other way of saying "this is plain old data"? I don't know enough about the plans for custom allocators to say anything intelligent :p

Re: BearSSL – Smaller SSL/TLS

#203

Post by SOLAR_FIELDS »

NeutronBoy wrote: post #163
israrkhan wrote: post #125

Seems like it is trying to replace PolarSSL (now called mBed TLS). It even dervies the name from PolarSSL (Polar Bear). It is nice to have multiple options, however it can make the vulnerability management a nightmare. How many more SSL libraries do we need (OpenSSL, LibreSSL,S2N,GnuTLS), not to mention native SSL libraries (Secure Transport, SChannel)?

> It even dervies the name from PolarSSL (Polar Bear I thought it was a play on 'bare' - e.g. only the basic features needed.

Probably a triple entendre as the author is a frequent poster and high rep user on Security StackExchange where his profile pic has been a bear for years. The community even has a couple in jokes about it because one of the other high rep users also has a picture of a bear as his profile picture and they are affectionately referred to as "big bear" and "little bear".

Re: BearSSL – Smaller SSL/TLS

#204

Post by bandrami »

pcwalton wrote: post #201
bandrami wrote: post #197

Earlier quoted context omitted.

Are any of those safety guarantees important to a crypto project, though? Even heartbleed wasn't a "buffer overrun" in the memory safety sense of that word: the client was asking for and receiving the contents of memory that the server had every right, from a safety standpoint, to read from.

Absolutely. You're confusing Heartbleed and Tedbleed. https://tonyarcieri.com/would-rust-have-prevented-heartbleed...

Oh, wow, thank you! I totally had conflated those two in my head. (Let this go down as a rare instance of a HN commenter not doubling down on being wrong...)

Re: BearSSL – Smaller SSL/TLS

#205

Post by xdej »

pornin wrote: post #6
rdeboo wrote: post #2

One of the cliches about crypto is that you should not implement your own crypto. Not to suggest that the authors don't know what they are doing, but they mention 'alpha' quality themselves on the site. I wonder, how long does it take until a new library is deemed secure? What does the process look like? Trial and error? Or do they compare notes with vulnerabilities found in e.g. openssl?

It is a combination of "many eyes" and "good documentation". What is needed is some good text that describes the design choice, the rationale, and all the tricky details; and then people who read it and think about it. I'll write and publish such text within the next few months.

You could use some of your 233,693 reputation points as bounties on security.SE to attract people to read and think about bearssl.

Re: BearSSL – Smaller SSL/TLS

#206

Post by pfalcon »

pornin wrote: post #43
unwind wrote: post #36

This sounded very interesting. However, it seems it's been developed "in secret" and the only public commit is a huge import of all of it. :/ Too bad, the development history would have been very interesting to read, digesting it all at once is harder.

Honestly, all my internal git commit messages are "...". I intend to write (in many details) how the whole thing is designed. Give me a couple of months.

> Honestly, all my internal git commit messages are "...".

Very insightful about how security experts write security code, thanks! All that documentation which you hope to write some time - half of it should have been in your commit messages (that's what they teach on StackOverflow, no?)

Post reply on HN