←back to thread

Go-Safeweb

(github.com)
188 points jcbhmr | 3 comments | | HN request time: 0s | source
Show context
pushupentry1219 ◴[] 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 ◴[] 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 ◴[] 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 ◴[] 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. thayne ◴[] No.42133821[source]
For a single application, it's not too bad. When you have dozens of applications that all have different mechanisms to install a CA, rotate certs, etc. And some of those don't have a good way to automate rotating the certs, then it becomes a pain.
replies(1): >>42134313 #
2. bayindirh ◴[] No.42134313[source]
I don't think so. We run a horde of machines, and run plethora of services, which are custom and/or has a very narrow install base due to the niche they serve.

99% of them use system-wide PKI store for CA and their certificates, which is under /etc. All of them have configuration options for these folders, and have short certificate lives because of the operational regulations we have in place.

At worst case, we distribute them with saltstack. Otherwise we just use scp, maybe a small wrapper script. Managing them doesn't take any measurable time for us.

...and we have our own CA on top of it.

replies(1): >>42138041 #
3. thayne ◴[] No.42138041[source]
> 99% of them use system-wide PKI store for CA and their certificates, which is under /etc.

Consider yourself lucky then.

For self-hosted third party software, I've seen requirements to provide it in an environment variable, upload it to a web form over plain http on localhost, specify an AWS secret service secret that contains it, put it in a specific location that is bind mounted into a container, create a custom image (both VM and container), etc.