The easy guide to securing HTTP + TLS with Go

This is a creation in Article, where the information may have evolved or changed.

The Go programming language makes it easy-to-write and deploy servers offering HTTPS (HTTP + Transport Layer Security) to Clients. The crypto package in Go's standard library are easy-to-use and well Documented:it's an under-explored gem. Due to it's low-on-legacy implementation of modern standards and easy configurability, there are no reason to insert Apa Che or Nginx server to terminate TLS connections. A Go Application Server can do it all including being the front-end. All without openssl!

Within the Go Standard Library, the HTTP package provides the ListenAndServeTLS() API, this offers secure HTTP to clients. Once a server is functionally working, how does one check HTTPS configuration and security? Here are a practical guide:

1. Pick an audit tool to test your HTTP+TLS server
2. Understand any failures
3. Fix the issues
4. (Rinse and Repeat)

PICK an audit tool

Let's start with the right tool. In this article, we use the scanner at Qualys SSL Labs. It's recommended by Adam Langley, security maven and key author of Go's "crypto" codebase.

RUN the tool

• Be prepared-failing grades, like the "C" below
• Pay attention to the security warnings shown in color-coded message boxes. Work to fix them next.

FIX the security issues

The first significant misconfiguration reported by the above scan is the possibility of a POODLE attack. While Go doesn ' t support the older SSLV3 @ all, you can still make the server does a smarter TLS handshake by explicitly co Nfiguring it to only advertise support of VTLS 1.0 or higher. This is do by setting tls.Config.MinVersion :

// Make a server negotiate only TLS v1.0+ with clientsconfig := &tls.Config{MinVersion: tls.VersionTLS10}s := &http.Server{TLSConfig: config}s.ListenAndServeTLS()

Next up is the yellow-coded warning on use of a weak cipher:rc4. This error is limiting ciphers to a stronger set via tls.Config.CipherSuites . Also Notice the use of this PreferServerCipherSuites forces the TLS negotiation to pick a result from the (presumably) stronger list of serve R-specified ciphers.

// Work for iOS 6+, WP 8.x, and Android 4.4.2+config := &tls.Config{MinVersion:               tls.VersionTLS12,PreferServerCipherSuites: true,CipherSuites: []uint16{tls.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,tls.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,tls.TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,tls.TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,tls.TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,tls.TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,....},}

For a comprehensive understanding of the warnings flagged by the tool, check out Mozilla's Guide to TLS and cipher suites.

Rejoice at your passing grade!

Once you has the fixed the issues flagged by the tool, a All-green report card awaits.

A Word of Caution:before changing Go ' s defaults, do-read the standard library documentation for TLS, and Mozilla's Guide To TLS and cipher suites. Additional factors to consider while tuning the HTTPS server is:

• Network round-trips required to negotiate a TLS connection
• Encryption quality and cpu/battery cost trade-off
• Legal implications if applicable.

Happy security!

(Thistopic were presented by the author at a lightening talk "Excuse me, your Crypto is showing!" during Gophercon Ind IA 2015. The shooting gopher image is attributed to creator Wisi Mongkhonsrisawat via the Gorequest Project.)