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

Patch OpenSSL on November 1 to avoid “critical” security vulnerability

globalsign.com

Post reply on HN
Print view View original

11–20 of 217 posts

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#11

Post by pyuser583 »

29athrowaway wrote: post #10
RealStickman_ wrote: post #8

Earlier quoted context omitted.

Get started then. We can't use something with no track record nor releases published in production systems.

Then rewrite in Ada or whatever. Ada has been around for a while and has been used in important projects.

Is Ada memory safe? I don’t think it is.

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#12

Post by yjftsjthsd-h »

29athrowaway wrote: post #10
RealStickman_ wrote: post #8

Earlier quoted context omitted.

Get started then. We can't use something with no track record nor releases published in production systems.

Then rewrite in Ada or whatever. Ada has been around for a while and has been used in important projects.

Are there TLS implementations in Ada that have a track record? I don't think that remark was aimed at the language, only pointing out that writing a new TLS library in a safer language is not exactly a trivial expenditure of resources.

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#13

Post by yjftsjthsd-h »

pyuser583 wrote: post #11
29athrowaway wrote: post #10

Earlier quoted context omitted.

Then rewrite in Ada or whatever. Ada has been around for a while and has been used in important projects.

Is Ada memory safe? I don’t think it is.

https://www.reddit.com/r/ada/comments/mme3jk/is_ada_memory_s... seems to think so, although unfortunately I'm not qualified to evaluate it (so take this with a medium-large grain of salt...)

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#14

Post by 29athrowaway »

pyuser583 wrote: post #11
29athrowaway wrote: post #10

Earlier quoted context omitted.

Then rewrite in Ada or whatever. Ada has been around for a while and has been used in important projects.

Is Ada memory safe? I don’t think it is.

It is still a significant upgrade in terms of safety over C.

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#15

Post by 29athrowaway »

yjftsjthsd-h wrote: post #12
29athrowaway wrote: post #10

Earlier quoted context omitted.

Then rewrite in Ada or whatever. Ada has been around for a while and has been used in important projects.

Are there TLS implementations in Ada that have a track record? I don't think that remark was aimed at the language, only pointing out that writing a new TLS library in a safer language is not exactly a trivial expenditure of resources.

The track record of OpenSSL = memory management vulnerabilities. Vulnerabilities that are preventable.

Google: openssl "use-after-free" site:cvedetails.com/cve

It's time to accept that C is not the tool for the job. Good programmers still make mistakes and now we have tools to catch most of those mistakes.

In Rust many of those errors become compile-time errors.

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#16

Post by throwawaymaths »

bradleyjg wrote: post #6
Gigachad wrote: post #4

How many times does this have to happen before we start rejecting components written in unsafe languages?

You first. What browser and OS are you posting from?

If your server is in Erlang, it's probably dodged this (Erlang dodged heart bleed because it only uses ssl libs for cryptographic primitives)

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#17

Post by fulafel »

Gigachad wrote: post #4

How many times does this have to happen before we start rejecting components written in unsafe languages?

The start has happened, but it's happening unevenly with different users. Lots of TLS servers (in reverse proxies but also in backend apps and even Apache httpd[1]) are in memory safe languages.

For example Go, while not totally memory safe, has shipped their Go-implemented crypto/tls library for a long time. (And also had some crypto correctness bugs - reminding us that memory safety is "necessary but not sufficient" for a TLS implementation)

[1] https://www.memorysafety.org/blog/memory-safe-httpd/

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#19

Post by JSGdev »

mmwelt wrote: post #9

> And by widely leveraged, I mean almost completely ubiquitous, if you’re using HTTPS, chances are you’re using OpenSSL. Almost everyone is. This is probably a bit of an exaggeration. There are quite a few other SSL implementations that actually are also "widely leveraged"[1]. In particular, LibreSSL was forked and cleaned up after Heartbleed. Google uses BoringSSL. GnuTLS is widely used and unrelated to OpenSSL. [1]…

Yep we've been using rustls for most of a year no issues. Memory safety go brrr :) Would encourage others to take a look at it. Ring is a good base that's been audited and the lower attack surface from no old openssl bloat code makes a difference.

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#20

Post by speedgoose »

bradleyjg wrote: post #6
Gigachad wrote: post #4

How many times does this have to happen before we start rejecting components written in unsafe languages?

You first. What browser and OS are you posting from?

Not OS or browser but my SSH servers use Teleport and my HTTPS servers use Traefik or Caddy.

Caddy, Traefik, and Teleport are written in Golang and not using OpenSSL. It’s a start.

Post reply on HN