Encryption Methods and Algorithms

• Symmetric Cryptography:
  • Only one key (shared key) that both encrypts and decrypts the data
  • Both ends must have this key (and keep it secret)
  • Examples: AES (AES-128/192/256), BlowFish (32 to 448bits), Twofish (128-bit), ChaCha20
• Asymmetric Cryptography (public-key encryption)
  • Examples:
    • RSA (Rivest, Shamir, and Adleman) since 1977
    • ECC (Elliptic Curve Cryptography)
    • DSA (Digital Signature Algorithm)
    • Diffie-Hellman Key Exchange (NOT used directly, but for securely establishing a shared key between two parties)

HTTPS and SSL/TLS

HTTPS uses public-key encryption to verify the identity of the server, and to exchange a shared key, and then switches to using symmetric encryption for communication using that shared key. The reason for using two different algorithms is that RSA encryption keys are large and computationally more expensive, while symmetric keys are smaller and faster to compute.
When you are configuring an HTTPS site, you will need to:

• Generate a private key (MUST be kept secret)
• Create a public key associated with the private key
• Create a signing request which contains identifying information and the public key
• Sent the signing request to a Certificate Authority (CA) to be signed by them
• The CA will provide the signed certificate file
• You provide your key and certificate file to the HTTP server to be used by the website

The SSL Handshake

• A client sends the server a “Client Hello message”.
  • SSL version number, Cipher settings, session-specific data, etc.
• The server replies with “Server Hello message”.
  • SSL version, Cipher settings, etc.
  • SSL Certificate and Server Public Key
• SSL certificate is signed using a CA private key, but the CA public key can decrypt/verify!
• The client verifies the SSL Certificate (from Certificate Authority) to verify the server identity
• Client creates a “session key”, encrypts it using the server's public key, and sends it to the server.
• Server decrypts the session key using its private key and sends an acknowledgement
• The public-private key pair is no longer used; the “session key” is used for symmetric encryption of the actual data

SSL/TLS protocols:

Please note that currently, the minimum acceptable protocol is TLS 1.2 for backward compatibility, while TLS 1.3 is recommended. For most modern applications and clients, you may disable other protocols or use TLS 1.3 exclusively. Additionally, disabling the less secure and older protocols reduces the attack surface; for example, it will prevent protocol downgrade attacks.

PKI and SSL Certificates

Terminology

• Public key infrastructure (PKI):
  • Is a set of roles, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates and manage public key encryption.
  • The goal is to provide a method of assurance for validity and authenticity of keys and certificates
• Certificate Authority (CA):
  • The authority that authenticates the identity of individuals, computers and other entities.
• Registration Authority (RA):
  • A subordinate CA that issues a certificate on behalf of the root CA for specific uses.
• SSL Certificate:
  • The Data file that includes the public key and other information
  • As of Sep 2020, SSL Certs are valid for up to 13 months from the date issued. This is enforced by major web browser vendors: Google, Microsoft, Apple, and Mozilla
    • This will be farther reduced down to 47 days starting from March 15, 2029
• Certificate Management System:
  • The system which stores, validates and revokes certificates.
• CA Store:
  • Is the list of recognized CAs that are built into browsers, operating systems, and firmware
  • You may install and manage “private CA” or other CA certificates that you choose to trust in your client software or operating systems

The Chain of Trust

There are many CAs and many more RAs. You could imagine that if every system is required to have all the CA certificates in order to be able to establish trust, it can lead to scalability problems. Chain of Trust is a security model which is used to enable scalability and ease of management. It creates a hierarchy of trust, from the root certificates down to the end-entity certificate. In short, your system can trust an entity because your system trusts the Root CA, and the Root CA trusts the RA/CA, which trusts the entity.

Certification Process

The role of CA/RA is to verify the identity of the requester and digitally sign the Public keys and publish the certificates. A certificate is signed using the CA’s private key. The verification of the identity of the requester is achieved either via software or under human supervision. SSL certificates can be issued with different levels of assurance; some require more extensive vetting, and costs are associated with the process.

Steps to get your SSL certificate signed:

• Generate a public/private key pair
• Create a CSR file (Certificate Signing Request) and send it to an RA
  • Contains the public key
  • Provide the information the CA/RA needs for verification for the type of cert being requested inside the CSR
• CA/RA will complete vetting process (Can be automated or manual)
• Once the verification is complete, the CA/RA will send the signed SSL Certificate file
  • An SSL certificate contains the public key and the CA signature that has verified the information contained, such as the server name, domain, and other verifying information.

Types of SSL certificates

There are several different. One certificate can apply to a single website or several websites, depending on the type:

