Skip to Content.
Sympa Menu

discuss - Re: [opennic-discuss] broken https on reg.libre

discuss AT lists.opennicproject.org

Subject: Discuss mailing list

List archive

Re: [opennic-discuss] broken https on reg.libre


Chronological Thread  
  • From: Erich Eckner <opennic AT eckner.net>
  • To: discuss AT lists.opennicproject.org
  • Subject: Re: [opennic-discuss] broken https on reg.libre
  • Date: Fri, 22 May 2020 13:52:23 +0200 (CEST)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, 22 May 2020, Rouben wrote:

Hi,

Hi,

Since you bring up TOFU (Trust On First Use), I wanted to also chime in on
the whole TLS cert situation.

I think some things have changed since we last looked at it.

1. There are more ACME service (not just client) implementations available
than before. For example, Smallstep CA seems like an easier to manage
implementation that Let’s Encrypt’s
boulder: https://smallstep.com/certificates/

This sounds good.


2. As part of implementing a DNS change, we could ask our users to also
import our root certs.

Sounds reasonable. <dreaming> Maybe, someday we will enter the root-ca bundle of some major browser, though. </dreaming>


3. If we use ACME, we can set things up as follows (rough sketch, just off
the top of my head):

a) root cert - private key on a restricted machine or the CA operator’s
hardware token like a YubiKey. The public key/self-signed cert for this one
is published on opennic site and is what we ask our users to trust when they
deploy our DNS

b) intermediate - valid for 6 months, needs to be semi-automatically renewed
(resigned) by (a) - CA operator does this with their hardware token/Yubikey
on a secure, dedicated, offline machine.

c) client certs - valid for 1-3 months, requested and issued exclusively
through ACME protocol, signed by (b). Private key for (b) lives on ACME
server.

What are your thoughts?

This sounds good, too. The only downside, I can see, is that we create a single point-of-failure with the offline, dedicated root certificate. Is there some possibility to share that amongst more than one person securely?

Besides the obvious and insecure solution of sending the private key around, I only see having multiple such keys (I think 2 would really be sufficient) and require the users to import both of them.

regards, Erich

On Fri, May 22, 2020 at 06:01 Erich Eckner <opennic AT eckner.net> wrote:

Hi,

I know, that creating properly trusted ssl certificates for
opennic
domains is (currently) impossible. But I'd still like to urge
the operator
of reg.libre to add the reg.libre vhost backend also on https
(on any
certificate). Because, currently, one is forced to use
http://reg.libre,
because https://reg.libre brings up the content from a different
vhost
(after ignoring to the unavoidable certificate warning/error).

I think, using https with a broken certificate is still safer
than using
no https at all - it withstands passive eavesdropping, and also
one can
use tofu to pin the certificate after first use.

btw: This might be true for other sites within opennic's
namespace, so
maybe everyone running sites which handle secret data (e.g.
login
credentials) may want to check their config too :-)

cheers,
Erich

--------
You are a member of the OpenNIC Discuss list.
You may unsubscribe by emailing
discuss-unsubscribe AT lists.opennicproject.org

--
Rouben


-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl7HvPgACgkQCu7JB1Xa
e1q2Aw/9HBrKf9nMpAY91SIgoM3WZxw0JXYYDFrPp7mHk5eXb4TOVunC+qfXWr+D
ffGGELZj3uDgwVkoTjc8Cs2lzta3I2fBr4Flx3ppSafKoUBp8P8X0keZvrcBDO9N
goVxQiuvHVTy3o88MYPKJorbJ7BBqm8huJia8boURqZtQBVJaLXG476JbS5cW7q1
41/37Yin81HW60mMTjaX0urKlVSD+VlWauI5MsEjKQSd3GcHE+M6+c6VYBlvL8QF
84Cu6yCx5x41O1duVKDAk/woVELqXShpibMeMQunbxwRgypVHUuzyHKv40ImWWGY
xEuIuIRidW1Sq6Le4dUHfOYFEEDEgO2hdz17GIFqzAh22AntD615UQP7ZBAHfoZ2
Q86ylmw3fhXOlUkhQ9xMRdCtt/tRP6q3YlRTpXrvyeekKoPZpwlO7cU8RBrY4APm
lPuVLQtVjcFhRQJUuxJ4SaGKQz6Cgwom97YBApvReJFArGIRK2SnRhZQFKMd53qf
lVqCG7FCdscRYgP8B2yqkbzE28QBTAAZUQAnRChKlpa4wrfqLQID27RYstIrRh1d
3oJLz/tPp5FlaRD47AUMueKfcWWR5IzCip4UBaJt5anae0DsRHv9JtuQcBcbRE5n
czYWGzPBhuzWCykDxtcJ4xIh22tjSQd/zJe7TKFI4UUTQcbB0rQ=
=eUr7
-----END PGP SIGNATURE-----


Archive powered by MHonArc 2.6.19.

Top of Page