4 ms·

While I'm sure I could configure this on a system, the level of understanding required to actually create it honestly is fantastic. Is this something you creat

While I'm sure I could configure this on a system, the level of understanding required to actually create it honestly is fantastic. Is this something you created yourself, or was it a community project?

teddyh 5y ago
Initial idea and C++ implementation (using TLS with X.509 certificates and explicit UDP broadcasts) was done in 2007 by another person. Redesign of the protocol (to TLS with OpenPGP keys¹ and DNS Service Discovery²), and re-implementation in Python and C, I did in collaboration with that person. In addition to ongoing maintenance, the relatively recent switch from TLS with OpenPGP keys to TLS with Raw Public Keys³ was done by me. The level of understanding required is something I would think that all system administrators worth their salt had at the time. I would think that the best way to acquire such knowledge is doing the Linux From Scratch⁴ exercise, even though I have not done it myself. 1. RFC 6091 2. http://www.dns-sd.org/ http://www.dns-sd.org/, RFC 6763 3. RFC 7250 4. https://www.linuxfromscratch.org/lfs/ https://www.linuxfromscratch.org/lfs/
- Inhibit 5y ago
  That looks like an awesome project but I'm not sure building an LFS system would help developing a system like that. Possibly in understanding and configuring it. I still recall how to build a Linux system from go. Coding what you're working on up in Python/C would take a large unrelated amount of knowledge.
  - teddyh 5y ago
    The knowledge about how to write a program comes naturally when you know, in fine enough detail, both the problem which the program should solve, how to solve it, and the environment in which the program should run. In this case, writing a Python server program to respond to requests was relatively simple; Python provides built-in modules which makes writing servers easy. And when you know what the client program (i.e. the program running on the currently locked host) should do, and you know what environment the program has to operate in, the program more or less writes itself. The first version of the program used a simple UDP broadcasting method to a hard-coded port to find servers, which required some rudimentary networking knowledge, but only basic TCP/IP stuff. Later, both the server and client parts have gone through numerous refactorings which brought in many features (like a plugin system on the client side, and a D-Bus interface on the server side), but those were manageable chunks to add to an already mature and working system. But sure, in addition to the knowledge one could acquire from LFS, I also had some high-level knowledge of how TLS and its handshake worked, I knew that there was some way to use OpenPGP keys instead of X.509 certificates in TLS, and I knew a little about how DNS-SD worked. The rest I needed I read up on as I wrote the code.
- hamburglar 5y ago
  Looks like a neat project but the intro/faq should probably be a bit more self-critical to point out weaknesses. The “nope, it’s protected by TLS” answers ignore the fact that anyone attacking this could also have attacked the PKI. If someone gets the client cert and key, they can probably fake the request to get the decryption password. I’m assuming that client key isn’t protected by a password, since then that would be the thing a user has to provide at boot time. And what about the vector where someone attacks the CA that issued the certs? Where is that stored? Can fake roots be injected by someone in possession of both machines? This may be moot if you are using self-signed certs, but of course those introduce their own management issues. Also, I don’t really see any discussion of availability concerns. This is a system with a pretty gnarly fail-closed kill switch that could happen with a simple network outage. That doesn’t really seem to be acknowledged and there’s no discussion of the inherent balance between security and availability. You really need to be able to guarantee a certain level of availability or things basically self-destruct. Presumably there’s a mechanism that allows a self-destructed pair or cluster of these mandros’d servers to go back to a normal operating mode? Anyway, I don’t mean to be too critical. It’s a really cool project. A little Byzantine but with a stated reason for that. Would just like to see more focus on the weaknesses and potential critical operational issues. A section called “reasons you may not want to use this” that is very up front about those seems appropriate.
  - 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.
hinkley 5y ago
Hardware security modules are no cakewalk either. For webservers I think most people consider them overkill. They mostly IME get used to handle code signing. And at one company they were worried about the devices getting stolen, so they could had HSMs and still couldn’t reboot unattended (though most of the signing keys were with humans rather that automated)

teddyh 5y ago

Initial idea and C++ implementation (using TLS with X.509 certificates and explicit UDP broadcasts) was done in 2007 by another person. Redesign of the protocol (to TLS with OpenPGP keys¹ and DNS Service Discovery²), and re-implementation in Python and C, I did in collaboration with that person. In addition to ongoing maintenance, the relatively recent switch from TLS with OpenPGP keys to TLS with Raw Public Keys³ was done by me. The level of understanding required is something I would think that all system administrators worth their salt had at the time. I would think that the best way to acquire such knowledge is doing the Linux From Scratch⁴ exercise, even though I have not done it myself. 1. RFC 6091 2. http://www.dns-sd.org/ http://www.dns-sd.org/, RFC 6763 3. RFC 7250 4. https://www.linuxfromscratch.org/lfs/ https://www.linuxfromscratch.org/lfs/

Inhibit 5y ago
That looks like an awesome project but I'm not sure building an LFS system would help developing a system like that. Possibly in understanding and configuring it. I still recall how to build a Linux system from go. Coding what you're working on up in Python/C would take a large unrelated amount of knowledge.
- teddyh 5y ago
  The knowledge about how to write a program comes naturally when you know, in fine enough detail, both the problem which the program should solve, how to solve it, and the environment in which the program should run. In this case, writing a Python server program to respond to requests was relatively simple; Python provides built-in modules which makes writing servers easy. And when you know what the client program (i.e. the program running on the currently locked host) should do, and you know what environment the program has to operate in, the program more or less writes itself. The first version of the program used a simple UDP broadcasting method to a hard-coded port to find servers, which required some rudimentary networking knowledge, but only basic TCP/IP stuff. Later, both the server and client parts have gone through numerous refactorings which brought in many features (like a plugin system on the client side, and a D-Bus interface on the server side), but those were manageable chunks to add to an already mature and working system. But sure, in addition to the knowledge one could acquire from LFS, I also had some high-level knowledge of how TLS and its handshake worked, I knew that there was some way to use OpenPGP keys instead of X.509 certificates in TLS, and I knew a little about how DNS-SD worked. The rest I needed I read up on as I wrote the code.
hamburglar 5y ago
Looks like a neat project but the intro/faq should probably be a bit more self-critical to point out weaknesses. The “nope, it’s protected by TLS” answers ignore the fact that anyone attacking this could also have attacked the PKI. If someone gets the client cert and key, they can probably fake the request to get the decryption password. I’m assuming that client key isn’t protected by a password, since then that would be the thing a user has to provide at boot time. And what about the vector where someone attacks the CA that issued the certs? Where is that stored? Can fake roots be injected by someone in possession of both machines? This may be moot if you are using self-signed certs, but of course those introduce their own management issues. Also, I don’t really see any discussion of availability concerns. This is a system with a pretty gnarly fail-closed kill switch that could happen with a simple network outage. That doesn’t really seem to be acknowledged and there’s no discussion of the inherent balance between security and availability. You really need to be able to guarantee a certain level of availability or things basically self-destruct. Presumably there’s a mechanism that allows a self-destructed pair or cluster of these mandros’d servers to go back to a normal operating mode? Anyway, I don’t mean to be too critical. It’s a really cool project. A little Byzantine but with a stated reason for that. Would just like to see more focus on the weaknesses and potential critical operational issues. A section called “reasons you may not want to use this” that is very up front about those seems appropriate.
- 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.

hinkley 5y ago

Hardware security modules are no cakewalk either. For webservers I think most people consider them overkill. They mostly IME get used to handle code signing. And at one company they were worried about the devices getting stolen, so they could had HSMs and still couldn’t reboot unattended (though most of the signing keys were with humans rather that automated)