Yeah. I have a proof of concept complete. It's a bit more than 3 lines.
It's just under 100 lines. Error handling, etc.
1. This needs to be something devs can use without a lot of effort or they
just push back and use file-based HTTPS servers.
2. This needs to have no loss of functionality. Otherwise, adoption will
be slow at best.
On Friday, October 8, 2021 at 9:21:33 AM UTC-5 seank...@gmail.com wrote:
> It's only 3 lines excluding error handling if you just want to use a
> static string.
> And you'll likely want to setting up your own http.Server anyway to have
> control over timeouts (and also your own mux to prevent leaking debug
> handlers).
>
> In practice you may actually want o use crypt/tls.Config.GetCertificate
> instead, to allow your server to update certs from your secret store
> without a restart.
>
> On Friday, October 8, 2021 at 3:52:29 PM UTC+2 Sam Caldwell wrote:
>
>> Sorry for the delayed response. I needed to noodle on this option and
>> talk to some of the devs who would need to implement this.
>>
>> 1. Setting up an http.Server{} and tls.Config will work. But it is a lot
>> of effort for devs who want to focus on the business logic.
>> 2. This creates more code the golang users (devs) need to implement and
>> maintain...which disincentivizes a non-file-based approach.
>>
>> I've created my own library to do what is suggested in this thread, but
>> I'd say that as a community we should pursue a better option.
>> On Monday, September 13, 2021 at 4:14:01 PM UTC-5 bse...@computer.org
>> wrote:
>>
>>> On Mon, Sep 13, 2021 at 3:03 PM Sam Caldwell <ma...@samcaldwell.net>
>>> wrote:
>>>
>>>> Does anyone have any ideas of an easy path to load certificate and key
>>>> files from a string rather than a file?
>>>>
>>>> *Use Case:*
>>>> 1. traditionally we all put a cleartext file on disk with our private
>>>> key and public certificate. If the server is breached, we just regenerate
>>>> all the things and move on.
>>>> 2. I would like to store my certificates and keys in a more secure
>>>> location (AWS SSM Param store, Hashicorp Vault, etc.).
>>>> 3. The certificate is only read from file at startup as best I can
>>>> tell, and relocating certificates and keys to an encrypted store would (a)
>>>> allow better auditing when the content is accessed, (b) restrict access to
>>>> only authorized processes and (c) make rotating keys and certificates a
>>>> much easier process.
>>>>
>>>> *Analysis:*
>>>> *Current Functionality:*
>>>> - We setup a server using ListenAndServeTLS() and pass in a filename
>>>> for the certificate and key.
>>>> - In go1.17.1/src/net/http/server.go at 3066, tls.LoadX509KeyPair()
>>>> loads is called.
>>>> - LoadX509KeyPair() exists at 230 in src/crypto/tls/tls.go and
>>>> - It calls os.ReadFile() at 231 and 235.
>>>> *Possible Solution:*
>>>> - We cannot break existing things, and within the limitations of
>>>> golang, it is probably the least-disruptive solution to add a new
>>>> ListenAndServeTLSFromVar() which would functionally do everything
>>>> ListenAndServeTLS() does, but instead of reading a file, it would instead
>>>> accept the input string as the certificate/key content.
>>>> - Alternatively ListenAndServeTLSFromVar() would accept a boolean
>>>> parameter which would determine if certificate and key parameters are
>>>> filenames or content strings. in this case, ListenAndServeTLSFromVar()
>>>> would support both filenames and content string use cases and provide a
>>>> path to unifying the approach if the community begins to adopt the use
>>>> case
>>>> identified above in large numbers.
>>>>
>>>
>>> You can already do this by creating an http.Server{} with a tls.Config
>>> initialized from the certificates you have. You have to decode and parse
>>> the certificates from strings to create the tls.Config.
>>>
>>>
>>>
>>>>
>>>> *Conclusion:*
>>>> I'm willing to do the work and contribute the code to implement the
>>>> above, but I wanted to solicit opinions first. Ideally the functionality
>>>> exists already and I am reinventing a wheel. In that case, please point
>>>> me
>>>> in the right direction so I can focus my efforts on my current project.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "golang-nuts" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to golang-nuts...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/golang-nuts/6e283ce3-7802-4765-9fd3-156d01c65bbbn%40googlegroups.com
>>>>
>>>> <https://groups.google.com/d/msgid/golang-nuts/6e283ce3-7802-4765-9fd3-156d01c65bbbn%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/7e705e2b-27de-4fa8-85c5-ef3f5476d35dn%40googlegroups.com.
