| 1 |
Michael Orlitzky <michael@××××××××.com> wrote: |
| 2 |
> On 10/14/2013 07:49 AM, Martin Vaeth wrote: |
| 3 |
>> |
| 4 |
>> Using yet another service with possible holes to protect a sshd? |
| 5 |
>> In this case, I would like port knocking at least for this OpenVPN. |
| 6 |
> |
| 7 |
> The sensitive parts of OpenVPN are audited regularly, and it uses "SSL" |
| 8 |
> -- public key auth to exchange a symmetric key, both of which use |
| 9 |
> tried-and-true algorithms/code. |
| 10 |
|
| 11 |
So its completely as well-audited and secure as openssh was when |
| 12 |
the Debian disaster happened. Also IIRC there are currently |
| 13 |
some timing attacks against certain SSL modes, and who knows |
| 14 |
when some clever hacker finds another possibility nobody |
| 15 |
thought of up to now. |
| 16 |
|
| 17 |
> Port knocking on the other hand is just security through obscurity |
| 18 |
|
| 19 |
As is every password. |
| 20 |
|
| 21 |
> and is visible over the wire |
| 22 |
|
| 23 |
This is why you have to change it regularly. Actually, if you change |
| 24 |
it whenever you used it, you have a rather strong method, essentially |
| 25 |
only vulnerable if the man-in-the-middle is able to cut your |
| 26 |
connection, and even then he has only very limited time to attack |
| 27 |
the actual service which is protected by it. |
| 28 |
|
| 29 |
> problem is "solved" if it's easy to exponentially increase the amount |
| 30 |
> of work an attacker has to do. |
| 31 |
|
| 32 |
And exactly for this reason the solution is always only a theory - |
| 33 |
for very particularly specified problems. For practical machines, |
| 34 |
it is good to have this *in addition* to other safety measurements: |
| 35 |
Experience shows that rather often there are some new ideas or bugs |
| 36 |
which can be used to avoid the exponential amount by something not |
| 37 |
covered by the original theory. |
| 38 |
|
| 39 |
> Obscurity does provide some benefit, but it gets dismissed because we |
| 40 |
> tend to ignore the constant factor when talking about these things. |
| 41 |
|
| 42 |
This is reasonable for theory, but in practice the constant factor |
| 43 |
can be more important. Even more if it needs human intervention. |
| 44 |
|
| 45 |
> Hiding the salt would just be security through obscurity. |
| 46 |
|
| 47 |
And yet it is stupid if you do not do it and give away a |
| 48 |
huge constant factor for no advantage. |
| 49 |
|
| 50 |
> Similarly, putting port knocking in front of OpenVPN is like putting a |
| 51 |
> padlock on the bank vault. If someone is going to break OpenVPN, port |
| 52 |
> knocking ain't gonna stop them. |
| 53 |
|
| 54 |
No. Port knocking is more like putting your bank vault into a |
| 55 |
wooden box. If some new attack against SSL or the OpenVPN |
| 56 |
implementation is found, it is like somebody has a key to |
| 57 |
your vault. If you are a highly important target, this will |
| 58 |
not save you, but if human resources are needed to break |
| 59 |
whatever you did for obscurity, it makes in practice the |
| 60 |
crucial difference. |
| 61 |
|
| 62 |
> It's not laziness I'm advocating, just simplicity. Simple, |
| 63 |
> understandable code is more likely to be correct than clever code. And |
| 64 |
> in this case, incorrect iptables code is more of a threat than the tiny |
| 65 |
> race condition. |
| 66 |
|
| 67 |
You have a strange mentality: |
| 68 |
One the one hand you are afraid that a rather primitive translation |
| 69 |
of one syntax into another leads to unexpected effects, and on the |
| 70 |
other hand you trust much more complex things like SSL and OpenVPN |
| 71 |
which could much easier allow unexpected things with even the |
| 72 |
slightest attempt to secure them further if you can. |
Archives