On Mon, Jun 27, 2022 at 05:35:38PM -0700, Hugh Myrie wrote:
> I wish to create a secure private network using a self-signed certificate
> with a Go web server: See the following code block:
>
> // Code
> err := http.ListenAndServeTLS(":"+port, "auto.org.pem",
> "auto.org-key.pem", handler)
> if err != nil {
>
> logError((err.Error()))
> log.Fatal("ListenAndServe: ", err)
> }
> // End of Code
>
> Could I auto generate (and register) the .pem and .key files using GO? I
> wish to create a trust certificate if there files do not exist.
>
> I came across the following website:
>
> "https://gist.github.com/shaneutt/5e1995295cff6721c89a71d13a71c251";
>
> I am not sure how to implement this. Your help is appreciated.
I'm afraid there may be a critical flaw in your approach as a concept.
I'll try to explain how I perceive it. I might be wrong in my assessment, and
if yes, please excuse me - I'm just trying to help.
OK, so, TLS has two conceptual facets in the way it implements secure data
exchange tunnels: encryption (information hiding) and mutual authentication.
Based on my experience, people tend to ignore the second one while fixating on
the former. Maybe this comes from the extensive usage of web browsers, in
which using of certificates for authentication most of the time is strictly
one-way - most websites to not require their clients to authenticate on the
TLS level, and authenticating of the websites is well hidden under the hood.
Now consider implementing a custom "secure private network" with the help of
TLS. Say, your server accepts TLS sessions from its clients, and uses
a self-signed certificate and the matching key. Now, have you thought out how
this server will make sure that a client wanting to connect to actually has
the permission to do that? Conversely, how the client knows the server is
legitimate and was not spoofed using a Man-in-the-Middle attack?
To authenticate clients, you might implement some non-TLS method - such as
passwords. This would work, but when architecting a secure communication
system you should apply "security mindset" when thinking: if the client has
set up a TLS session with a rogue server, any information the client sends to
that session must be considered as compromised, and any imformation received
must not be trusted (unless there's a way to reliably verify it). This inclues
the password exchange. You could implement a secure password exchange scheme
which does not result in disclosing the password (only proves its knowledge)
but the rogue server can just tell the client it authenticated OK, and then
start accepting actual data from the client. You could implement the reverse
scheme to also authenticate the server to the client, and this would require
keeping the server's password on each client.
OK, so TLS is already able to authenticate both sides to each other - using
certificates. There are two ways do do it. The "normal" one is to trust a
certificate presented during a TLS handshake exchange by trusting whoever had
issued that certificate (and hence signed it). The "punk" way is to check the
so-called fingerprint - a cryptographic hash calculated on the certificate's
data - to match whatever stored at the authenticating side.
Add to the picture that the server usually wants to have a way to prevent
certain clients - which would otherwise be properly authenticated - from
accessing the server - usually because they have been compromised somehow
(consider a stolen laptop which contains the cert+key used to access the
server). Again, TLS has a way to support this - through the so-called
certificate revocation list, CRL, which can list otherwise valid certificates
which must be considered not eligible for use - "revoked".
So, what I'm leading to, is basically these two things:
- Proper framework for mutual authentication of the server(s) and the clients
forming a secure network requires careful planning and implementing.
An often overlooked aspect of it is managing keys used for authentication.
- TLS already implements support for both mutual authentication during session
initiation phase, and for implementing the key management framework.
Not using these features should require careful consideration: security is
notoriously hard to get right, and one has to think twice before forfeiting
tried-and-tested solutions. Autogenerating a self-signed certificate and
sticking it into a library call which starts a HTTPS server looks like merely
looking for TLS-encryption without considering authentication.
OK, so, should you decide to acually rely on TLS to do proper authentication,
you will need to read up on how authentication based on X.509 certificates
actually works, what certification authoriries (CAs) are, and how certificates
are to be issued and maintained and revoked.
Note that it's not required to maintain a full-blown certification authority
(CA) to generate certificates and keys for the servers and the clients.
You _will_ need a CA, but "low-tech" solutions to do that do exist - such as a
set of scripts shipped in the form of a package named "easy-rsa" for Debian
and its derivatives (such as Ubuntu).
--
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/20220630113506.ky4a25f6ovrciccf%40carbon.