• Single-domain: A single-domain SSL certificate applies to only one domain (a "domain" is the name of a website, like www.example.com).
• Wildcard: A wildcard SSL certificate applies to only one domain; however, it also includes that domain's subdomains. For example, a wildcard certificate is valid for example.com, www.example.com, blog.example.com, dev.example.com, etc.
• Multi-domain: multi-domain SSL certificates can apply to multiple unrelated domains.

SSL certificates also come with different validation levels. A validation level is like a background check, and the level changes depending on the thoroughness of the check (provided at a different cost).

• Domain Validation: This is the least-stringent level of validation, and the cheapest. All a business has to do is prove it controls the domain. Most free certs provided by entities such as Let's Encrypt and Cloudflare use an automated process (usually using the ACME protocol), simply to verify that the requesting server is reachable at the specified domain.
• Organization Validation (OV cert): The CA directly contacts the person or business requesting the certificate. These certificates are more trustworthy for users.
• Extended Validation (EV Cert): This requires a full background check of an organization before the SSL certificate can be issued. It may cost hundreds or thousands of dollars per year to maintain.

Please note that there are other types of certificates issued by trusted CAs that are not in scope for discussion here. An example is "Code Signing Certificates," which requires OV or EV level verification for developers to be able to publish software for Microsoft and Apple platforms.

Tools and Utilities

OpenSSL (Wikipedia Article)

OpenSSL is a CLI tool and libraries for all SSL activities. These tools and libraries are available for a variety of operating systems, including Linux, Unix, and Windows. It can generate keys, create a CA, generate a CSR, and sign certificates. It is also used for examining certificate files for troubleshooting or manual verification. All major operating systems and many services rely on OpenSSL. OpenSSL supports almost all new and old algorithms and processes; the code base has grown to be complex, with many options to choose from in the utilities.

OpenSSL has faced challenges in the past. Despite the project being used by many major tech companies and the internet at large, the open-source project was not adequately supported. In the past, the development and maintenance of OpenSSL was mostly done by volunteers and only two full-time employees. This led to a number of bugs and vulnerabilities over the years, and the code audits were not positive. OpenSSL is currently well supported and well founded, and the software is well maintained.

One of the biggest criticisms of OpenSSL is the sheer number of available options, which can lead to confusion and misconfigurations (see If OpenSSL were a GUI and the following image).

The extensive coverage of OpenSSL has led to other alternative SSL library implementations. The alternatives seek to reduce exposure by removing outdated or unused options and functions, and limiting algorithms to secure or modern ones. Some of these alternative implementations are open, while others are proprietary. Some examples of such efforts (with varying degrees of popularity and success) include:

• LibreSSL
  • A fork of OpenSSL, by the BSD Team, was created in response to the OpenSSL Heartbleed vulnerability in 2012
  • the codebase significantly altered to remove legacy cruft
  • Used by OpenBSD, but cannot coexist with OpenSSL, may break software (due to the same library names, but different and altered functions and output)
• Boring SSL
  • Fork of OpenSSL by Google in 2014
  • Meant to be optimized for Google's own use, and not recommended for use by 3rd parties
• Bouncy Castle
  • Written as an API for Java and later for C#
  • Maintained by the Australian registered Charity “The legion of the bouncy castle.”
• SChannel (Proprietary)
  • Microsoft Secure Channel, a proprietary implementation of SSL/TLS used in Windows OS
  • Sometimes lagging in supporting the latest standards and encryption, for example, only started supporting TLS 1.3 as of Windows 11 and Server 2022
• BSAFE
  • Proprietary, currently owned by Dell, in use mostly in enterprises and governments, where the cost of switching may be too high

Easy-RSA

Easy-RSA is a set of scripts developed by the creators of OpenVPN to simplify SSL operations. You may use OpenSSL utilities and libraries using the complex commands and options available, but using Easy-RSA will reduce the steps substantially.

• The scripts are usually stored under the/etc/openvpn/easy-rsa directory (distro dependent)
• make-cadir can be used to create a CA on your system for self-signed (snakeoil) certificates
• This CA and its certificates can be added to a local machine as a trusted source
• In Ubuntu:
  • Copy the CA certificate to the /usr/share/ca-certificates/ directory
  • dpkg-reconfigure ca-certificates and select the desired CA certificates from the list
    

Using SSL in Apache2

In the Apache2 HTTP server, an SSL module is already provided. Enable the module using a2enmod ssl, and modify the site configuration file to enable HTTPS. The most basic configurations are:

• Modify the virtual host definition to listen on port 443: virtualhost hostname:443>.
• Turn on SSL engine: SSLEngine on.
• Add paths to the private key and certificate files to be used by this site:
  • SSLCertificateFile /path/to/certificate/file.
  • SSLCertificateKeyFile /path/to/private_key/file.
• You will need to reload the server for changes to take effect.
• You will also need to provide the passphrase for the private key file to the service
  • In Ubuntu the systemd-tty-ask-password-agent --query tool