Secure Sockets Layer (SSL) Interview Questions and Answers: A Comprehensive Guide

Ph. D. DevOps, Deep Learning, Visualization, Seoul National University, Carnegie Mellon, UC Berkeley, and Golden Gate Avenue in San Francisco to name a few.

DevOps / Sys Admin Q & A

Ph. D. DevOps, Deep Learning, Visualization, Seoul National University, Carnegie Mellon, UC Berkeley, and Golden Gate Avenue in San Francisco to name a few.

Sponsor Open Source development activities and free contents for everyone.

DevOps / Sys Admin Q & A #11 : SSH & SSL(TLS) bogotobogo.com site search: Prelude

We need to know about two important ideas in order to get the most out of this post: public key cryptography and signature

• Public key cryptography: Bob’s private key is the only way to decrypt a message that was encrypted with his public key. Bob can use his private key to decrypt a message from a remote server that was encrypted with his public key.
• With Alice’s public key, anyone can check that a message signature is really from Alice (made with her private key) and not from someone else. => Our browser can confirm that the SSL certificate sent by Alice’s server, which was issued by the CA, really comes from her server. This is because the server sends both its certs and public key when a page request comes in. Anyone who knows Alice’s public key can confirm that a signature could only have been made by someone who knows her private key.

Introduction – Asymmetric (Public) key

One effective way of securing SSH access to a remote server is to use a public/private key pair. This means that we put a public key on the server and a private key on our local workstation. This lets both sides trust each other and send 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.

There is a type of encryption called symmetrical (shared key) encryption where one key can be used to both encrypt and decrypt messages sent and received by the other party. 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. Its job is to negotiate the secure connection, make sure the other party is who they say they are, and start the right environment if the credentials are accepted.

The client starts the initial TCP handshake with the server, negotiates the secure connection, checks that the server’s identity matches what was previously recorded, and gives the server credentials to prove its identity. SSH Workflow.

The SSH connection between the client and the server is established in three stages:

• Verification of the server by the client.
• making a session key to protect the messages sent between the server and the client
• Client authentication.

Lets look into the three stages one by one.

