wallet/docs/how_to_do_VPNs.html

<!DOCTYPE html>
<html lang="en"><head>

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

<style>
		body {
			max-width: 30em;
			margin-left: 2em;
			}
	p.center {text-align:center;}
</style><title>How to do VPNs right</title></head><body>

<p><a href="./index.html"> To Home page</a> </p>

<h1>How to do VPNs right</h1>

<h2>This web page obsolete.  VPN’s are now relatively easy to use</h2>

Most existing VPNs are extremely hard to set up correctly
– and rather too easy to set up incorrectly.&nbsp; <p>

Part of the problem is that many of them imitate or copy
SSL’s X.509 key negotiation.  X.509 throws up its hands in
despair at the key distribution problem and abandons it
to the end user.&nbsp; SSL session setup performance is poor,
and no one has succeeded in making SSL user friendly to
use it in a way that is actually safe.  If using SSL or
its various successors, the end user must himself grapple
with cryptographic concepts that give cryptographers a
hard time, and which professional cryptographers
frequently screw up.  So inevitably, the end user gets it
wrong almost all the time, even expert highly motivated
users.&nbsp; </p><p>

If you start from SSL or DTLS you are going to wind up
with the sort of hopelessly difficult VPN setups that we
have in fact wound up with.  It is completely unacceptable
to tell your end users to use OpenSSL to create
certificates, certify them and then install the
certificates, which is the sort of thing we are all too
frequently instructed to do.&nbsp; </p><p>

Instead, one needs to devise the user interface, then work
backwards from the user interface to key negotiation, and
then use SSL/TLS, or SSL/TLS concepts only to the extent
that TLS fits the actual solution, rather than trying to
build a solution out of TLS.  In this page, I will
describe VPN setup done right.&nbsp; </p><p>

In any VPN system, each packet within a session must have
its own unique IV (nonce), and each session must have its
own symmetric encryption secret and authentication
secret.&nbsp; We have to have a new session every client
restart, every server restart, and every 2^64 bytes.&nbsp; At
the beginning of each new session, new strong secrets,
large truly random numbers, have to be negotiated for
symmetric encryption and authentication.&nbsp; </p><p>

The problem is that humans are not going to carry around
large strong secrets every time either end of the
connection restarts.&nbsp; In fact they are not going to
transport large strong secrets any time ever, which is the
flaw in SSL and its successors such as IPSec and DTLS.&nbsp;
</p><p>

Humans have long relied on shibboleths for security
against treachery by outsiders. Thus the computer
interface to our clever cryptographic algorithms must
resemble as closely as possible the ancient human
reliance on shibboleths for security.&nbsp; </p><p>

What humans <em>are</em> going to do, and what the user
interface must support, and the cryptography somehow make
secure, is set up a user name and a rather short password,
and enter that password on request – rather too easily
enter it on request without necessarily checking who they
are  giving it to.&nbsp; Our security has to work with humans
as they are, and make what humans are naturally inclined
to do secure, rather than try to change what humans are
naturally inclined to do.&nbsp; </p><p>

So the VPN setup is this:.&nbsp;</p><ul><li><p>

Server starts VPN server program, client starts VPN client
program for the very first time.&nbsp; Human at client enters
a URL for the server  program.&nbsp; If it connects to the
server (or something pretending to be  the server) it
requests user name and password, which of course does not
yet exist, and offers the user the choice of creating a
new user name and  password. </p></li><li><p>

User at the client creates a new user name and password.&nbsp;
Client logs in, and reports that user so and so has
absolutely no privileges, needs to talk to the
administrator on the server.&nbsp; The user at the client
contacts the administrator on the server out of band, this
being the standard way  VPNs are in fact set up in
practice.&nbsp; Our security ultimately rests on this out of
band human to human discussion, which relies on standard
human to human security, which humans are naturally quite
good at, thanks to several million years of evolution
involving frequently lethal treachery.&nbsp; The administrator
then looks at the gui of the server program (yes, it has
to have a gui, unlike most existing VPNs) which lists the
various user names (but not their passwords, for, as we
shall see, the server program does not in fact know the
password).&nbsp; The administrator then gives user name the
necessary privileges. </p></li><li><p>

