199 lines
9.0 KiB
HTML
199 lines
9.0 KiB
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. <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. 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. </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. </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. </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. We have to have a new session every client
|
||
restart, every server restart, and every 2^64 bytes. At
|
||
the beginning of each new session, new strong secrets,
|
||
large truly random numbers, have to be negotiated for
|
||
symmetric encryption and authentication. </p><p>
|
||
|
||
The problem is that humans are not going to carry around
|
||
large strong secrets every time either end of the
|
||
connection restarts. 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.
|
||
</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. </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. 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. </p><p>
|
||
|
||
So the VPN setup is this:. </p><ul><li><p>
|
||
|
||
Server starts VPN server program, client starts VPN client
|
||
program for the very first time. Human at client enters
|
||
a URL for the server program. 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.
|
||
Client logs in, and reports that user so and so has
|
||
absolutely no privileges, needs to talk to the
|
||
administrator on the server. 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. 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. 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). 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. </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. 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. </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. 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. So the fact that the
|
||
attacker can force manual intervention on client restart
|
||
is hereby declared to be a feature, not a bug.
|
||
</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.
|
||
</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. </p></li><li><p>
|
||
|
||
Password-authenticated key agreement also ensures that a passive eavesdropper will not
|
||
discover the password or the strong session secret. </p>
|
||
</li></ul><p>
|
||
|
||
The short password is OK, because offline attacks are
|
||
impossible due to password-authenticated key agreement. The total lack of security on
|
||
the URL is OK because phishing attacks are impossible due
|
||
to password-authenticated key agreement. 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. 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. If the connection is needed, but not
|
||
present, the operation should just fail. </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. </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. </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>
|