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/e8a7d974-7f6f-eeae-15d1-c4e82a2b3f83%40mb0.org.
