Michael Orlitzky <mich...@orlitzky.com> wrote: > On 10/14/2013 07:49 AM, Martin Vaeth wrote: >> >> Using yet another service with possible holes to protect a sshd? >> In this case, I would like port knocking at least for this OpenVPN. > > The sensitive parts of OpenVPN are audited regularly, and it uses "SSL" > -- public key auth to exchange a symmetric key, both of which use > tried-and-true algorithms/code.
So its completely as well-audited and secure as openssh was when the Debian disaster happened. Also IIRC there are currently some timing attacks against certain SSL modes, and who knows when some clever hacker finds another possibility nobody thought of up to now. > Port knocking on the other hand is just security through obscurity As is every password. > and is visible over the wire This is why you have to change it regularly. Actually, if you change it whenever you used it, you have a rather strong method, essentially only vulnerable if the man-in-the-middle is able to cut your connection, and even then he has only very limited time to attack the actual service which is protected by it. > problem is "solved" if it's easy to exponentially increase the amount > of work an attacker has to do. And exactly for this reason the solution is always only a theory - for very particularly specified problems. For practical machines, it is good to have this *in addition* to other safety measurements: Experience shows that rather often there are some new ideas or bugs which can be used to avoid the exponential amount by something not covered by the original theory. > Obscurity does provide some benefit, but it gets dismissed because we > tend to ignore the constant factor when talking about these things. This is reasonable for theory, but in practice the constant factor can be more important. Even more if it needs human intervention. > Hiding the salt would just be security through obscurity. And yet it is stupid if you do not do it and give away a huge constant factor for no advantage. > Similarly, putting port knocking in front of OpenVPN is like putting a > padlock on the bank vault. If someone is going to break OpenVPN, port > knocking ain't gonna stop them. No. Port knocking is more like putting your bank vault into a wooden box. If some new attack against SSL or the OpenVPN implementation is found, it is like somebody has a key to your vault. If you are a highly important target, this will not save you, but if human resources are needed to break whatever you did for obscurity, it makes in practice the crucial difference. > It's not laziness I'm advocating, just simplicity. Simple, > understandable code is more likely to be correct than clever code. And > in this case, incorrect iptables code is more of a threat than the tiny > race condition. You have a strange mentality: One the one hand you are afraid that a rather primitive translation of one syntax into another leads to unexpected effects, and on the other hand you trust much more complex things like SSL and OpenVPN which could much easier allow unexpected things with even the slightest attempt to secure them further if you can.
