2 ms·

> If someone gets the client cert and key, they can probably fake the request to get the decryption password. Yes, that is a weakness, which is openly addresse

by teddyh 5y ago

> If someone gets the client cert and key, they can probably fake the request to get the decryption password. Yes, that is a weakness, which is openly addressed in the FAQ: https://www.recompile.se/mandos/man/intro.8mandos#quick https://www.recompile.se/mandos/man/intro.8mandos#quick TLDR: It only works if an attacker is pretty quick about it. See also here: https://www.recompile.se/mandos/man/intro.8mandos#security https://www.recompile.se/mandos/man/intro.8mandos#security > And what about the vector where someone attacks the CA that issued the certs? There is no CA involved, nor any X.509 keys. The keys used in TLS are ed25519 raw keys, and the server has a list of, and checks, individual key fingerprints. > This may be moot if you are using self-signed certs, but of course those introduce their own management issues. Yes, you have to generate and transport keys out-of-band (i.e. by hand) as part of the initial setup. The instructions on exactly how to do this are shown as part of installation and configuration. > a pretty gnarly fail-closed kill switch That’s a feature. A security system should fail closed. > Presumably there’s a mechanism that allows a self-destructed pair or cluster of these [mandos]’d servers to go back to a normal operating mode? Yes. You either type in a password on the console on one of the servers, or use a dropbear to ssh in remotely to do it. > A section called “reasons you may not want to use this” that is very up front about those seems appropriate. The project is mostly intended for those people who have already decided that full-disk encryption is a requirement, and Mandos is meant to alleviate some of the pain which they have already accepted. But sure, I see your point.

hamburglar 5y ago
> That’s a feature. A security system should fail closed. Of course, but there should at least be a mention of the fact that you need to tune the fail-closed parameters to take your availability into consideration. I appreciate that the various attacks would have to be done "pretty quick" according to the FAQ but the definition of "pretty quick" is necessarily countered by what kind of guarantees you can make about your availability (of the server(s) and the client), and this isn't mentioned. If a 30 second network failure causes the server to refuse keys to the client from that point on, but you can't guarantee that level of network availability (taking into account things like replacement of network switches and other types of maintenance), the definition of "pretty quick" may be too quick. It's a very direct and explicit tradeoff between security and availability and that concept is absent from the intro/FAQ. As a mental exercise, consider how you'd answer the FAQ "So I should set my timeouts super low for better security?" Again, I'm not trying to be a picky ass, and I think the project is cool. I just think this is a topic that non-security-folks don't necessarily think about automatically, and this is the opportunity to make them think about it. The entire doc sounds like "faster timeout == better" and it would be very unfortunate for someone to configure and deploy this based on that understanding. PS your other responses to my nitpicks were great, and somehow I missed the entry about stealing the client key being possible but having to be done very quickly. Thumbs up. I'm curious about what you mean by saying you aren't using "x509 keys" though. You must be generating a self-signed x509 cert containing the client's pubkey in order to do TLS. The packaging of the key itself isn't really relevant, is it? The "cert validation" on either side doesn't really care much about the contents of the cert other than the pubkey encoded therein, but you still do actually have to create x509 certs using those keys unless you've completely butchered the TLS stack. Right?
- teddyh 5y ago
  The timeout can’t realistically be set very short, since it needs to allow for a normal reboot of a server. Servers are, in my experience, notoriously slow to reboot. Therefore, a typical network hiccup is assumed to be shorter than that. The default timeout value of 5 minutes reflects this. Also, you could add the Mandos server status to your alerting system, and if anything goes wrong with your network and the Mandos server times out for a client, you can be alerted to this fact, so you can fix it before the next time that client happens to reboot. > consider how you'd answer the FAQ "So I should set my timeouts super low for better security?" Fair; the text could be clearer about this. > I'm curious about what you mean by saying you aren't using "x509 keys" though. Well, we aren’t using TLS with X.509 keys. We are using TLS with Raw Public Keys, as specified by RFC 7250 (https://www.rfc-editor.org/rfc/rfc7250.html https://www.rfc-editor.org/rfc/rfc7250.html) and supported by GnuTLS: https://www.gnutls.org/manual/gnutls.html#Raw-public_002dkeys https://www.gnutls.org/manual/gnutls.html#Raw-public_002dkey...

by teddyh 5y ago

hamburglar 5y ago

> That’s a feature. A security system should fail closed. Of course, but there should at least be a mention of the fact that you need to tune the fail-closed parameters to take your availability into consideration. I appreciate that the various attacks would have to be done "pretty quick" according to the FAQ but the definition of "pretty quick" is necessarily countered by what kind of guarantees you can make about your availability (of the server(s) and the client), and this isn't mentioned. If a 30 second network failure causes the server to refuse keys to the client from that point on, but you can't guarantee that level of network availability (taking into account things like replacement of network switches and other types of maintenance), the definition of "pretty quick" may be too quick. It's a very direct and explicit tradeoff between security and availability and that concept is absent from the intro/FAQ. As a mental exercise, consider how you'd answer the FAQ "So I should set my timeouts super low for better security?" Again, I'm not trying to be a picky ass, and I think the project is cool. I just think this is a topic that non-security-folks don't necessarily think about automatically, and this is the opportunity to make them think about it. The entire doc sounds like "faster timeout == better" and it would be very unfortunate for someone to configure and deploy this based on that understanding. PS your other responses to my nitpicks were great, and somehow I missed the entry about stealing the client key being possible but having to be done very quickly. Thumbs up. I'm curious about what you mean by saying you aren't using "x509 keys" though. You must be generating a self-signed x509 cert containing the client's pubkey in order to do TLS. The packaging of the key itself isn't really relevant, is it? The "cert validation" on either side doesn't really care much about the contents of the cert other than the pubkey encoded therein, but you still do actually have to create x509 certs using those keys unless you've completely butchered the TLS stack. Right?

teddyh 5y ago
The timeout can’t realistically be set very short, since it needs to allow for a normal reboot of a server. Servers are, in my experience, notoriously slow to reboot. Therefore, a typical network hiccup is assumed to be shorter than that. The default timeout value of 5 minutes reflects this. Also, you could add the Mandos server status to your alerting system, and if anything goes wrong with your network and the Mandos server times out for a client, you can be alerted to this fact, so you can fix it before the next time that client happens to reboot. > consider how you'd answer the FAQ "So I should set my timeouts super low for better security?" Fair; the text could be clearer about this. > I'm curious about what you mean by saying you aren't using "x509 keys" though. Well, we aren’t using TLS with X.509 keys. We are using TLS with Raw Public Keys, as specified by RFC 7250 (https://www.rfc-editor.org/rfc/rfc7250.html https://www.rfc-editor.org/rfc/rfc7250.html) and supported by GnuTLS: https://www.gnutls.org/manual/gnutls.html#Raw-public_002dkeys https://www.gnutls.org/manual/gnutls.html#Raw-public_002dkey...