Just Google ssh certificate authentication and you’ll find a lot of resources.
> On Jun 30, 2022, at 9:29 AM, Hugh Myrie <hugh.my...@gmail.com> 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> 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.
--
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/B32C4B8D-001B-4545-AFAE-5191F18F96FC%40ix.netcom.com.
