Hello, After recent experiment I noticed that there is a man-in-the-middle vulnerability in Microsoft Windows IPSec implementation when using certificates for authentication. This also includes the Windows L2TP/IPSec VPN. It seems that this is a known problem as there where posts mentioning this on bugtraq before. (see: http://www.securityfocus.com/archive/1/347392) However nobody seems to care about this, and it's nearly nowhere mentioned on the well-known VPN howtos. Windows is verifying the authenticity of an IPSec Gateway by checking the gateway certificate against its trusted CA public key. Thus only a gateway with a valid certificate is accepted. But it DOES NOT check the subject of the certificate e.g. the CN field. As a matter of fact every other member of the VPN network with a valid client certificate can setup a IPSec Gateway. The fouled clients will accept the attackers certificate because it has a valid signature. They will not notice that the attacker is not the real gateway but an other client. On further investigation on this topic I took a look on the EAP/TLS 802.1x stuff for authentication WPA WLAN links which is also using certificates. Microsoft has introduced two OID's which are coupled with certificates and which define the purpose - either gateway for server or client. As a result when using 802.1x the attack does not work because a client will not accept another clients certificate as its not valid for gateway usage. I tried to use these OID's for IPSec Authentication as well. The result: it does not help either. Client certificates are still accepted as valid gateway certificates. I've not found any statement from Microsoft on this topic or any official security advisory. However I think this could easily be fixed by enabling the usage of the EAP/TLS OIDs for IPSec authentication. Workaround: You can use this workaround if you use a Linux IPSec implementation as IPSec Gateway and OpenSSL for certificates. Generate a single CA for each pair of Gateway/Client certificates. Configure your gateway to use another certificate/CA for each client. The single clients won't accept each other as gateways because their certificates are signed by different CA's. Greetings, Steffen Pfendtner -- Steffen Pfendtner <steffen@wh-netz.de> GPG Key fingerprint = DF91 11BB 498F 573B 8002 6E0B 3AE3 FF88 EADD B3BC
