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>. -- 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/C0B93337-A4C4-43B5-9DFE-3467D4F67CF4%40ix.netcom.com.