• The client checks out the server: the client starts an SSH connection Server listens to SSHs default port 22. At this stage, the server identity is verified. When a client connects to a server for the first time, the server asks the client to manually verify the server: $ ssh -i bogotobogo pem ubuntu@3. 236. 66. 255 The authenticity of host 3. 236. 66. 255 (3. 236. 66. 255) cant be established. ECDSA key fingerprint is SHA256:kPVPFoAzH927+HMenDk81UFRMPNY2/KAYYvVFN/dTi8. Are you sure you want to keep connecting (yes/no)? yes Warning: Added permanently 3 236. 66. 255 (ECDSA) to the list of known hosts. Welcome to Ubuntu 18. 04. 4 LTS (GNU/Linux 5. 3. 0-1023-aws x86_64) . ubuntu@ip-172-31-94-245:~$ ubuntu@ip-172-31-94-245:~$ cat ~/. ssh/authorized_keys ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCXQumwl. The server will be added to ~/ once it has been checked out. ssh/known_hosts file on the client side. When the client tries to connect to the server again after the first time, the information stored in the ~/ ssh/known_hosts file: $ cat ~/. ssh/known_hosts . 100. 26. 243. 180 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBOLSFx0UX5sWlpXaf/4VBxyWYaiovjbJq2nscrBIUngJjz3gwtummz1X01Yjn6DIJEm+Ak+I4yEn3sJHhVGV5eg= . If we take out the server line from the ~/ ssh/known_hosts file, we need to repeat step 1.
• Making a session key to encrypt the messages sent between the server and the client: Once the server has been verified, both sides agree on a session key, which is a shared symmetric key generated by the Diffie-Hellman algorithm. Image: Diffie–Hellman key exchange This session key will be used to protect the whole session.
• Client authentication: After setting up symmetric encryption, the next step is to make sure the client is an actual person. To put it simply, the steps are: Make a key pair with ssh-keygen Give the server the public key with ssh-copy-id utility. The private key stays with the user. The server stores the public key as ~/. ssh/authorized_keys. The client can’t connect if the server doesn’t have the public key. For example: $ ssh -i bogotobogo pem ubuntu@3. 236. 66. 255 ubuntu@3. 236. 66. 255: Permission denied (publickey). After that, whenever the server needs to verify, it will ask the client to show that it has the private key that matches the public key. The server actually comes up with a random number, encrypts it with the public key, and sends the message that way. Client proves it has the private key. How do you prove it? If the client has the right private key, it can decrypt the message and get the server’s random number. The client takes the shared session key and the random number it got and figures out the MD5 hash of this value. After receiving the encrypted number message, the client sends this MD5 hash back to the server. To figure out the MD5 value on its own, the server uses the shared session key and the first number it sent to the client. The server checks its own answer against the one the client sent back. If these two values match, the client is authenticated. Here is a sample ssh with verbose option: ~/. ssh $ ssh -v -i bogotobogo. pem ubuntu@3. 236. 66. 255 OpenSSH_7. 6p1, LibreSSL 2. 6. 2 debug1: Reading settings from /etc/ssh/ssh_config debug1: Read options for * from /etc/ssh/ssh_config line 48 debug1: Connecting to 3 236. 66. 255 port 22. debug1: Connection established. There is no such file or directory as key_load_public in the debug1 log. The identity file is bogotobogo. There is no such file or directory with the name “pem type -1” in the debug1 log. The identity file is also missing. pem-cert type -1 debug1: Local version string SSH-2. 0-OpenSSH_7. 6 debug1: Remote protocol version 2. 0, remote software version OpenSSH_7. 6p1 Ubuntu-4ubuntu0. 3 debug1: match: OpenSSH_7. 6p1 Ubuntu-4ubuntu0. 3 pat OpenSSH* compat 0x04000000 debug1: Authenticating to 3. 236. 66. Ubuntu 255:22 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: curve25519-sha256 debug1: kex: host key algorithm: ecdsa-sha2-nistp256 debug1: kex: server->client cipher: chacha20-poly1305@openssh com MAC: compression: none debug1: kex: client->server cipher: chacha20-poly1305@openssh. This is the MAC address of the host: com MAC: HMenDk81UFRMPNY2/KAYYvVFN/dTi8 debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ecdsa-sha2-nistp256 SHA256:kPVPFoAzH927 236. 66. 255 is known and matches the ECDSA host key. debug1: Found key in /Users/kihyuckhong/. debug1: expecting SSH2_MSG_NEWKEYS debug1: received SSH2_MSG_NEWKEYS debug1: rekey after 134217728 blocks debug1: received SSH2_MSG_EXT_INFO debug1: kex_input_ext_info: server-sig-algs= debug1: received SSH2_MSG_SERVICE_ACCEPT debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Trying private key: bogotobogo pem debug1: Authentication succeeded (publickey). Authenticated to 3. 236. 66. 255 ([3. 236. 66. 255]:22). debug1: channel 0: new [client-session] debug1: Requesting no-more-sessions@openssh. com debug1: Entering interactive session. debug1: pledge: network debug1: client_input_global_request: rtype hostkeys-00@openssh. com want_reply 0 debug1: Sending environment. debug1: Sending env LANG = en_US. UTF-8 Welcome to Ubuntu 18. 04. 4 LTS (GNU/Linux 5. 3. 0-1023-aws x86_64) . ubuntu@ip-172-31-94-245:~$ .

How SSL works

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), a small change to SSLv3 that was made weaker by BEAST (2011) and Lucky 13 (2013).
• TLS 1. 1 (SSL 3. 2) (2006), small change; Lucky 13 (2013) and RC4 (2013, 2015) made it less strong.
• TLS 1. 2 (SSL 3. 3) (2008), better hashes and AEAD mode; only AEAD mode ciphers are safe.
• TLS 1. 3 (2018), optimized version of TLS 1. Two trips are needed with TLS 1, but only one trip is needed with TLS 2. 2. No more RSA but using Diffie-Hellman.

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! Your browser does not support the video tag. SSL-Handshake.

Key concepts:

• Any message that is encrypted with Bob’s public key can only be decrypted with Bob’s private key. This means that Bob can use his private key to decrypt a message from a remote server as long as the message was encrypted with his public key.
• Digital cert with signature: Anyone with Alice’s public key can confirm that a message signature is from Alice (made with her private key) and not someone else. This means that our browser can confirm that the SSL certificate sent by Alice’s server was issued by the CA and is actually from her server. This is because when a client requests a page, the server sends the client both its certificates and public key. Why digital certificate? .