Obviously we do not want to repeat this scene every time
either end of the connection restarts.  So the client
gives the end user the option  that the client will
remember the server address, user name and password, and  logon
automatically on startup – in which case anyone with
physical access to the computer can steal the password,
which can be strongly  obfuscated but not truly hidden,
but that is the kind of threat the end user can
understand and properly evaluate.  All existing VPNs have
similar problems, as does email.&nbsp; </p><p>

Also, anyone that installs malware on the end user’s
computer can steal the password, which threat the end user
cannot be expected to understand  or properly evaluate. We
know <a href="safe_operating_system.html">how to defeat
malware</a> – Polaris and Bitfrost show how to make
malware almost impossible, but malware resistant operating
systems still have some rough edges.&nbsp; Regardless, SSL
certificates and email programs have the same problem, so
we are just going to live with the node weakness until the
day that every operating system works the way that
Bitfrost is intended to work. </p></li></ul><p>

Now we look at making this system cryptographically secure
against  active and passive attacks on the wire, phishing,
and social engineering.&nbsp; </p><ul><li><p>

If the user enters the user name and password incorrectly,
then he  has to pass a reverse Turing test before entering
the password again, to  prevent scripts from trying
millions of passwords.&nbsp; So if an attacker  has tried to
guess passwords, the VPN network will not automatically
login on client startup, but will instead require user
intervention to respond to the reverse Turing test.  The
user will be informed by the  server that n unsuccessful
login attempts have taken place against his user name, thus
notifying him he is under attack.&nbsp; So the fact that the
attacker can force manual intervention on client restart
is hereby  declared to be a feature, not a bug.&nbsp;
</p></li><li><p>

The user interface to create a connection never pops up
spontaneously, but only as a direct result of the user
choosing to cause it to pop up, typically by clicking
the create-a-connection icon on his start menu.&nbsp;
</p></li><li><p>

We use password-authenticated key agreement to construct a strong frequently changing
secret from the short infrequently changing secret.  Thus
if the user logs in to the wrong host – or to an
adversary pretending to be the correct host in a man
in the middle attack, the false server does not get the
password or the session secret.&nbsp; </p></li><li><p>

Password-authenticated key agreement also ensures that a passive eavesdropper will not
discover the password or the strong session secret.&nbsp; </p>
</li></ul><p>

The short password is OK, because offline attacks are
impossible due to password-authenticated key agreement.&nbsp; The total lack of security on
the URL is OK because phishing attacks are impossible due
to password-authenticated key agreement.&nbsp; Of course they are only impossible due to password-authenticated key agreement
if the end user is using his own client with a hostile
address and is therefore <em>using</em> password-authenticated key agreement.  If he is using
a hostile client, he is hosed.&nbsp; To reduce the risk that
he may be fooled into using a hostile client, the user
interface to create a connection should never pop up
spontaneously.&nbsp; If the connection is needed, but not
present, the operation should just fail.&nbsp; </p><p>

The client software should always mangle the user
passphrase with the unchanging server public key, so if
the user uses the same password for accounts with
multiple entities, those entities cannot use this against
each other.&nbsp; </p><p>

The reverse Turing test protects against scripted online
password guessing attacks.  The various retry, leakage,
and replay attacks on symmetric encryption do not work
because we always have a nonce for each and every packet,
we password-authenticated key agreement renegotiate new shared secrets for every session
and we have new sessions as often as cryptographically
needed.&nbsp; </p>

<p style="background-color : #ccffcc;  font-size:80%">These documents are
licensed under the <a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/">Creative
Commons Attribution-Share Alike 3.0 License</a></p>
</body></html>