[go-nuts] Shell tab-completion

['Valentin Deleplace' via golang-nuts]

Hello, is there a recommended way to achieve command line completion of the 
go command with Bash and Zsh?
E.g.
go te  ->  go test
go bui -> go build

I don't have that out-of-the-box, and the install page 
 doesn't mention it.
I've seen a couple of 3rd party github repos for this, that have not been 
updated recently. Maybe one of them is good, I just haven't tried them yet!

Thanks

-- 
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/e6d5b220-88ff-4b54-a5bd-f74c141077a7n%40googlegroups.com.

Re: [go-nuts] Shell tab-completion

[Steve Mynott]

On Thu, 30 Jun 2022 at 11:07, 'Valentin Deleplace' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Hello, is there a recommended way to achieve command line completion of
> the go command with Bash and Zsh?
> E.g.
> go te  ->  go test
> go bui -> go build
>
> I don't have that out-of-the-box, and the install page
>  doesn't mention it.
> I've seen a couple of 3rd party github repos for this, that have not been
> updated recently. Maybe one of them is good, I just haven't tried them yet!
>

I'm using and can recommend

https://github.com/zsh-users/zsh-completions

which seems actively maintained.

-- 
Steve Mynott 
rsa3072/629FBB91565E591955B5876A79CEFAA4450EBD50

-- 
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/CANuZA8S-pefac-DNS0RcCLw9fhu36ENiqGCXRHukOKuUpFXJ3w%40mail.gmail.com.

Re: [go-nuts] ListenAndServeTLS() (pem and key files for private network)

[Konstantin Khomoutov]

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 

Re: [go-nuts] ListenAndServeTLS() (pem and key files for private network)

[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  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 i

Re: [go-nuts] ListenAndServeTLS() (pem and key files for private network)

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

On Thu, Jun 30, 2022 at 7:22 AM Robert Engels  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 
> 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 

Re: [go-nuts] ListenAndServeTLS() (pem and key files for private network)

[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  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  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  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 

Re: [go-nuts] ListenAndServeTLS() (pem and key files for private network)

[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 > 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: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

Re: [go-nuts] ListenAndServeTLS() (pem and key files for private network)

[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  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 > > 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: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 actu

Re: [go-nuts] ListenAndServeTLS() (pem and key files for private network)

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

On Thu, Jun 30, 2022 at 12:29 PM Robert Engels 
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  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  > 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: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 archi

Re: [go-nuts] ListenAndServeTLS() (pem and key files for private network)

['Sean Liao' via golang-nuts]

> 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

-- 
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/CAGabyPq3y5VTKx7dg8sUd-wEJpVTi7HZHyJ0ofG3X1JEGLWWVQ%40mail.gmail.com.

[go-nuts] Re: How do you make a ReadCloser?

['Ansuraj Khadanga' via golang-nuts]

Thats great! Thanks for sharing.

req.Body = ioutil.NopCloser(bytes.NewReader([]byte("foo")))

works!

On Wednesday, 27 June 2018 at 22:21:52 UTC+5:30 keens...@gmail.com wrote:

> This worked perfectly, thanks!
>
>
> On Tuesday, December 1, 2015 at 5:29:27 AM UTC-8, Borja Berastegui wrote:
>>
>> req.Body = ioutil.NopCloser(bytes.NewReader([]byte("foo")))
>>
>>

-- 
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/8e4dce0a-e6e9-4586-9ac6-5953be828711n%40googlegroups.com.