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

Go-Safeweb

github.com

Post reply on HN
Print view View original

71–78 of 78 posts

Re: Go-Safeweb

#71

Post by gr4vityWall »

bayindirh wrote: post #54
gr4vityWall wrote: post #50

Earlier quoted context omitted.

> Think Raspi5/N100 NUC boxes as the target hardware. I don't think those would be negatively impacted by running Docker or Caddy. Isn't the performance cost of containers minimal these days? I had similar thoughts in the past, but when I looked up performance comparisons between running something on docker vs without a container, the resulting performance was practically identical.

The problem is not containerization per se, I run containers both in my personal systems and at work. If you extremely optimize for compilers, the performance difference can be trimmed down to 2%. I think for most of us, it's 5%-6% band, and it's OK for non-loaded servers. My qualm is about trimming fairly standard features and offloading it to somewhere else. A single HTTP service + traefik (or Apache/NGINX reverse…

> A single HTTP service + traefik (or Apache/NGINX reverse proxy) is heavier than a single HTTPS service.

How heavy are talking, and what would be the measured impact?

I have worked on small teams (3~4 people) where we had to use our own infrastructure for regulatory reasons. I also self-host a few things as a hobby. I don't think Nginx or Caddy were ever a bottleneck, and at the human level, they saved more resources than not using them. I don't remember the last time I exposed something to a network using their bundled http server directly rather than a reverse proxy. I don't like wasting computational resources of course, but % wise, 'optimizing' them by not using containers or a reverse proxy wouldn't net any visible gains - there's usually other low hanging fruit that gives you more for your time.

Re: Go-Safeweb

#72

Post by nine_k »

liveoneggs wrote: post #65
ongy wrote: post #45

Earlier quoted context omitted.

This might be me being daft, but I never quite understood the appeal of doing this with istio. OR also partially just due to the timing of when I started to care about things in k8s world. (Rather recently) My understanding of that model is that the services themselves still just do unauthenticated HTTP, this gets picked up on the client side by a sidecar, packed into mTLS/HTTPS, authed+unpacked on the server sidecar…

in the modern world extra network hops, novel userland network stacks, and additional cycles of decrypted/re-encrypting traffic make your apps go faster, not slower.

Not sure if it's ironic or not. Because it should be not.

AES-NI gives you encryption at the speed of memcpy basically. Userland network stacks are faster because they don't incur the kernel call cost. With that, if your NIC drivers support zero-copy access, an extra hop to a machine in the same rack over a 10G link is barely noticeable, may be shorter than an L3 miss.

The cost of this is mostly more hardware and more power used, but not much or any additional latency.

Re: Go-Safeweb

#73

Post by jakereps »

webprofusion wrote: post #36

Just use Caddy https://caddyserver.com/

Isn’t that equivalent to saying “just use NGINX”? Caddy isn’t a library you use in your Go server code, it’s a separate reverse proxy, isn’t it? They solve separate things.

Re: Go-Safeweb

#74

Post by liveoneggs »

nine_k wrote: post #72
liveoneggs wrote: post #65

Earlier quoted context omitted.

in the modern world extra network hops, novel userland network stacks, and additional cycles of decrypted/re-encrypting traffic make your apps go faster, not slower.

Not sure if it's ironic or not. Because it should be not. AES-NI gives you encryption at the speed of memcpy basically. Userland network stacks are faster because they don't incur the kernel call cost. With that, if your NIC drivers support zero-copy access, an extra hop to a machine in the same rack over a 10G link is barely noticeable, may be shorter than an L3 miss. The cost of this is mostly more hardware and mor…

lol

Re: Go-Safeweb

#75

Post by hu3 »

jakereps wrote: post #73
webprofusion wrote: post #36

Just use Caddy https://caddyserver.com/

Isn’t that equivalent to saying “just use NGINX”? Caddy isn’t a library you use in your Go server code, it’s a separate reverse proxy, isn’t it? They solve separate things.

One could:

import "github.com/mholt/caddy"

https://medium.com/backendarmy/embedding-a-web-server-in-go-...

Not sure if it's still the case.

Re: Go-Safeweb

#76

Post by kortilla »

9dev wrote: post #68
kortilla wrote: post #11

Earlier quoted context omitted.

I think you’re vastly overestimating the complexity of pointing a TLS library to a CA.

Do that for a bunch of different applications and you hit interesting issues. For example the Java TLS stack, which doesn’t accept a PEM certificate on its own, but needs the full certificate chain. Kibana, however, requires the full certificate chain including the root certificate, which isn’t usually a part of the certificate itself, and Elasticsearch complains about an invalid certificate if you point it to the sa…

I’ve done it. What you’re describing is like an hour of work. Moving TLS outside of the application is possibly the dumbest reason to spend the resources and complexity on a side car.

Re: Go-Safeweb

#77

Post by cyberpunk »

ongy wrote: post #45
cyberpunk wrote: post #18

Earlier quoted context omitted.

Why wouldn’t you use istio or cilium for this?

This might be me being daft, but I never quite understood the appeal of doing this with istio. OR also partially just due to the timing of when I started to care about things in k8s world. (Rather recently) My understanding of that model is that the services themselves still just do unauthenticated HTTP, this gets picked up on the client side by a sidecar, packed into mTLS/HTTPS, authed+unpacked on the server sidecar…

For us it’s compliance related first rather than any real security upgrade; we must use mtls between all services (finance) and it’s simply less to manage to use a service mesh.

The cloud provider could read the memory of a k8s node and in theory capture the session keys of two workloads on the same node, and we can’t really protect against that without something like confidential computing.

We get some other benefits for free by using istio though like nice logs, easily sending a chunk of traffic to a new release before rolling it everywhere, or doing fully transparent oauth even in services which don’t support it (oauth2proxy and istio looks at the jwts etc).

Re: Go-Safeweb

#78

Post by efilife »

EvanHahn wrote: post #66
ssahoo wrote: post #5

This is basically the helmet of go?

Helmet author here. This is a similar project, but not the same. Helmet covers HTTP response headers, and that's it. This project seems to have a wider scope, covering things like auth and error handling.

Your last comments were 10 months ago and 10 years ago. A rare occurence. HN at its finest
Post reply on HN