Hacker News Reader

Comment by jerf | Hacker News Reader

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?

View on HN

(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. <Fancy new language that promises to solve all of C's problems> 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.

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.

There are others too, e.g. ATS

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.

Certain things(circular structures) are harder to represent without dropping down to unsafe code(which is a C equivalent security model).

It's a bit more upfront work to satisfy the compiler but I've found the payoff in debugging memory issues to be completely worth it.

Right, so then it is a net advantage over C, with the (negligible) trade-off of compiler-wrangling. The parent comment seemed to suggest the contrary.

> 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.

I don't think they were offering up Go as an alternative to C, but rather giving an example of an OpenSSL implementation in a language that isn't C. Rust is mentioned because the prior comment called for the creation of a pure-Rust OpenSSL library as proof that Rust can be used in this context. No such things exists, but they were trying to offer up a similar example to prove the same point.

I don't know if this has changed, but at one point the author of crypto/tls basically said "this hasn't been audited or carefully looked at; do not use this code". Not exactly a ringing endorsement, even if he's stopped saying that.

Reply on news.ycombinator.com