3 ms·
> 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 p
by 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 agoThe 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...