Martin, all the information is helpful as I am provided with possible options. I am new to the SSL/TLS encryption process, so my question may not be clearly stated. Yes it is a private network but I want a secure network.and without the browser complaining that the certificate is invalid, The option that you prescribe is important should the IP address or DNS name of the server be changed. Based on the comments, certificates are the accepted security standard. I am still open to feedback.
On Thu, Jun 30, 2022 at 12:29 PM Robert Engels <reng...@ix.netcom.com> wrote: > One great aspect of the certificates is that they can be revoked - so > simply revoking a certificate will disable access across the board. > Certificates are also supported by HSM and the like. It can simplify and > secure the systems according to accepted security standards a bit more > straightforward in my opinion. > > Passwords are going away… > > > On Jun 30, 2022, at 11:55 AM, Martin Schnabel <m...@mb0.org> wrote: > > > > Sorry, i may have misunderstood the private network part, hope my > answer was helpful anyway. My usecase was a local area network without a > fixed ip or dns names, like common home network appliances. I thought about > using client certificates too, but decided it would be easier to use common > session cookie based password authentication over the tls connection. > > > > But now i am interested if i am missing something. What would be the > reason to use client certificates instead? > > > >> On 6/30/22 16:29, Hugh Myrie wrote: > >> 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 > <mailto: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 <mailto: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 > >> <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 > >> <mailto:golang-nuts%2bunsubscr...@googlegroups.com>. > >> > To view this discussion on the web visit > >> > https://groups.google.com/d/msgid/golang-nuts/20220630113506.ky4a25f6ovrciccf%40carbon > >> < > https://groups.google.com/d/msgid/golang-nuts/20220630113506.ky4a25f6ovrciccf%40carbon > >. > >> -- > >> http://www.jaxtr.com/blessed_hope <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 <mailto: > 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 > < > https://groups.google.com/d/msgid/golang-nuts/CAN-X3%3DZdOzLRe8AwUA-0QstS3aHvPafttLy4wk83e3enpZ-cBw%40mail.gmail.com?utm_medium=email&utm_source=footer > >. > -- 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%3DY8iHc%3DO6y4d1jdCSFbsJp7LxCbkaLpBnJPgMHQsqx4fg%40mail.gmail.com.
