Re: [go-nuts] net/http TLS issue

[Brian Candler]

What key do you use to encrypt and decrypt the password in the config 
file?  Something hard-coded in the application?  That'll be easy to 
extract, e.g. by single-stepping the binary.

It's also worth mentioning: with many filesystems, when you overwrite a 
file, garbage blocks containing the old file (and hence the cleartext 
passphrase) remain on the system.  This will be true for pretty much any 
filesystem if you decide to do an atomic overwrite of the config file by 
writing out a new file, and then renaming it to replace the old file.  The 
directory entry is updated to point to the new file, but the blocks which 
contain the old file remain until they are re-used at some indeterminate 
time in the future.

-- 
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/9308764c-e19c-4888-926f-948956185ac0o%40googlegroups.com.

Re: [go-nuts] net/http TLS issue

[Rich]

Thanks for your reply. I think I have it down now. What I am going to do 
is: 
1. Read the key in to pemBlk
2. See if it's got a passcode
3. If it does decrypt
```
if x509.IsEncryptedPEMBlock(pemBlk) {
keyPEMBlock, err = x509.DecryptPEMBlock(pemBlk, []byte(passphrase))
```

As to having to have a human enter the passcode on each restart. I have a 
json configuration file that contains directives for where the keypair is 
an the passphrase. Read the passcode, try to decrypt it.  If the decrypt 
fails -- its probably in clear text so encrypt it and write it back to the 
config file. This way all the person has to do is put the passphrase in 
clear text, restart application, password is now encrypted in the config 
file. When the password changes because the key changed (once a year), 
change the config (plaintext) and restart -- passphrase is then encrypted. 
 
On Sunday, October 18, 2020 at 9:01:23 PM UTC-4 pat2...@gmail.com wrote:

> On Sunday, October 18, 2020 at 4:39:46 PM UTC-4 Rich wrote:
>
>> I have no problem writing this myself and I already have ideas on what I 
>> am going to do, but before I do that I thought I'd ask and see if anyone 
>> knew of a package, or some easier way that did this already. I've spent 
>> hours in the past writing code only to find later someone has written a 
>> great package that does what I need and more. Never hurts to ask right ;
>>
>
> The great packages have been written. But the real solution is to use a 
> service either in software like AWS Secrets Manager or in a hardware box 
> like the banking networks like.  If your company has had this policy a long 
> time, use whatever other systems have used. 
>
> Writing crypto software that seems to work is not hard. For this case, 
> have the operator enter a passphrase, run it thru a HMAC, and then use AES 
> 256 to encipher/decipher the CERT. Store the binary in some standard 
> format, try to avoid ANS.1 if you can possibly do it.
>
> Writing crypto software that really works, is secure, etc. is very hard. 
> No offense, but you are unlikely to do it.
>
> I don't understand how this is supposed to work. Do you ask the system's 
> operator to type in the passphrase every time the service is restarted? 
> Most modern systems don't have a human operator to do such typing. And how 
> do you ensure that there is no keyboard logger on the operator's terminal? 
> Or are you keeping the passphrase in someplace like an environment variable 
> or a secret file?
>
> The software and the crypto are only a tiny part of the issue. Either do 
> whatever made them happy in the past, or find out what is really driving 
> this "requirement".
>

-- 
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/a6279a0d-63e6-4c2d-8047-cd7c7905956dn%40googlegroups.com.

Re: [go-nuts] net/http TLS issue

[pat2...@gmail.com]

On Sunday, October 18, 2020 at 4:39:46 PM UTC-4 Rich wrote:

> I have no problem writing this myself and I already have ideas on what I 
> am going to do, but before I do that I thought I'd ask and see if anyone 
> knew of a package, or some easier way that did this already. I've spent 
> hours in the past writing code only to find later someone has written a 
> great package that does what I need and more. Never hurts to ask right ;
>

The great packages have been written. But the real solution is to use a 
service either in software like AWS Secrets Manager or in a hardware box 
like the banking networks like.  If your company has had this policy a long 
time, use whatever other systems have used. 

Writing crypto software that seems to work is not hard. For this case, have 
the operator enter a passphrase, run it thru a HMAC, and then use AES 256 
to encipher/decipher the CERT. Store the binary in some standard format, 
try to avoid ANS.1 if you can possibly do it.

Writing crypto software that really works, is secure, etc. is very hard. No 
offense, but you are unlikely to do it.

I don't understand how this is supposed to work. Do you ask the system's 
operator to type in the passphrase every time the service is restarted? 
Most modern systems don't have a human operator to do such typing. And how 
do you ensure that there is no keyboard logger on the operator's terminal? 
Or are you keeping the passphrase in someplace like an environment variable 
or a secret file?

