←back to thread

Go-Safeweb

(github.com)
188 points jcbhmr | 2 comments | 14 Nov 24 03:04 UTC | HN request time: 0.4s | source
Show context
pushupentry1219 ◴[14 Nov 24 04:54 UTC] No.42133267[source]▶
Not sure how I feel about the HTTPS/TLS related bits. These days anything I write in Go uses plain HTTP, and the TLS is done by a reverse proxy of some variety that does some other stuff with the traffic too including security headers, routing for different paths to different services, etc. I never run a go web application "bare", public facing, and manually supplying cert files.
replies(6): >>42133422 #>>42133588 #>>42133628 #>>42134049 #>>42134283 #>>42135953 #
bayindirh ◴[14 Nov 24 05:38 UTC] No.42133422[source]▶
While I understand the sentiment, this makes bare installations too hard.

A big project not handling HTTPS themselves (like docmost), adds tons of complexity on the server side. Now, I have to install that service as a container to isolate that, then need to add a reverse proxy on top, etc.

That leads to resource inflation when I just want to use a small VM for that single task. Now, instead I deploy a whole infrastructure to run that small thing.

replies(4): >>42133440 #>>42133543 #>>42133601 #>>42133665 #
NhanH ◴[14 Nov 24 05:45 UTC] No.42133440[source]▶
Handling https in the project also adds tons of complexity in the long run though: tls/ssl library versions, cert handling. Instead of having one way to deal with all of them (at the proxy layer, or sometimes at network layer), I have to deal with individual software way of managing those
replies(3): >>42133468 #>>42133705 #>>42133868 #
kortilla ◴[14 Nov 24 05:52 UTC] No.42133468[source]▶
I think you’re vastly overestimating the complexity of pointing a TLS library to a CA.
replies(3): >>42133821 #>>42133937 #>>42137845 #
1. 9dev ◴[14 Nov 24 16:30 UTC] No.42137845[source]▶
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 same one.

So even for two apps from the same vendor, which are commonly deployed together, you need bespoke TLS file variants. Scale that to more applications, and you’ll find out the hard way that you are vastly underestimating the complexity of operating a software ecosystem.

replies(1): >>42144272 #
2. kortilla ◴[15 Nov 24 05:53 UTC] No.42144272[source]▶
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.