User interface, security, and "simplicity"

[Thor Lancelot Simon]

It's fashionable in some circles (including, it seems, this one) to bash
IPsec (particularly IKE) and tout SSL VPNs (particularly OpenVPN) on what
are basically user interface grounds.

I cannot help repeatedly noting that -- I believe more so than with actual
IPsec deployments, whether with or without IKE -- OpenVPN deployments are
often configured in hideously insecure ways.  This is no more the fault of
OpenVPN's designers, of course, than the ghastly configuration interfaces
imposed by many IKE impledmentations are the fault of IPsec's designers.

See, for example, http://doc.pfsense.org/index.php/VPN_Capability_OpenVPN
which is the official documentation from the popular "pfsense"
firewall/NAT/VPN package on configuring OpenVPN for use with clients.  Of
particular note:

	1) It is not possible to configure a list of expected identities
	   of users; rather, just a CA which must sign for all users.

	2) No CRL is configured, nor do the instructions say to do so,
	   though it is possible.

	3) The client and server certificates come from the same CA,
	   and both client and server get configured with *only the CA
	   certificate*, not the subject name of the expected peer.

		This is, of course, a serious security hole all of its
		own, since it allows any client to conduct an MITM 
		attack and impersonate the server.

	4) Instructions are given for using a package called "EasyRSA"
	   to set up a CA and create and sign keys.  These instructions
	   have several severe flaws of their own:

		a) They generate client public and private keys *on the
		   CA* rather than using client generation and proper
		   certificate signing requests.  This poses a needless
		   risk of private key compromise, which is, in fact,
		   particularly likely, since

		b) The instructions mention only in passing that oh, by
		   the way, one might want to encrypt the client's new
		   private key, and that one _could_ do so -- but the
		   example does not, in fact, encrypt the key.
		   Anecdotally I have heard of a few users of this
		   combination of software packages (OpenVPN/pfsense/
		   EasyRSA) who bother to encrypt the private keys
		   they send to users -- but quite a few more who just
		   ship them around plaintext, since the example does
		   so.

		c) No documentation at all is given of how to revoke a
		   key, nor why one would want to do so.

	5) No explanation whatsoever is given of the compromises made in
	   the process of "simplifying" the configuration of this VPN
	   software -- which are significant and have major security
	   consequences.

The upshot is that, indeed, at least as shown here, this particular
configuration frontend to OpenVPN is very easy to configure -- if you
are willing to settle for much less security than OpenVPN was designed
to provide, and much less than, if you're naive about cryptography, you
probably think you're getting.

Gee, that's funny, that's one of the problems with IPsec implementations
that people always cite when they tout SSL VPNs (the other is that some
firewalls can't be configured to pass IP protocol 50 for ESP -- but, of
course, ESP can be tunneled in UDP, in a standard way, and that's been
true for years now).

I am left with the strong suspicion that SSL VPNs are "easier to configure
and use" because a large percentage of their user population simply is not
very sensitive to how much security is actually provided.  Someone said
"have a firewall", they set up a firewall.  Someone says "I can't get in
through the firewall, set up a VPN", they set up a VPN.  For their purposes
IP over DNS might serve just as well -- and if enough other people said it
was secure, they'd probably get all defensive if you said it wasn't, at
least not how they'd configured it.

One could think of it, I suppose, as a combination of drinking the Kool
Aid and buying the snake oil -- drinking the snake oil?  Whatever one calls
it one should be very careful of its effects on the popular consciousness
when trying to understand what user preferences for this security product
over that one actually mean.

Thor

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com