Your help is much appreciated. Security is of paramount importance so I
must take everything into consideration. I am learning so feel free to
provide useful feedback.
On Thu, Jun 30, 2022 at 7:22 AM Robert Engels <reng...@ix.netcom.com> wrote:
> 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
> .
>
--
http://www.jaxtr.com/blessed_hope
--
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/CAN-X3%3DZdOzLRe8AwUA-0QstS3aHvPafttLy4wk83e3enpZ-cBw%40mail.gmail.com.
