setting up a hardened https server in go 1.13

[DrGo]

https://blog.gopheracademy.com/advent-2016/exposing-go-on-the-internet/

I found this article very helpful in setting up a hardened https server. But It dates back to 2016 and go 1.8. Are there more up-to-date recommendations for go 1.13?

Thanks,

[Kevin Chadwick]

On 2020-02-21 01:42, DrGo wrote:
> Are there more up-to-date recommendations for go 1.13?

Personally I run Go behind either app engine or via fcgi behind OpenBSD httpd.
I'm not sure any other https server has the same level of key protection as
revamped in OpenBSDs httpd (separate to LibreSSL), since heartbleed (despite not
being as vulnerable as most).

[Amnon Baron Cohen]

Interesting.

What vulnerabilities does OpenBSDs httpd protect against, which a properly hardened net/http does not?

The problem with proxying through OpenBSD's server, nginx or any other server is that there is another 
moving part that you need to master, configure, monitor, and which may have its own vulnerabilities.

Filippo, who wrote the blog, is now on the core go team, and working on Go Crypto and getting
hardened behaviour by default. See https://blog.filippo.io/hi/ and 
https://go.googlesource.com/proposal/+/master/design/cryptography-principles.md
This would be welcome, as hardening net/http requires a couple of dozen lines of boilerplate code.

As you say, his blog post is four years old, and four years is a long time in crypto land,
it would be great if we got some updated recommendation from Filippo.
The default behavior has been improved. SSLv3 for instance will be removed when 
Go 1.14 comes out (in a few days time). Perhaps we could coax Filippo to write 
a Go blog with his updated best practices?

[Kevin Chadwick]

On 2020-02-21 16:13, Amnon Baron Cohen wrote:
> Interesting.
>
> What vulnerabilities does OpenBSDs httpd protect against, which a properly
> hardened net/http does not?
>

Default connection limits suggest it isn't production ready by default and so is
the main reason...so define properly hardened, but also.

https://marc.info/?l=openbsd-cvs&m=139879883203226&w=2
http://insanecoding.blogspot.com/2014/05/protecting-private-keys.html

> The problem with proxying through OpenBSD's server, nginx or any other server is
> that there is another 
> moving part that you need to master, configure, monitor,

httpd.conf is very simple.

> and which may have its own vulnerabilities.

There will be some truth to this, however I guess it is swapping out memory safe
go code for code running as multiple processes as different users, rather than
strictly increasing attack surface. In fact the pledge/simplicity etc. on the
fcgi interface may garner some protections. I haven't considered it much at all
though really, due to first point.

So I guess against a properly hardened is debateable for exploit but the
severity of exploit may be less likely, currently.

[Amnon Baron Cohen]

On Friday, 21 February 2020 17:49:06 UTC, Kevin Chadwick wrote:

On 2020-02-21 16:13, Amnon Baron Cohen wrote:
>
Default connection limits suggest it isn't production ready by default and so is
the main reason...so define properly hardened, but also.

hardened means following the recommendations of Filippo's blog post 
(which in practice adds about 30 lines to your code).

But without a list of vulnerabilities, this sounds to me like FUD.

[DrGo]

On 2020-02-21 16:13, Amnon Baron Cohen wrote:
>
Default connection limits suggest it isn't production ready by default and so is
the main reason...so define properly hardened, but also.

For an average schmuck like me, "hardened" means that I am not criminally neglecting an easy fix to a known vulnerability in the tools I am using (luckily I am not in charge of developing the 2020 voting apps). Ideally, net/http exports a function that hides the gory details that Filippo's article recommends. Another option is a set of clear up-to-date recommendations by the relevant Go Team.

Thanks,

[Kevin Chadwick]

>But without a list of vulnerabilities, this sounds to me like FUD.

Fud implies intentional deceit, not the case.

Now that you have made me think about it then if security is your priority over performance then OpenHttpd certainly provides better protection of the TLS key and various server functions and leverages better OS protection at the cost of a vulnerability putting the OS at greater risk but an exploit in net/http would more likely give almost immediate ownership of the whole server but less likely the OS.

Re-acting to vulnerabilities isn't security, avoiding their affect is. Using golang especially where great care cannot be afforded is one such way.

Personally I wish net/http used more than one user and processes but it is still fantastic.