NTS - lesson in certificates/keys please

Fri Jan 18 07:30:05 UTC 2019

On 1/17/19 11:35 PM, Gary E. Miller via devel wrote:
> Many root certs are for 10 years or more.  I would shoot any admin that
> put a server live that had been sitting around for 10 years w/o updates.

Agreed!

----

I have a bunch of experience dealing with TLS (for multiple higher level
protocols) as an admin.

A daemon that needs a TLS certificate needs to allow the admin to
specify three things at a minimum: a private key, a certificate, and an
intermediate certificate bundle. These would be passed to the SSL
library. Depending on the SSL library and daemon, sometimes the
certificate and intermediate bundle are provided in a single file, and
sometimes they are provided in two files.

As an additional complication, right now we seem to be in a transition
away from RSA towards ECDSA, so some daemons will support providing both
types of keys (and thus two separate certificates, one for each key, and
thus two separate intermediate bundles).

An intermediate certificate bundle is one or more intermediate
certificates. This is required because certificates are no longer issued
directly from Root CAs, for security reasons. (This way, the CA can keep
the Root private key locked up most of the time.)

For a Let's Encrypt certificate, you'd have a hierarchy like this:
DST Root CA X3
  Let's Encrypt Authority X3
    mysite.com

So the certificate file is the certificate for mysite.com. The
intermediate file has the certificate for Let's Encrypt Authority X3.

The intermediate bundle could have multiple certificates. It could also
have multiple _paths_. For example, Let's Encrypt has its own root:
https://letsencrypt.org/certificates/

They are still typically issuing certificates off the chained root from
Identrust because it is more widely trusted by browsers, especially
because of older browsers. But it is possible to provide both paths.
(The question is if the clients support this properly, so typically for
HTTPS a conservative approach is taken and only one path is provided.)

DST Root CA X3
  Let's Encrypt Authority X3 (IdenTrust cross-signed)
    mysite.com

ISRG Root X1
  Let's Encrypt Authority X3 (Signed by ISRG Root X1)
    mysite.com

In this case, the intermediate bundle would include both versions of
Let's Encrypt Authority X3.

A daemon should also allow the following sort of settings (Apache names
follow):
SSLProtocol - Which versions of TLS to allow.*
SSLCipherSuite - A cipher string for OpenSSL (or whatever SSL library).
SSLHonorCipherOrder - Whether to use the server's order or the client's.

The cipher string allows for the list of allowed ciphers to be modified
by the administrator as vulnerabilities are found. Here is an example of
a current best practice-based cipher string for OpenSSL (with manual
line wrapping added for this email):
EECDH+ECDSA+AESGCM:+EECDH+ECDSA+AESGCM+AES256:EECDH+aRSA+AESGCM:
+EECDH+aRSA+AESGCM+AES256:EECDH+ECDSA+SHA256:EECDH+ECDSA+SHA384:
EECDH+aRSA+SHA256:EECDH+aRSA+SHA384:EECDH+AES128:EECDH:EDH+aRSA+AESGCM:
+EDH+aRSA+AESGCM+AES256:EDH+aRSA+AES128+SHA256:EDH+aRSA+SHA256:
EDH+aRSA+AES128:EDH+aRSA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:
!SRP:!DSS:!RC4

You can see the order of the ciphers that this delivers with:
openssl ciphers -v ...the string...

* In the case of NTS, I believe the spec calls for TLS 1.3 at a minimum,
since there is no backwards compatibility needed. But eventually, there
will undoubtedly be a new TLS version. If a future TLS 1.4 comes out,
this parameter allows the admin to eventually disallow TLS 1.3 at that
point. For a more current example, it has long been the case to disable
SSLv3 with this parameter for HTTPS, and the recent trend is disabling
TLS 1.0 and 1.1, which is required by certain binding security standards
(e.g. PCI DSS from the credit card industry).

Let's Encrypt was already mentioned. Keep in mind that it will be
replacing the certificate every 2 months or so. It will need to tell the
daemon to reload the key & certificate at that point, either by
restarting it or some other mechanism, like sending a HUP. So you may or
may not want to provide a mechanism lighter weight than a restart. And
expect it to be used relatively frequently.

For another presentation of some of this, with an actual example, see:
https://www.ssllabs.com/ssltest/analyze.html?d=ntpsec.org

Once the basics area all working, you should look at OCSP stapling to
see if that is applicable here. OCSP is a protocol for checking with the
CA to determine if the certificate is still valid (i.e. not revoked).
However, checking with the CA on every request is _very bad_. This adds
delay to every SSL initialization. It makes the CA a performance and
failure choke point. It also gives away information to the CA, as each
client hits the CA for every site they load. So nobody does this, and we
would then lose the benefits of checking for certificate revocation. The
solution to this is OCSP stapling. With OCSP stapling, the server daemon
(e.g. Apache), not the client, periodically contacts the CA. The CA
provides a signed, time-stamped, time limited response attesting to the
current validity of the certificate. The daemon then "staples" that
response to the certificate that it sends to clients.

Some examples of configuration parameters...

Apache:
https://httpd.apache.org/docs/2.4/ssl/ssl_howto.html
SSLCertificateFile
SSLCertificateKeyFile

ProFTPD:
http://www.proftpd.org/docs/howto/TLS.html
TLSRSACertificateFile
TLSRSACertificateKeyFile

Dovecot:
https://wiki.dovecot.org/SSL/DovecotConfiguration
ssl_cert
ssl_key

-- 
Richard

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20190118/c5987058/attachment.bin>