|
|
Hello Ken,
On Mon, Mar 05, 2007, Ken GALLO wrote:
>On Mon, Mar 05, 2007, Michael wrote:
>> In the online docs, it mentions that a man in the middle attack can
>> best be prevented by using the --ns-cert-type <client|server>
>> option, while using the --tls-remote <server common name> ranks
>> second. Why is --ns-cert-type more effective in this context?
>>
>Every certificate you sign will have "purpose" options embedded in it.
>There are a variety of options, but for this discussion lets say there is
>"client" and "server". Because you control the certificate authority, you
>control which certificates have a "server" purpose.
>
Yes I know, but...
The manpage speaks of a man in the middle (MITM) attacker
impersonating a legitimate OpenVPN server through use of an
already authenticated OpenVPN client. Such a person would
have to have several things to attack a new OpenVPN client
wishing to connect (for example):
o Control over the new client's DNS cache/resolver
or
o Control over the legitimate server's nameserver
and
o Control over the CA used to sign the new client's certificate
If they indeed already have that, then I don't see the logic behind
statements like 'ns-cert-type and/or tls-remote can protect against
an MITM attack'.
The attacker would have to know if the new client insists on
a 'client' or 'server' purpose and which CN the server uses, but
they have that already from their own existing client connection.
Then they generate a X.509 with the corresponding purpose and CN,
and the new client has no way to tell the difference.
>Your clients can be configured to only connect to servers with a "server"
>certificate. This helps against MITM attacks because there are a limited
>number of these certificates, and one presumes their keys are heavily
>protected.
>
I wonder what purpose is coded into X.509 server certificates
issued by the typical CAs. I would guess both 'client' and 'server',
rendering ns-cert-type client checks useless for most commercial
certificates.
The hurdle for attacking self-generated certs isn't being able to
code the 'server' purpose into the cert, rather it's obtaining the
CA in use by the legitimate OpenVPN server. Then ns-cert-type
client checks are useless for noncommercial certs as well.
Am I missing something behind the logic of 'protecting against MITM
with ns-cert-type and tls-remote'?
Regards,
Michael
______________________
OpenVPN mailing lists
https://lists.sourceforge.net/lists/listinfo/openvpn-users
|