ListenAndServeTLS() (pem and key files for private network)

[Hugh Myrie]

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.

[Peter Galbavy]

If it helps, I put this together for my own project - it's not a package but a bunch of convenience functions/methods for generating TLS certs and keys (there is a lot of implementation specific stuff), but the general shape may help you:

https://github.com/itrs-group/cordial/blob/main/tools/geneos/internal/instance/tls.go

Peter

[Martin Schnabel]

hi hugh,

i played around with the same idea six years ago, resulting in
https://github.com/mb0/localca

it will use a self signed root cerificate and creates new child
certificates specific to the requested hostname, be it an ip or a name
like my_local.box

i haven't tested it for awhile, but the idea does apply.

have fun

> --
> 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...@googlegroups.com
> <mailto:golang-nuts...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/6ce2a407-600d-44b7-97d1-53e90e91e7c8n%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/6ce2a407-600d-44b7-97d1-53e90e91e7c8n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Martin Schnabel]

the package only helps to setup a special tls listener to be used with
the http server, as shown in the example. the http handler code and
routing is not affected in any way and is completely independent.

the special listener uses a ca cert to generate new server certs every
time you reach under a new name. client only need to trust the ca cert
at one time. if they connect to the server the listener returns the
existing server cert or creates a new cert (with the self signed ca
cert) that includes the name or ip it was called with.

hope that helps

On 6/28/22 16:03, Hugh Myrie wrote:
> Hi Martin,
>
> How does localca handle CORS?
>
> Originally I defined an handler and pass it as a parameter to
> ListenAndServeTLS
>
> c := cors.New(cors.Options{
>         AllowedOrigins:   []string{"*"},
>         AllowedMethods:   []string{"GET", "PUT", "POST", "DELETE"},
>         AllowedHeaders:   []string{"*"},
>         AllowCredentials: true,
>     })
> handler := c.Handler(r)
>
> On Tue, Jun 28, 2022 at 7:03 AM Hugh Myrie <hugh....@gmail.com
> <mailto:hugh....@gmail.com>> wrote:
>
> Thanks Martin for your help.

>
> On Tue, Jun 28, 2022, 06:26 Martin Schnabel <m...@mb0.org
> <mailto:m...@mb0.org>> wrote:
>
> hi hugh,
>
> i played around with the same idea six years ago, resulting in

> https://github.com/mb0/localca <https://github.com/mb0/localca>

> <mailto:golang-nuts%2Bunsu...@googlegroups.com>
> > <mailto:golang-nuts...@googlegroups.com
> <mailto:golang-nuts%2Bunsu...@googlegroups.com>>.

> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/golang-nuts/6ce2a407-600d-44b7-97d1-53e90e91e7c8n%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/6ce2a407-600d-44b7-97d1-53e90e91e7c8n%40googlegroups.com>
>
> >

> <https://groups.google.com/d/msgid/golang-nuts/6ce2a407-600d-44b7-97d1-53e90e91e7c8n%40googlegroups.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/golang-nuts/6ce2a407-600d-44b7-97d1-53e90e91e7c8n%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>
> --
> You received this message because you are subscribed to a topic
> in the Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/0XKZ3AkAA9w/unsubscribe
> <https://groups.google.com/d/topic/golang-nuts/0XKZ3AkAA9w/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email
> to golang-nuts...@googlegroups.com
> <mailto:golang-nuts%2Bunsu...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/golang-nuts/63b7a250-5afc-6171-6526-00796498ea36%40mb0.org
> <https://groups.google.com/d/msgid/golang-nuts/63b7a250-5afc-6171-6526-00796498ea36%40mb0.org>.
>
>
>
> --
> http://www.jaxtr.com/blessed_hope <http://www.jaxtr.com/blessed_hope>

[Konstantin Khomoutov]

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).

[Robert Engels]

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:

> --
> 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...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20220630113506.ky4a25f6ovrciccf%40carbon.

[Hugh Myrie]

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.

--

http://www.jaxtr.com/blessed_hope

[Robert Engels]

Just Google ssh certificate authentication and you’ll find a lot of resources. 

On Jun 30, 2022, at 9:29 AM, Hugh Myrie <hugh....@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAN-X3%3DZdOzLRe8AwUA-0QstS3aHvPafttLy4wk83e3enpZ-cBw%40mail.gmail.com.

[Martin Schnabel]

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 <ren...@ix.netcom.com
> <mailto:ren...@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

> <mailto:golang-nuts%2Bunsu...@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...@googlegroups.com

> <mailto:golang-nuts...@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>.

[Robert Engels]

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.

[Hugh Myrie]

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.

--

http://www.jaxtr.com/blessed_hope

[Sean Liao]

> using a self-signed certificate

> without the browser complaining that the certificate is invalid

By default, browsers trust certificates signed by Certificate Authorities (CA) in the system cert store. CAs can get added if they pass certain requirements. Typically they will only sign certificates after you've demonstrated control over a domain name, either with a public HTTP or TLS server or with DNS records. Running in a private network, you could use the DNS option, but all certs issued this way will be logged publicly via Certificate Transparency.

If you have some control over the end (clients) systems, you could instead add your own CAs to the system cert store. This will allow you to sign certificates for any address (domain or IP), at the cost of needing to distribute the CA certificates to all your systems.

ACME is the standard protocol to automate signing certificates by demonstrating control, if you run your own compatible CA in within your private network, you can do this without leaking information to the public.

Unless you wish to distribute each self signed certificate to every client, by definition they cannot be trusted by default. 

- sean