After setting up a TCP/IP link between the client and the server, the client will send the requests to the destination IP on port 443 (the default TLS/SSL port). The control is now transferred to the SSL Protocol in the application layer.

Keep in mind that even though the client has the IP

Basically, 3 keys are used to set up the SSL connection: the public, private, and session keys.

It takes a lot of processing power to encrypt and decrypt with a private and public key, so they are only used during the SSL Handshake to make a symmetric session key. After the secure connection is made, the symmetric session key is used to encrypt all transmitted data.

The SSL transaction has two phases:

• SSL Handshake (the key exchange)
• SSL data transfer

Pic. credit : SSL Handshake and HTTPS Bindings on IIS

Here are the steps of SSL/TLS handshake:

• The client makes and sends a TLS packet called CLIENT HELLO. It has the SSL/TLS Protocol version, a list of Cipher Suites (for encryption), and a string of random bytes called “client random.” ” .
• The server replies to the client with SERVER HELLO, which includes the SSL/TLS Protocol version, one of the cipher suites from the client’s list (whichever is the safest), the server’s certificate (with its public key), and “server random,” which is another random string of bytes that the server creates.
• The Client uses the SERVER HELLO to perform SERVER AUTHENTICATION.
• The client uses the server’s data to create a session pre-master secret. It then encrypts this secret with the server’s public key, which can be found in the server’s certificate, and sends the encrypted pre-master secret to the server. (asymmetric key).
• The server decrypts the pre-master secret with its private key. It then creates a master secret by going through a series of steps that the client also goes through, starting with the same pre-master secret. The master secret is used by both the client and the server to create session keys. These are symmetric keys that are used to encrypt and decrypt information sent over SSL and to check that the information is still valid (that is, to see if it has changed between when it was sent and when it was received over SSL).
• The CUSTOMER After that, it sends a separate, encrypted message saying that its part of the handshake is over. The SSL Handshake is done.
• From now on, the Client sends the encrypted HTTP Request packet to the Server. The symmetric key is used by the server to decrypt the request. It then makes a response, encrypts it, and sends it back to the client. This continues normally for the entire session of secure communication.

To sum up, the server sends its public key, and the client and server agree on a secret that they can both use to encrypt the message. So, all the messages sent between the visitor and the server are encrypted with a symmetric key, which means that both the visitor and the server know the key.

Essentially, the first term is the Key Exchange, an algorithm that the two parties use to exchange keys. In this case, its based on the Diffie-Hellman algorithm, specifically, Elliptic-Curve Diffie–Hellman (ECDHE).

The second term is what type of key is in our Certificate. So every certificate has a public key of a certain type, Public Key Infrastructure (PKI) certifacate. In this case its RSA.

The third piece is our Transport Cipher, the encryption algorithm used to encrypt all the data. There are many factors that affect this, but the safest cipher is AES with Galois/Counter Mode (AES‑GCM). This is a pretty cheap and solid cipher to use.

The last one is Integrity with Secure Hash Algorithms (SHA) with one of SHA-2 family. The SHA384 produces the 384 bit digest of a message. There is a cache that goes with messages to make sure they haven’t been changed. If the message is encrypted and has integrity, we can move on from there. Digital Signature.

Digital signatures, like handwritten signatures, are unique to each signer. Digital signature uses Public Key Infrastructure (PKI).

A digital signature on a document is usually just a hash of the document that has been encrypted with the private key of the person giving the signature. If the signer’s public key can be used to decrypt this signature, then we know that this signer made it since they are the only one who can see the private key.

When someone electronically signs a document with their private key, a mathematical algorithm applies the document to a hash and encrypts the data. The resulting encrypted data is the digital signature. The signature is also marked with the time that the document was signed. If the document changes after signing, the digital signature is invalidated.

Picture from What are digital signatures?

Here is a sample case:

