Protect sensitive memory regions separately

[RyanGordon]

Summary

This is for a discussion around protecting sensitive portions of memory (i.e. handshake cache, master secret, private keys) instead of leaving it with the same regular Golang memory handling.

One such implementation could be to use something like memguard which utilizes kernel features to more carefully protect certain portions of memory.

Motivation

The motivation is to minimize existential risk of vulnerabilities in the application, Golang, or other lower level systems that could allow sensitive memory to be read given some set of vulnerabilities that allow for the situation to occur.

Describe alternatives you've considered

The primary alternative is to rely on Golang's tried and true memory functions and to audit and implement for best practices to ensure sensitive struct members are isolated and private, and sensitive memory is as short lived as possible

Additional context

We could consider introducing a dependency on https://godoc.org/github.com/awnumar/memguard, for creating a secure enclave where we store sensitive information. It's a little more extreme than just zeroing out a buffer but it goes to fairly great lengths to help you keep a memory area protected.

Originally posted by @daenney in #93

[daenney]

I've looked at memguard again recently, but it would be pretty invasive to use it as you end up constantly needing to interact with the memguard.Enclave. We'd have to abstract around that at the very least and be extremely careful to constantly use it correctly when dealing with any secret material.

I think I'm going to close this one for now. As it currently stands, Go's standard library doesn't do anything in particular on this front either. In most cases stdlib doesn't even bother with pointers-to-structs so there'll potentially be multiple copies of things like a TLS private key in memory when using cryto/tls etc. If the Go runtime could provide something like mmap'ing and locking an area of memory to store secrets in that would probably be a lot more feasible to support.