<div dir="ltr">Ward and I just had a conversation about how to implement SSL for Keep, knowing that Go's TLS support has had some problems in the past. I dug into the current state of the crypto/tls library for Go, and found this comment from Adam Langley, who maintains Google's SSL libraries:<div>
<span style="font-family:Arial,Helvetica,sans-serif;font-size:13px"><br></span></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">...crypto/tls does, of course, try to be useful.... the standard library doesn't try to be all things to all people. It quite deliberately aims to be simpler at the cost of only supporting the 90% case. If edge cases can be handled with local modifications then that does release the trunk from the burden of maintaining the code."</span> (<a href="https://groups.google.com/d/msg/golang-nuts/LjhVww0TQi4/M5TTs81XsocJ">https://groups.google.com/d/msg/golang-nuts/LjhVww0TQi4/M5TTs81XsocJ</a>)</div>
</blockquote><div><div><br></div><div>Because we expect the clients that talk directly to Keep to be relatively constrained -- i.e. we do not expect to have to support connections from random users' web browsers on old Windows machines or Mac OS 9 -- I think this isn't necessarily a dealbreaker for using Go's native crypto/tls support. As long as our own SDK can talk to Keep, we're still okay.  Any thoughts?</div>
</div><div><br></div></div>