• Alice clicks sign a file.
• It is Alice’s computer that figures out the hash (the message is sent to a well-known mathematical function that turns it into a hash).
• To make the digital signature, Alice’s private key is used to encrypt the hash.
• Send the first message and its digital signature to Bob.
• Bob receives the signed message. There is a note that says it has been signed, so his app knows what to do to check it.
• Bobs computer decrypts the Digital Signature using Alices Public Key.
• Bobs computer also calculates the hash of the original message.
• The computer at Bob’s checks the hashes it made from the message it received against the hash it got from Alice’s message after it was decrypted.

CSR?

Steps to Request and Install SSL Certificate:

• Generate a CSR and key pair locally on our server. The key pair has a public key and a private key. The public key is embedded in * $ openssl req -new -newkey rsa:2048 -nodes -keyout bogo-privatekey key -out bogo. csr Generating a 2048 bit RSA private key . +++ . +++ writing new private key to bogo-privatekey. key . $ ls bogo-privatekey. key bogo. csr $ cat bogo-privatekey. key —–BEGIN PRIVATE KEY—– MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDU5OXoQLIjCKIM . tggWYqo+TH2fRTop5XSwUnLozDxvhmxUdlhBTDK4IYVV6XXRl8tWxwUgf4z7AerK pH4X+Yh23ug9/gRAFG5npgk= —–END PRIVATE KEY—– $ cat bogo. csr —–BEGIN CERTIFICATE REQUEST—– MIICzDCCAbQCAQAwgYYxCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJDQTERMA8GA1UE . The following OpenSSL command will easily decode the CSR on our server: $ openssl req -in bogo Please find the certificate request data below. The version number is 0 (0x0), and the subject lines are “C=US, ST=CA, L=San Jose, O=bogotobogo, CN=www.” bogotobogo. com/emailAddress=kihyuck. hong@gmail. com Subject: Public Key Information: Public Key Algorithm: RSAEncryption Public-Key: (2048 bit) Modulus: 00:d4:e4:e5:e8:40:b2:23:08:a2:0c:21:3e:ee:ba: a0:17:af:a1:7c:10:51:4a:41:c0:c1:0d:84:1a:0b: This is the message that was sent: 8a:a9:34:cf:46:ff:2d:40:8a:69:f3:41:e5:cc:9c: 6c:78:f1:92:30:83:44:f7:c8:b7:4c:4e:73:00:c3: b7:d3 Attributes: a0:00 Signature Algorithm: sha256WithRSAEncryption 49:06:2f:38:67:87:a8:c3:23:96:92:a1:49:9c:65:8b:02:82: 8f:f7:9a:1f:63:ac:b1:64:17:ae:1b:55:33:8e:7a:32:78:92: The timeout for this request was 7200 seconds, and the return code was 0 (ok). The start time was 1625171760, and the timeout was 7200 seconds.
• Send the CSR and public key to a CA. They will check our legal identity and see if we own the domain name we put in our application. Our organization is checked by the Certificate Authority to see if it is registered at the address given in the CSR and to see if the domain exists.
• After being checked, the company gets a copy of their SSL certificate with their business information and the public key. The organization can now install the certificate on their server.
• The certificate from one CA is linked to a “trusted root” certificate from another CA. Root certificates are built into every browser and linked to certificates that were issued specifically for each user to make an HTTPS connection.

Certificate chains (Building Trusts, SSL chain of Trusts) – Root Cert, Intermediate Certificate, Server Certificate

A certificate chain is a logical list of certificates that includes an SSL Certificate and Certificate Authority (CA) Certificates. It lets the receiver check that the sender and all of the CAs are reliable. The SSL certificate starts the chain or path, and each certificate in the chain is signed by the entity that is named in the certificate before it.

This is the name for any certificate that comes after the Root Certificate but before the SSL Certificate. The Intermediate Certificate is the signer/issuer of the SSL Certificate. The Root CA Certificate is the signer/issuer of the Intermediate Certificate. Some browsers, mobile devices, apps, and other things may not work if the Intermediate Certificate is not installed on the server where the SSL certificate is installed. from trusting the SSL certificate. To make sure that all clients can use the SSL certificate, the Intermediate Certificate must be put in place.

The picture below shows a certification path that starts with the certificate owner and ends with the Root CA. This is where the chain of trust starts:

Picture from How certificate chains work

List of Certificate Authorities (CA):

