I don’t think it needs to be that complicated just load the client public certs
into the server. Validate upon usage that the cert is still valid. Easy to
authenticate clients this way. This is how ssh works with certificate based
authentication. Peer to peer is a little harder but usually you get the valid
certs from a trusted server.
> On Jun 30, 2022, at 6:35 AM, Konstantin Khomoutov <kos...@bswap.ru> wrote:
>
> 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.
--
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/B2F074ED-C063-4576-93B3-F2E75152160E%40ix.netcom.com.
