DevOps / Sys Admin Q & A #11 : SSH & SSL
One effective way of securing SSH access to a remote server is to use a public/private key pair. This means that a public key is placed on the server and a private key is placed on our local workstation authenticating each side to the other, and passing commands and output back and forth. In short, SSH allows remote login and other network services to operate securely over an unsecured network.
Picture source : ref #4 - An unpredictable (typically large and random) number is used to begin generation of an acceptable pair of keys suitable for use by an asymmetric key algorithm.
Note: Symmetrical (shared key) encryption is a type of encryption where one key can be used to encrypt messages to the opposite party, and also to decrypt the messages received from the other participant. So, anyone who holds the key can encrypt and decrypt messages to anyone else holding the key.
The server listens on a designated port (22) for connections. It is responsible for negotiating the secure connection, authenticating the connecting party, and spawning the correct environment if the credentials are accepted.
The client is responsible for beginning the initial TCP handshake with the server, negotiating the secure connection, verifying that the server's identity matches previously recorded information, and providing credentials to authenticate.
An SSH session is established in two separate stages (SSH version 2 - ref #2):
- Negotiating encryption for the session - agree upon and establish encryption to protect future communication.
- Authenticating the user's access to the server - authenticate the user and decide whether an access to the server should be granted.
Picture source : ref #1
Once a TCP connection between our local machine and a remote server, the server provides its public host key. The client can use the public host key to check if it's the intended host.
At this point, both parties negotiate a session key using a version of something called the Diffie-Hellman algorithm. This algorithm (and its variants) make it possible for each party to combine their own private data with public data from the other system to arrive at an identical secret session key.
In the Diffie-Hellman key exchange scheme, each party generates a public/private key pair and distributes the public key. After obtaining an authentic copy of each other's public keys, Alice and Bob can compute a shared secret offline. The shared secret can be used, for instance, as the key for a symmetric cipher. - ref # 4
The session key will be used to encrypt the entire session. The public and private key pairs used for this part of the procedure are completely separate from the SSH keys used to authenticate a client to the server.
SSH key pairs are asymmetric keys, meaning that the two associated keys serve different functions.
The public key is used to encrypt data that can only be decrypted with the private key. The public key can be freely shared, because, although it can encrypt for the private key, there is no method of deriving the private key from the public key.
Picture source ref #4 - In an asymmetric key encryption scheme, anyone can encrypt messages using the public key, but only the holder of the paired private key can decrypt. Security depends on the secrecy of the private key.
The asymmetry of the keys allows the server to encrypt messages to the client using the public key. The client can then prove that it holds the private key by decrypting the message correctly.
Secure Socket Layer (SSL) also known as Transport Layer Security (TLS).
The following protocols are most commonly used:
- SSL 1.0 (not published)
- SSL 2.0 (1995)
- SSL 3.0 (1996), broken by POODLE (Nov 2014)
- TLS 1.0 (SSL 3.1) (1999), minor tweak to SSLv3, weakened by BEAST(2011) and Lucky 13(2013)
- TLS 1.1 (SSL 3.2) (2006), minor tweak, weakened by Lucky 13 (2013) and RC4(2013, 2015)
- TLS 1.2 (SSL 3.3) (2008), improved hashes and AEAD mode, only safe with AEAD mode ciphers
- TLS 1.3 (n/a) (draft)
Just watching the following video (ref. #5), we can get a high level of idea about how SSL (Secure Socket Layer) works!
No one video is complete and the following three may help us to understand SSL.
The ref.#7 is a relatively thorough document regarding the SSL handshake!
Once a TCP/IP connection has been established between the client and the server. The client will now forward the requests to the Destination IP on port 443 (Default TLS/SSL port). The control is now transferred to the SSL Protocol in the application layer.
Note that though the client has the IP & the Port information handy from TCP handshake, it still has no clue whatsoever about the hostname.
Pic. credit : SSL Handshake and HTTPS Bindings on IIS
Here are the steps of SSL/TLS handshake:
- The client creates/sends a TLS Packet called as CLIENT HELLO which contains the following details: SSL Protocol version, Session ID, list of Cipher Suites supported by the client, and list of CLIENT HELLO Extensions
- The Server responds to the client with SERVER HELLO which contains the following: SSL/TLS Protocol version, one of the cipher suites from the list of cipher suites provided by client (whichever is the most secure), Certificate of the server (including its public key), and list of SERVER HELLO Extensions.
- The Client uses the SERVER HELLO to perform SERVER AUTHENTICATION.
- The Client uses the data provided from the server to generate a pre-master secret for the session, encrypts it with the server's public key (obtained from the server's certificate), and then sends the encrypted pre-master secret to the server. (asymmetric key).
- The server uses its private key to decrypt the pre-master secret, and then performs a series of steps (which the client also performs, starting from the same pre-master secret) to generate the master secret. Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity (that is, to detect any changes in the data between the time it was sent and the time it is received over the SSL connection).
- The CLIENT & the SERVER send each other a message informing that future messages from them will be encrypted with the session keys. It then sends a separate (encrypted) message indicating that its portion of the handshake is finished. The SSL Handshake is done.
- From now on, the Client sends the actual HTTP Request packet to the Server in the encrypted form. The Server decrypts the request via the symmetric key and generates a response, encrypts it and sends it back to the client. This continues normally for the entire session of secure communication.
In summary, the server itself sends a public key, and the client and server establish a shared secret that they can use to encrypt the communication. So, all the communication between the visitor and the server is encrypted with a symmetric key, meaning both parties have the same key.
Essentially, the first term is the key exchange, an algorithm that the two parties use to exchange keys. In this case, it's based on the Diffie-Hellman algorithm.
The second term is what type of key is in our certificate. So every certificate has a public key of a certain type. In this case it's RSA.
The third piece is your transport cipher, the encryption algorithm used to encrypt all the data. There's a lot of different pieces that go into this, but AES‑GCM is the most secure cipher; this is actually something that Intel processors do at almost zero cost. So this is a pretty cheap and solid cipher to use.
The last one is integrity. Messages have a cache that goes along with them to make sure they haven't been tampered but if it's encrypted, and with integrity, we can go from there.
Let's start with https://www.startcomca.com/
Retrieve the certificate (1lnx.com.pem).
Get a complete CA bundle in a zip file by clicking the item under SSL/TLS:
Unzip will give us the following certs for several servers:
We'll use 1_1lnx.com_bundle.crt which is for Nginx. It is a bundle file that contains root and intermediate certificates.
To see how we use NGINX with SSL, please visit DevOps / Sys admin Q & A #26 : NGINX SSL, Caching, and Session.
- How To Configure SSH Key-Based Authentication on a Linux Server
- Secure Shell: How Does SSH Work
- Understanding the SSH Encryption and Connection Process
- Public-key cryptography
- SSL Certificates: Serving secure web content over HTTPS
- How To Install an SSL Certificate from a Commercial Certificate Authority
- SSL Handshake and HTTPS Bindings on IIS
- NGINX + HTTPS 101: The Basics & Getting Started
Ph.D. / Golden Gate Ave, San Francisco / Seoul National Univ / Carnegie Mellon / UC Berkeley / DevOps / Deep Learning / Visualization