The easy guide to securing HTTP + TLS with Go

Reading time ~2 minutes

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 is 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 is no reason to insert an Apache 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 that offers secure HTTP to clients. Once a server is functionally working, how does one check HTTPS configuration and security? Here is 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 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 for 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 at all, you can still make the server do a smarter TLS handshake by explicitly configuring it to only advertise support of vTLS 1.0 or higher. This is done by setting tls.Config.MinVersion:

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

Next up is the yellow-coded warning about use of a weak cipher: RC4. You may fix this error by limiting ciphers to a stronger set via tls.Config.CipherSuites. Also notice the use of PreferServerCipherSuites that forces the TLS negotiation to pick a result from the (presumably) stronger list of server-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 have fixed the issues flagged by the tool, an 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 are:

  • network round-trips required to negotiate a TLS connection
  • encryption quality and CPU/battery cost trade-off
  • legal implications if applicable.

Happy security!

(This topic was presented by the author at a lightening talk “Excuse me, your Crypto is showing!” during GopherCon India 2015. The shooting gopher image is attributed to creator Wisi Mongkhonsrisawat via the GoRequest project.)

The subtle art of listening. OR, if you build it will they come?

*[Maheima Kapur is an advisor to the Fastah Project, she helps the team [make software that people want](http://blog.samaltman.com/startu...… Continue reading

GopherCon and NASSCOM Startup Warehouse

Published on September 10, 2014