Reading up a bit more it looks like Go implemented its own SSL library. So I guess this is what Caddy uses? Would it be possible to link Caddy with GnuTLS or OpenSSL instead?
Cryptography is notoriously easy to botch in subtle and surprising ways and I’m only human. I don’t feel that I can warrant that Go’s TLS code is flawless and I wouldn’t want to misrepresent it.
One of Go’s big things is that its binaries are fully statically compiled. It’s not possible to dynamically link alternate implementations to Caddy because we chose to use the advantages gained by statically compiling.
Is there some peer reviews or audits made to assert this? TLS and crypto implementations are very difficult to get right, so I think it is prudent to ask these questions.
@Forza, Go’s TLS stack is widely accepted to be one of the best and most robust implementations in the world.
No, we absolutely will not be allowing Caddy to link to C code, especially for its TLS stack. Remember Heartbleed? That entire class of vulnerabilities is impossible with Go.
Go’s cryptography code was written by some of the most experienced cryptographers in the field. No code is perfect, but any weaknesses or bugs tend to be found and fixed quickly. If you have doubts about it you should raise an issue on the Go tracker.
I would 100% trust Go’s memory-safe implementation of TLS over an old C program any day. Especially with authors like Adam Langley and Filippo Valsorda, and with 10+ years of production experience on some of the busiest edge servers on the Internet (Google, Cloudflare, Netflix, etc).
Have you tried doing a search or asking the Go project themselves? I think you’re on the wrong forum for that question, honestly.
I did searches I found the quote from Adam which I posted in the first post. I also found (mostly old) references that Go TLS is vulnerable to side channel attacks.
But you’re right. Those questions are best for a Go forum, and you already confirmed that Caddy is indeed using Go TLS.
Caddy is proudly written in Go, and its TLS stack is powered by the robust crypto/tls package in the Go standard library, trusted by the world’s largest content distributors.
I don’t doubt that Caddy is secure. I had just found very little on the net about it. A CVE search yielded very few results, but then this is probably is a good thing
I must admit that the defaults seems very sane when I look at the results from Qualys SSL test.
you can easily cross compile to any target from any build machine.
deployment is dead simple – zero dependencies. Docker is not needed.
you are not vulnerable to security issues in the host systems SSL/TLS libs. What you deploy is pretty much what you get.
although there is high quality code written in C/C++, it is much easier to write safe, reliable programs in Go, so I think long term there is much less risk using a Go implementation of about anything – especially if it is widely used.
Go’s network programming model is much simpler than about anything else. Simplicity == less bugs.
Once you link to C libs in your Go program, you forgo many of the benefits of Go.
