Secure Connections

Requirements

• Ensure that sensitive data cannot be intercepted or modified in-transit between client and server
• Enforce need-to-know requirements in a multi-user environment by preventing inadvertent connections among different users' clients and servers.

Terminology

• Private key - a private key is a key that can decrypt information encrypted with the corresponding public key.
• Public key - a public key encrypts information so that it can only be decrypted by the corresponding private key.
• Certificate - combines a public key with information about the owner of the corresponding private key (including country, state, city, organization, e-mail address, etc). A certificate acts as a token which can only have been generated by the holder of a private key.

Prerequisites

Before performing any of the following use-cases, the user must create a set of keys and certificates as-follows (presumably this will be automated through the use of scripts or made part of a simple graphical user interface):

• User generates a private key and corresponding self-signed "session" certificate.
• User generates a private key and corresponding "client" certificate, signed with the "session" key.
• User generates a private key and corresponding "server" certificate, signed with the "session" key.
• User copies session certificate, server certificate, and server key to the server filesystem.

Security Bottom-Line

The bottom-line with this scheme is that clients and servers can only communicate if they are holding certificates signed with the session key. Thus, the session key should be safeguarded against disclosure using password protection and appropriate filesystem permissions.

Although a user could create a single set of certificates and "reuse" them for multiple ParaQ sessions, this would be a potentially serious security hole - once a certificate had been generated for a "friend", that friend would have access to every ParaQ session started by the user, negating the value of the certificate system. Thus, we assume that the certificate-generation process is sufficiently automated to make certificate-generation painless, and to discourage reuse of certificates.

Certificates, even if generated by a single user with identical parameters, will be unique - eliminating the possibility of inadvertent connections between client and server.

Use Cases

Forward Connection

• User launches the server, enabling forward connections, and specifying the paths to the session certificate, server certificate, and server key.
• Server begins waiting for connections using an SSL socket.
• User launches the client, specifying the server host address and port, plus the paths to the session certificate, client certificate, and client key.
• Client connects to the server using SSL. Within the SSL layer both client and server validate that the other host's certificate was signed by the session certificate, and refuse to connect otherwise.

Client Reconnects to Server

• Assume an existing Forward Connection.
• Client disconnects from the server, which continues running.
• User launches another client, specifying the server host address and port, plus the paths to the original session certificate, client certificate, and client key.
• Client connects to the server using SSL. Within the SSL layer both client and server validate that the other host's certificate was signed by the original session certificate, and refuse to connect otherwise.

Friend Connects to Running Server

• Assume an existing Forward Connection.
• Client disconnects from the server, which continues running.
• User gives a copy of the original session certificate, client certificate, and client key to a friend.
• Friend launches a client, specifying the server host address and port, plus the paths to the session certificate, client certificate, and client key.
• Client connects to the server using SSL. Within the SSL layer both client and server validate that the other host's certificate was signed by the original session certificate, and refuse to connect otherwise.

Alternate:

• User generates a new private key and corresponding "client" certificate, signed by the "session" certificate, and passes them to their friend.
• The user may generate as many new keys and client certificates as they like, all signed by the original "session" certificate, for use by friends.

Reverse Connection

• User launches the client, enabling reverse connections, and specifying the paths to the session certificate, client certificate, and client key.
• Client begins waiting for connections using an SSL socket.
• User launches the server, specifying the client host address and port, plus the paths to the session certificate, server certificate, and server key.
• Server connects to the client using SSL. Within the SSL layer both client and server validate that the other host's certificate was signed by the session certificate, and refuse to connect otherwise.

Server Phones Home

• Assume an existing Reverse Connection.
• Client disconnects from the server, specifying a host address, port, and time interval for reconnect attempts. The server continues running, and periodically tries to reconnect to the given host.
• User launches another client, enabling reverse connections, and specifying the paths to the original session certificate, client certificate, and client key.
• Client begins waiting for connections using an SSL socket.
• Server eventually connects to the client using SSL. Within the SSL layer both client and server validate that the other host's certificate was signed by the original session certificate, and refuse to connect otherwise.

Server Phones a Friend

• Assume an existing Reverse Connection.
• Client disconnects from the server, specifying a host address, port, and time interval for reconnect attempts. The server continues running, and periodically tries to reconnect to the given host.
• User gives a copy of the original session certificate, client certificate, and client key to a friend.
• Friend launches a client, enabling reverse connections, and specifying the paths to the original session certificate, client certificate, and client key.
• Client begins waiting for connections using an SSL socket.
• Server eventually connects to the client using SSL. Within the SSL layer both client and server validate that the other host's certificate was signed by the original session certificate, and refuse to connect otherwise.

Alternate:

• User generates a new private key and corresponding "client" certificate, signed by the "session" certificate, and passes them to their friend.
• The user may generate as many new keys and client certificates as they like, all signed by the original "session" certificate, for use by friends.