doc: SSL management system #2712
Conversation
architeuthidae
force-pushed
the
man-ssl-support
branch
from
630c644 to
3a2d2c9
Compare
doc/manual/getting_started_mgmt.rst
Outdated
|
|
||
| .. note:: | ||
|
|
||
| If you understand the basics of TLS/SSL and web certificates, you might find it helpful to know that the given client certificate is really understood by the master as a certificate authority. That is to say, if you'd prefer to generate new keys for new clients, you can ensure they'll be recognized by signing their certificates with the original client key. In this context, however, reusing a single client key is perfectly acceptable. |
There was a problem hiding this comment.
Do the client/server certificates have to be CA certs? I was under the impression that self-signed certs without CA:true in the basicConstraints would also work. m-labs/sipyco#46 (comment)
There was a problem hiding this comment.
Cryptographically a (root) CA cert is just a self-signed cert, all that makes it a CA cert is deciding to trust it as one. For both master and client the "peer cert" is ultimately understood as a root CA, which as far as I'm aware (admittedly, haven't tested) should allow the use of multiple client keys as above.
There was a problem hiding this comment.
It seems to be more of a semantic matter than a technical one. I know that the ssl library may call it a cafile but its clear that it accepts x509 certs with CA:FALSE in our case. Given that this note is meant to be for more experienced users, perhaps saying that the "client certificate may be a CA" and then used for the purpose you described.
There was a problem hiding this comment.
May doesn't quite sit right with me purely because to me the difference isn't CA:true or CA:false, but the much more concretely security-relevant issue of how the certificate is trusted, and it is trusted as a root CA, no matter how it's marked. Maybe "is accepted as"?
There was a problem hiding this comment.
Sure that seems fine. Can you make it slightly more explicit that this is unique to the example provided? End-entity root certs would also be acceptable in our setup, and in fact the p2p nature of it seems to suggest this use-case (as well as the comment I linked). The command you link to, despite the parameter name, does not require the cafile to contain a cert with the ability to sign other certs. It ensures that the root cert is a "trust anchor" and only checks for CA:TRUE if there are other certs in the chain. Hence why a client cert with CA:FALSE is not rejected.
https://github.com/openssl/openssl/blob/master/doc/man3/SSL_CTX_load_verify_locations.pod#notes
https://docs.openssl.org/3.1/man1/openssl-verification-options/#trust-anchors
architeuthidae
force-pushed
the
man-ssl-support
branch
2 times, most recently
from
97ad00f to
bffbfc6
Compare
|
Edited to incorporate artiq-comtools/17 |
architeuthidae
force-pushed
the
man-ssl-support
branch
from
bffbfc6 to
73cbaf1
Compare
|
|
||
| $ artiq_client --ssl <client.pem> <client.key> <master.pem> | ||
| $ artiq_dashboard --ssl <client.pem> <client.key> <master.pem> | ||
| $ artiq_ctlmgr --ssl <client.pem> <client.key> <master.pem> |
There was a problem hiding this comment.
This will need an update after SSL support for the controllers themselves is done.
|
|
||
| Some users may recognize that reusing the same private key between multiple machines is unusual and somewhat frowned upon by cryptographic standards. This is largely because, famously, the larger the group of people keeping a secret, the more difficult the secret is to keep. In particular, a private key *is* secret, and should be passed around only with significant care, which becomes more difficult the more often it has to be done. It is also in part because using the same key means clients can't be cryptographically distinguished from each other, i.e., two authorized clients might still impersonate *each other.* | ||
|
|
||
| In practice, ARTIQ nonetheless recommends this method, purely because generating certificates and keys *per client* involves considerably more management overhead, and can be equally insecure if not handled just as carefully. Additionally, all clients are equal, so there's no benefit to be gained by impersonation. In this context, reusing a single client key is acceptable. |
There was a problem hiding this comment.
It's usually just a few machines within the same lab...
There was a problem hiding this comment.
e.g. the justification about avoiding the management overhead of multiple keys doesn't hold water, or ...?
|
|
||
| .. tip:: | ||
|
|
||
| On the other hand, if you understand the basics of TLS/SSL and web certificates, you might find it helpful to know that the given client certificate is also accepted by the master as a *root certificate authority.* That is to say, if you'd prefer to generate new keys for new clients, you can ensure they'll be recognized by signing their certificates with the original client key. Note that changing the certificate authority given to the master will necessitate replacing *all* of the client certificates! |
There was a problem hiding this comment.
Did someone actually test that? This kind of SSL functionality has a bunch of rough edges in my experience.
There was a problem hiding this comment.
I haven't. @fsagbuya?
ARTIQ Pull Request
To match #2676 and artiq-comtools/17
Related Issue
#2577
Type of Changes
Steps (Choose relevant, delete irrelevant before submitting)
All Pull Requests
Documentation Changes
nix build .#artiq-manual-html; nix build .#artiq-manual-pdf) to ensure no errors.Licensing
See copyright & licensing for more info.
ARTIQ files that do not contain a license header are copyrighted by M-Labs Limited and are licensed under LGPLv3+.