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

31–40 of 217 posts

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

#31

Post by stigz »

fulafel wrote: post #17
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…

Speaking of go, it looks they will be patching this as well.

https://groups.google.com/g/golang-announce/c/dRtDK7WS78g

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

#32

Post by woodruffw »

timdoug wrote: post #30
speedgoose wrote: post #20

Earlier quoted context omitted.

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.

I adore Go, but it seems to be impacted too: https://groups.google.com/g/golang-announce/c/dRtDK7WS78g

This is almost certainly a different bug. I don't believe Go's standard library uses OpenSSL.

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

#33

Post by riffraff »

Xenoamorphous wrote: post #29
eastbound wrote: post #7

November 1st is a bank holiday in France, so a lot of sysadmins won’t be happy and systems will be vulnerable.

Spain, too.

Most of Europe with a historical Catholic majority. It's even an EU holiday.

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

#34

Post by timdoug »

woodruffw wrote: post #32
timdoug wrote: post #30

Earlier quoted context omitted.

I adore Go, but it seems to be impacted too: https://groups.google.com/g/golang-announce/c/dRtDK7WS78g

This is almost certainly a different bug. I don't believe Go's standard library uses OpenSSL.

You’re right re: implementation —- I’m drawing a conclusion solely from the coordinated disclosure that it’s a similar crypto/TLS issue.

If the Go issues were distinct I’d imagine they’d choose a different day to disclose/release?

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

#35

Post by woodruffw »

timdoug wrote: post #34
woodruffw wrote: post #32

Earlier quoted context omitted.

This is almost certainly a different bug. I don't believe Go's standard library uses OpenSSL.

You’re right re: implementation —- I’m drawing a conclusion solely from the coordinated disclosure that it’s a similar crypto/TLS issue. If the Go issues were distinct I’d imagine they’d choose a different day to disclose/release?

> If the Go issues were distinct I’d imagine they’d choose a different day to disclose/release?

I think it's just a funny coincidence. That's going based on what I know about the OpenSSL one; I don't know anything about the Go one. We'll find out!

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

#37

Post by tester756 »

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?

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

The ones that use Rust - Firefox and Windows

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

#39

Post by nine_k »

valenterry wrote: post #26
fulafel wrote: post #17

Earlier quoted context omitted.

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…

Well, Go isn't really a great language for safety either. Memory safety maybe yes, but not in general. Rust or Zig do much better here.

What makes Zig safer than Go, to your mind?

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

#40

Post by fulafel »

valenterry wrote: post #26
fulafel wrote: post #17

Earlier quoted context omitted.

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…

Well, Go isn't really a great language for safety either. Memory safety maybe yes, but not in general. Rust or Zig do much better here.

They don't have GC so they either make programs difficult to write (Rust) which hinders delivering secure replacements, or have use-after-free security problems (Zig) [1].

Use a GC when you can, it's the biggest programming productivity and quality improvement in PLT of the last 60+ years.

[1] Though I know Zig has some interesting mitigations, some used and some under research: https://news.ycombinator.com/item?id=31853964 https://lobste.rs/s/v5y4jb/how_safe_is_zig#c_vddk9j

Post reply on HN