The chain terminates with a Root CA Certificate. The Root CA Certificate is always signed by the CA itself. The signatures of all certificates in the chain must be verified up to the Root CA Certificate.

We can see the Root CA Certificate was self-signed:

Here is a sample of a cert list on a Mac:

Getting a Free Certificate – Option 1

Lets Encrypt is a non-profit CA that issues certificate completely free of charge. Moreover, they use the Automatic Certificate Management Environment (ACME) protocol, which automates the identity verification and certificate issuing process.

We can get a certificate from Lets Encrypt via Certbot ACME client. Getting a Free Certificate – Option 2

Lets 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:

Well use 1_1lnx. com_bundle. crt which is for Nginx. It is a bundle file that contains root and intermediate certificates. nginx with SSL/TLS.

To see how we use NGINX with SSL, please visit DevOps / Sys admin Q & A #26 : NGINX SSL, Caching, and Session. TLS.

It’s not easy to decide whether the TLS handshake should happen with a proxy (termiantion/offloading) or the real backend server (passthrough). Each has pros and cons.

When proxy SSL passthrough is set up, the load balancer does not need to have an SSL certificate installed. Instead of the load balancer, SSL certificates are put on the backend server, which is in charge of the SSL connection.

From servers perspective, SSL passthrough is more costly because it uses more CPU for encryption. Proxy SSL passthrough doesn’t look at traffic or join SSL sessions on network devices before they get to the server; it only sends encrypted data. SSL passthrough is better suited for smaller deployments.

SSL passthrough passes HTTPS traffic to a backend server without decrypting the traffic on the load balancer. The data goes through fully encrypted, and the Proxy only sees the socket (ip/port, layer 4) and doesn’t do anything on layer 7.

SSL termination (or offloading), decrypts all HTTPS traffic on the load balancer. Layer 7 actions are carried out and the data proceeds to the backend server as plain HTTP traffic. SSL offloading allows data to be inspected as it passes between the load balancer and server. It also reduces CPU demand on an application server by decrypting data in advance. But attacks can happen with SSL offloading because the data goes from the load balancer to the application server over HTTP without being encrypted. Checking connnections with openssl.

My domain, sub. mydomain. com is running a syslog server behind an AWS NLB. A TLS cert from digicert CA is installed on the LB via ACM and TLS terminates there. Then regular TCP communications are setup between the NLB and backend server. The server is listening on port 6514.

openssl comes with a client tool that we can use to connect to a secure server. The tool works like telnet or nc in that it handles encryption and gives us full control over the protocol that comes next.

The first few lines of the output will show information about the server certificate. The next section will list all the certificates that the server sent in the order that they were received. For each certificate, the first line will show the subject and the second line will show the issuer information.

The next item in the output is the server certificate. References

SSL Certificates and TLS Handshake | Computer. Networking Tutorial | DevOps/SRE Interview Questions

FAQ

What is SSL Secure Socket Layer used for?

What is an SSL certificate for interview questions?

What is the difference between Secure Sockets Layer SSL and TLS?

What are the problems with Secure Socket Layer?

What are Secure Sockets Layer (SSL) interview questions & answers?

Explore our comprehensive guide on Secure Sockets Layer (SSL) interview questions and answers. Gain insights into key concepts and prepare effectively for your next interview in the field of cybersecurity. Secure Sockets Layer (SSL) is a standard security technology that’s integral to the safe transmission of data over the internet.

What questions are asked in an SSL interview?

SSL, short for Secure Socket Layer, is solely responsible for protecting data during transfer from source to destination. Here is a list of SSL interview questions and answers generally asked in an interview. Q1. What are SSL/TLS certificates? Q2. Explain how SSL/TLS works. Q3. What is asymmetric and symmetric encryption? Q4.

What is Secure Sockets Layer (SSL)?

Secure Sockets Layer (SSL) is a standard security technology that’s integral to the safe transmission of data over the internet. It establishes an encrypted link between a web server and a browser, ensuring that all data passed between them remains private and secure.

What are the most common SSL handshake interview questions?

Here are 20 commonly asked SSL Handshake interview questions and answers to prepare you for your interview: 1. Can you explain what a SSL Handshake is? A SSL handshake is the process that occurs when two devices first establish a secure connection.