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

OpenSSL 4.0.0

github.com

Post reply on HN
Print view View original

61–70 of 89 posts

Re: OpenSSL 4.0.0

#61

Post by duskwuff »

Bender wrote: post #49
ameliaquining wrote: post #45

Earlier quoted context omitted.

It's not that adversaries can directly see the domain name; this doesn't have anything to do with domain fronting. The issue is that ECH doesn't hide the server's IP address, so it's mostly useless for privacy if that IP address uniquely identifies that server. The situation where it helps is if the server shares that IP address with lots of other people, i.e., if it's behind a big cloud CDN that supports ECH (AFAIK…

I can't speak for anyone else but I think I can work around that by moving the site around to different VPS nodes from time to time. I get bored with my silly hobby sites all the time and nuke the VM's then fire them up later which gives them a new IP. I don't know what others might do if anything. If I had a long running site I could do the same thing by having multiple font-end caching nodes using HAProxy or NGinx…

That's not quite it. The issue is that there's no other traffic bound to that IP - ECH doesn't buy you any security, because an observer doesn't even need to look at the content of the traffic to know where it's headed.

Re: OpenSSL 4.0.0

#62

Post by Bender »

duskwuff wrote: post #61
Bender wrote: post #49

Earlier quoted context omitted.

I can't speak for anyone else but I think I can work around that by moving the site around to different VPS nodes from time to time. I get bored with my silly hobby sites all the time and nuke the VM's then fire them up later which gives them a new IP. I don't know what others might do if anything. If I had a long running site I could do the same thing by having multiple font-end caching nodes using HAProxy or NGinx…

That's not quite it. The issue is that there's no other traffic bound to that IP - ECH doesn't buy you any security, because an observer doesn't even need to look at the content of the traffic to know where it's headed.

Maybe it will be more useful for outbound from NGinx or HAProxy to the origin server using ECH so the destination ISP has no idea what sites are on the origin assuming that traffic is not passing over a VPN already.

Re: OpenSSL 4.0.0

#63

Post by ocdtrekkie »

tredre3 wrote: post #46
ocdtrekkie wrote: post #40

Earlier quoted context omitted.

Once upon a time, like today? ICMP is most definitely only allowed situationally through firewalls today.

I'd say that ICMP is only situationally blocked by firewalls, not the other way around. Because I can ping almost any public server on the internet and they will reply. I can ping your website just fine and it replies to me!

You'd say incorrectly, firewalls have an implicit deny rule, so any case ICMP traverses a firewall, someone wanted it to. Obviously large hosting providers tend to find value in ICMP being enabled.

But for example, our firewall at work responds to ICMP but all of the endpoints which aren't meant for public use do not. That is less because ICMP is a problem and more because everything works fine without it and least privilege is good design.

ICMP is also more than just ping, and some parts of ICMP are considered a vulnerability if exposed to the public internet by some scanning services.

Re: OpenSSL 4.0.0

#64

Post by kccqzy »

awongh wrote: post #59
kccqzy wrote: post #15

Earlier quoted context omitted.

It’s still terrible. There was a brief period immediately after Heartbleed that it was rapidly improving but the entire OpenSSL 3 was a huge disappointment to anyone who cared about performance and complexity and developer experience (ergonomics). Core operations in OpenSSL 3 are still much much slower than in OpenSSL 1.1.1. The HAProxy people wrote a very good blog post on the state of SSL stacks: https://www.haprox…

Wow, also this: > The OpenSSL project does not sufficiently prioritize testing. [... ]the project was [...] reliant on the community to report regressions experienced during the extended alpha and beta period [...], because their own tests were insufficient to catch unintended real-world breakages. Despite the known gaps in OpenSSL’s test coverage, it’s still common for bug fixes to land without an accompanying regre…

This quote about testing is way worse:

> OpenSSL’s CI is exceptionally flaky, and the OpenSSL project has grown to tolerate this flakiness, which masks serious bugs. OpenSSL 3.0.4 contained a critical buffer overflow in the RSA implementation on AVX-512-capable CPUs. This bug was actually caught by CI — but because the crash only occurred when the CI runner happened to have an AVX-512 CPU (not all did), the failures were apparently dismissed as flakiness.

Re: OpenSSL 4.0.0

#66

Post by Neywiny »

Good to see const more prevalent. Too often I have to add that in to libraries for embedded. Possibly I believe in const by default but it is what it is at this point

Re: OpenSSL 4.0.0

#67

Post by kelnos »

ocdtrekkie wrote: post #31
hypeatei wrote: post #25

Earlier quoted context omitted.

Procrastinators. FTFY. Eventually these blocks won't be viable when big sites only support ECH. It's a stopgap solution that's delaying the inevitable death of SNI filtering.

This will never happen. Because between enterprise networks and countries with laws, ECH will end up blocked a lot of places. Big sites care about money more than your privacy, and forcing ECH is bad business. And sure, kill SNI filtering, most places that block ECH will be happy to require DPI instead, while you're busy shooting yourself in the foot. I don't want to see all of the data you transmit to every web prov…

> I don't want to see all of the data you transmit to every web provider over my networks

Then don't look. I'm serious. This idea that corporations need to snoop on everything their employees do is disgusting.

Re: OpenSSL 4.0.0

#68

Post by bombcar »

Bender wrote: post #56
ameliaquining wrote: post #54

Earlier quoted context omitted.

Anyone who wants to track your users can just follow the IP changes as they occur in real time.

Anyone who wants to track your users can just follow the IP changes as they occur in real time. That's cool. I only make my own mini-CDN's. There is always the option to put sites on a .onion domain but I don't host anything nearly exciting or controversial enough. For text that's probably a good option. I don't know if Tor is fast enough for binary or streaming sites yet. No idea how many here even know how to acces…

Tor is completely usable at reasonable speeds by even normies via Brave.

Re: OpenSSL 4.0.0

#69

Post by Bender »

bombcar wrote: post #68
Bender wrote: post #56

Earlier quoted context omitted.

Anyone who wants to track your users can just follow the IP changes as they occur in real time. That's cool. I only make my own mini-CDN's. There is always the option to put sites on a .onion domain but I don't host anything nearly exciting or controversial enough. For text that's probably a good option. I don't know if Tor is fast enough for binary or streaming sites yet. No idea how many here even know how to acces…

Tor is completely usable at reasonable speeds by even normies via Brave.

That's kindof what I suspected but have not kept up with it.

Re: OpenSSL 4.0.0

#70

Post by ocdtrekkie »

kelnos wrote: post #67
ocdtrekkie wrote: post #31

Earlier quoted context omitted.

This will never happen. Because between enterprise networks and countries with laws, ECH will end up blocked a lot of places. Big sites care about money more than your privacy, and forcing ECH is bad business. And sure, kill SNI filtering, most places that block ECH will be happy to require DPI instead, while you're busy shooting yourself in the foot. I don't want to see all of the data you transmit to every web prov…

> I don't want to see all of the data you transmit to every web provider over my networks Then don't look. I'm serious. This idea that corporations need to snoop on everything their employees do is disgusting.

So, if you are not at minimum inspecting SNI, you are not meaningfully providing security for your network. Where I work we do not really pay attention to what people are doing with their computers (that is an HR problem, not an IT problem), but the prevalence of ransomware almost certainly starts and ends with people not making rational network security decisions, which starts with filtering. We also remove the ads. =)
Post reply on HN