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.

Use Cases

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 by the "session" certificate.
• User generates a private key and corresponding "server" certificate, signed by the "session" certificate.
• User copies session certificate, server certificate, and server key to the server filesystem.

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.