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: Rouben <rouben AT rouben.net>
  • To: discuss AT lists.opennicproject.org
  • Subject: Re: [opennic-discuss] broken https on reg.libre
  • Date: Fri, 22 May 2020 08:32:23 -0400

You could do a split PGP/GPG key approach, where two people with their own individual Yubikeys (or similar device) need to sign the intermediate, but we would need to figure out how to convert these signed certs into X.509 after the fact. I’m not sure if this is even possible, as PGP/GPG has *some* X.509 capabilities, I just don’t know if it supports all the extensions necessary for a CA intermediate.

Any OpenSSL/GPG/PGP gurus on here that know of a similar mechanism (split private key)?

Rouben

On Fri, May 22, 2020 at 07:52 Erich Eckner <opennic AT eckner.net> wrote:
-----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-----

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



Archive powered by MHonArc 2.6.19.

Top of Page