The software and the crypto are only a tiny part of the issue. Either do 
whatever made them happy in the past, or find out what is really driving 
this "requirement".

-- 
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/0030732d-3fd2-487a-99dd-09395ee9f894n%40googlegroups.com.

Re: [go-nuts] net/http TLS issue

[Rich]

Thanks for your reply, however as I stated it's company policy to have a 
passphrase, even our java. keystores have a passcode. Using other services 
or methods, or just not having a passcode -- Just not the way they want it 
done. I am not a part of the security team that makes this stuff up and you 
might as well try to get water to flow up hill to change policies. It is 
what it is, I gotta deal with it. 

I have no problem writing this myself and I already have ideas on what I am 
going to do, but before I do that I thought I'd ask and see if anyone knew 
of a package, or some easier way that did this already. I've spent hours in 
the past writing code only to find later someone has written a great 
package that does what I need and more. Never hurts to ask right ;)


On Friday, October 16, 2020 at 6:33:14 PM UTC-4 mar...@gmail.com wrote:

> Having a passcode to protect a key file for a production service is 
> pointless, because you move the problem of storing the certificate securely 
> to the problem of storing the passcode securely, so might as well skip the 
> passcode and store the cert securely.
>
> Your certificate is probably encoded as a PEM cert, so you'd have to 
> manually call https://golang.org/pkg/crypto/x509/#DecryptPEMBlock and 
> provide a password, then construct your listener yourself using the 
> unmarshaled certificate. So, how are you going to protect this passcode? Is 
> someone going to have to provide it every time you start?
>
> Generally, in production systems, we use some kind of secret manager to 
> store that certificate, such as AWS Secrets Manager or encrypt it with KMS, 
> store it in Vault, etc. Ideally, you actually make a subordinate cert for 
> that service and rotate it at a reasonable interval.
>
> On Fri, Oct 16, 2020 at 2:06 PM Rich  wrote:
>
>> I don't know if we're the only company on the planet that demands the 
>> https keys have a passcode to them but I've been having a heck of a time 
>> trying to find a good way to serve https using a key with a passphrase.  
>>
>> err := ListenAndServeTLS(addr, certFile, keyFile string 
>> , handler Handler 
>> )  
>>
>> If they keyFile has a passcode this doesn't work and the examples I've 
>> seen take this one line and turn it into a much longer chunk of code.
>>
>> -- 
>> 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/c75fc8f6-abe4-4614-8281-cef4cb315ac3n%40googlegroups.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/732f64f7-d4ae-49f3-be69-58a816005097n%40googlegroups.com.

Re: [go-nuts] net/http TLS issue

[Marcin Romaszewicz]

Having a passcode to protect a key file for a production service is
pointless, because you move the problem of storing the certificate securely
to the problem of storing the passcode securely, so might as well skip the
passcode and store the cert securely.

Your certificate is probably encoded as a PEM cert, so you'd have to
manually call https://golang.org/pkg/crypto/x509/#DecryptPEMBlock and
provide a password, then construct your listener yourself using the
unmarshaled certificate. So, how are you going to protect this passcode? Is
someone going to have to provide it every time you start?

Generally, in production systems, we use some kind of secret manager to
store that certificate, such as AWS Secrets Manager or encrypt it with KMS,
store it in Vault, etc. Ideally, you actually make a subordinate cert for
that service and rotate it at a reasonable interval.

On Fri, Oct 16, 2020 at 2:06 PM Rich  wrote:

> I don't know if we're the only company on the planet that demands the
> https keys have a passcode to them but I've been having a heck of a time
> trying to find a good way to serve https using a key with a passphrase.
>
> err := ListenAndServeTLS(addr, certFile, keyFile string
> , handler Handler
> )
>
> If they keyFile has a passcode this doesn't work and the examples I've
> seen take this one line and turn it into a much longer chunk of code.
>
> --
> 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/c75fc8f6-abe4-4614-8281-cef4cb315ac3n%40googlegroups.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/CA%2Bv29LtOt-JXdpfvTFMhLMFS729PR0ASe_4xMsQzEkvDN%2BigjA%40mail.gmail.com.

[go-nuts] net/http TLS issue

[Rich]

I don't know if we're the only company on the planet that demands the https 
keys have a passcode to them but I've been having a heck of a time trying 
to find a good way to serve https using a key with a passphrase.  

err := ListenAndServeTLS(addr, certFile, keyFile string 
, handler Handler 
)  

If they keyFile has a passcode this doesn't work and the examples I've seen 
take this one line and turn it into a much longer chunk of code.

-- 
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/c75fc8f6-abe4-4614-8281-cef4cb315ac3n%40googlegroups.com.