When a message is sent across a connection, normally a TLS/SSL connection is used to encrypt the data in the message. To create this connection, a TLS Handshake occurs. Inside of that Handshake, the client and server exchange available cipher suites to ensure they use the same ciphers during the TLS Handshake.
A cipher suite provides instructions on how to secure the TLS/SSL connection by providing information on which ciphers are used by the client or server to create keys, authenticate users, etc. Cipher suites must be traded between the client and server to ensure the ciphers used in the TLS Handshake match and the client and server can understand each other.
How does a TLS handshake work?
A TLS Handshake is the process undertaken between a client and server to create a secure connection and encrypt the data sent through that connection. A TLS Handshake contains the following steps:
The client hello stage involves the client sending a request to the server to communicate. The TLS version, cipher suites supported, and a string of random bytes known as the “client random” are included in the hello.
In the server hello, the server acknowledges the client hello and ensures it is using a TLS version that is compatible with the client TLS version. The server also selects a compatible cipher suite from the ones offered by the client, and sends its certificate, the server random (similar to the client random), and the public key to the client.
The validity of the server’s certificate is then checked by the client through the certificate authority. The certificate authority, or CA, is a highly trusted entity given the responsibility of signing and generating digital certificates.
In this stage, the client encrypts a random string of bytes, called the “Pre-Master String”, with the server’s public key and sends it back to the server. This ensures that only the server can decrypt the key with its own private key, which adds an extra layer of security to the process.
Session Key Creation
The server then decrypts the pre-master key, and both the client and server create session keys from the client random, the server random, and the premaster string.
Finally, the client and server send each other messages saying they have finished creating their keys, and they compare keys with each other. If the session keys match, the TLS Handshake is completed, and the session keys are used to encrypt and decrypt any data sent between the server and client.
Now that we understand how a TLS Handshake works, we can focus on cipher suites in a TLS Handshake specifically.
Cipher suites contain four different components:
Key Exchange Algorithm
The information exchange process requires a secure connection to send unencrypted data, or a key shared between the client and server. This key will be used by the client to encrypt data and the server to decrypt that data. Since one key is used for both encryption and decryption, symmetric encryption is being used. To share that key, an algorithm, called the key exchange algorithm, was created to encrypt the symmetric encryption key in transfer. This ensures the integrity of the data as well as the security of the symmetric encrypting key. The key exchange algorithm is an encryption algorithm shared between client and server so each side of the connection can decrypt and use the symmetric encryption key. RSA, DH, ECDH and ECDHE are all examples of key exchange algorithms.
This algorithm is a way of ensuring the identity of the sender. Usually a password and username are used in the process of authenticating the client. The most common authentication algorithms are RSA, DSA and ECDSA.
Bulk Data Encryption Algorithm
The bulk data encryption algorithm is the algorithm used to encrypt the central data of the message. As the main part of the message is what attackers are attempting to steal or modify, the algorithm used here should be extremely secure. AES, 3DES and CAMELLA are the most common bulk data encryption algorithms used by cipher suites.
Message Authentication Code (MAC) Algorithm
The MAC is a section of information sent along to authenticate the client. The MAC algorithm is the algorithm used to encrypt the MAC. The server compares the MAC received and the MAC they calculate to ensure they match. Normally a Cyclic Redundancy Check algorithm, or CRC, is used with a MAC to check for damaged portions of the message, but a CRC cannot protect against intentional changes to the MAC. If an attacker obtains the message, changes the MAC, and calculates a new checksum, then the server will never know that the MAC was changed. SHA and MD5 are the most commonly used MAC algorithms.
An example of a version 1.2 cipher suite naming is TLS_DHE_RSA_AES256_SHA256. The first portion, TLS, specifies what the cipher suite is used for. TLS is the most common reason used for cipher suites. The second algorithm name, DHE, is the key exchange algorithm used. RSA is the authentication algorithm, AES256 is the bulk data encryption algorithm, and SHA256 is the MAC algorithm. Version 1.2 cipher suite names are short, but other cipher suite versions support different algorithms and are even shorter. The most widely used cipher suite version is version 1.2, even though version 1.3 already exists. The reason for using an older version over a newer version is the amount of options offered by each version. Version 1.2 cipher suites offer 37 ciphers and contain 4 ciphers, not including the reason the cipher suite is being used. Version 1.3, on the other hand, only offers 5 ciphers and includes 2 algorithms in its naming. Version 1.2 also offers more secure algorithms compared to 1.3. The naming of the cipher suite, and the amount of ciphers offered in a cipher suite in version 1.3 shorten the TLS Handshake significantly, however. Version 1.3 naming looks like this: TLS_ AES_256_GCM_SHA384. The fewer ciphers used, and the shorter the name, the faster the TLS Handshake.
Cipher suites are an integral part to the TLS Handshake, telling the client and server how to encrypt their information for the other to understand. The TLS Handshake, which connects a client and server in a secure connection, is used every day to connect to websites, so ensuring it is the most secure it can be is extremely important. Cipher suites are just one way to ensure safe and trusted connections. Code signing, proper certificate management, and secure SSH keys are all other secure connection methods that must also be implemented properly, to ensure the most secure connection to servers.
Digital certificates are used across the Internet to authenticate users exchanging data with one another. Since every legitimate website uses a certificate, certificate management is extremely important. If a certificate were to be stolen and misused, an attacker could pose as another, more legitimate, source and infect a user with malware via their website. The expiration of a certificate of a certificate can result in an outage, causing an organization to lose out on potential customers. These are just a few reasons to learn more about certificate management.
What is Certificate Management?
Certificate management is the process of monitoring, processing, and executing every process in a certificate’s lifecycle. Certificate management is responsible for issuing, renewing, and deploying certificates to endpoints (servers, appliances, devices, etc.) so that network services are uninterrupted. Certificate management should also automate tasks (issuing, renewal, and so on), as well as provide real time status of the infrastructure of the network.
Certificate management helps manage the network and prevent interruptions and downtime, while providing a detailed monitoring of the whole infrastructure. Good certificate management plans should be able to handle any network, even ones with thousands of devices. If a certificate expires or is misconfigured, catastrophic outages all over the network may occur.
What is a Digital Certificate?
Any discussion of certificate management would be incomplete without explaining what a digital certificate is. A certificate, also known as an SSL/TLS certificate, is a digital identifier for users, devices, and other endpoints within a network. Certificates are linked with a public/private key pair and verify that the public key, which is matched with the valid certificate, can be trusted. The main job of a certificate is to ensure that data sent across a connection between a user and a server is kept private. The certificates does this by encrypting and decrypting data as it is sent across the connection. This is achieved through something called an SSL/TLS Handshake.
A TLS Handshake is executed as follows:
1. Client Hello:The client hello occurs when the client sends a request to the server to communicate. The TLS version, the cipher suites supported, and a string of random bytes known as the “client random” are included in the hello.
2. Server Hello: In the server hello, the server acknowledges the client hello. It then ensures it is using a TLS version that is compatible with the client TLS version, selects a compatible cipher suite from the ones offered by the client, and sends its certificate, the server random (similar to the client random), and the public key to the client.
3.Certificate Validation: The validity of the server’s certificate is first checked by the client through the certificate authority. The certificate authority, or CA, is a highly trusted entity given the responsibility of signing and generating digital certificates.
4. Pre-Master String: The client then encrypts a random string of bytes, called the “Pre-Master String” with the server’s public key and sends it back to the server. This ensures that only the server can decrypt the key with its own private key, acting as another level of security.
5. Session Key Creation: The server decrypts the pre-master key, and then both the client and server create session keys from the client random, the server random, and the premaster string.
6. Finished Messaging: The client and server then send each other messages saying they have finished creating their keys, and they compare keys with each other. If the session keys match, the TLS Handshake is completed, and the session keys are used to encrypt and decrypt any data sent between the server and client.
Once created, certificates can be used for authentication of servers, clients, or other devices. Certificates are considered valid for a certain time period, and expire after that time frame. Certificates follow a constant lifecycle which include phases such as creation, renewal, suspension, expiration, and more. If certificates are left to expire, then the certificate holder will no longer be trusted, resulting in a loss of service for the website or device being used. To receive a certificate, a user or website must first go through a certificate authority or sign one themselves.
Certificates can be generated through either a trusted certificate authority or by signing a certificate themselves. Certificate authorities, or CAs, generate certificates for users to be used for TLS/SSL authentication. To ensure a certificate authority can be trusted, the chain of trust of the CA can be followed back to the source CA. A chain of trust is a chain of certificates published by trusted CAs, leading all the way back to the Root CA. To start the process of acquiring a digital certificate, the requestor must send out a Certificate Signing Request (CSR) to the CA. The CSR must have the public key of a key pair created by the requestor, along with information to confirm the identity of the requestor, such as a social security number or driver’s license. Once the requestors identity has been confirmed, the certificate is signed and returned by the CA and can be used for identification of the requestor.
The other option to get a certificate is to create one yourself using the same information, and then to self-sign it. This is used less often, because the identity of the signer cannot be verified with other trusted CAs, thus rendering the self-signed certificate suspicious. Due to this, many will not accept a self-signed certificate, so using a CA to create a certificate is the suggested method.
There are several distinct stages to the certificate lifecycle, which are shown below.
Discovery: Discovery is the first stage of the certificate lifecycle. In the discovery phase, the network is scanned for missing, expired, or unusable certificates. This phase also ensures any certificates already in place have been deployed properly. Certificates with vulnerabilities and other weaknesses can also be detected and fixed or replaced. The different certificates are commonly inventoried together in this phase to allow for tracking of certificate statuses, or grouping of related certificate types.
Creation/Purchasing: In this stage the CA creates the certificate itself, or the user purchases a certificate from a trusted CA. The key pair for the certificate is created and the public key, CSR, and personally identifiable information are sent to the CA for certificate creation. If an organization or user does not have or does not wish to create a chain of trusted CAs, a certificate is purchased instead of being created.
Installation: This stage deals with the distribution and installation of the certificate in its proper place. All aspects of the certificate’s configuration are checked in the installation phase, including the key pairs, the cipher suites, and the digital signature. The certificate is then installed onto the appropriate endpoint it was created for, and begins authentication of that endpoint.
Storing: One of the most important stages of the certificate lifecycle is the storing phase. Certificates must be accessible, but not reusable by attackers, thus they must be kept in a secure and centralized location. The storing phase can also inventory the certificates into groups, if inventorying was not done in the discovery phase.
Monitoring: This is the longest phase, where the certificates are monitored throughout the duration of their expiration period. Once the expiration date is reached, or sometimes right before, certain certificate management systems will automatically renew certificates. If automatic certificate management systems are not being used, then a system administrator will need to monitor the network’s certificates and renew, revoke, or replace any certificate that reaches its expiration date.
There are benefits to both manual and automatic monitoring, which will be discussed in-depth in the next section, but there are two important benefits which stand above the rest. The biggest benefit of manual monitoring is that if an unexpected issue occurs, then the monitor can react in real time to the problem, whereas an automatic system will not know what to do. On the other hand, an automatic monitor’s biggest benefit is that certificate renewals, revocations, etc. will not be forgotten, which can occur if a human is monitoring certificates for years.
Renewal: The renewal process of certificates begins once the validity of the certificate has run out. Once the user or automated systems decide to renew the certificate, a CSR is resent to the original issuing CA to get the certificate renewed. The process occurs as it did with originally creating the certificate, but much more quickly.
Revocation: If the issuing CA has be decommissioned, a certificate is being misused, or for a host of other reasons, then a certificate can be revoked. Once revoked, the certificate is placed on a Certificate Revocation List, or CRL, if a CRL is in use. A CRL is a list of certificates revoked by the CA that should no longer be trusted. If an Issuing CA’s certificate is on a CRL, then that CA cannot be used in a chain of trust for other CAs or certificates. A downside to using CRLs is that revoked certificates are only published periodically, not every time a certificate is revoked. This issue means a user could renew their certificate with their issuing CA, even though a few hours ago their certificate was revoked for illegitimate usage.
Replacement: If a CA’s certificate is revoked or if the certificate owner wishes to move from paid certificates to their own Public Key Infrastructure, then the replacement phase occurs. This occurs less often, as it is easier to just renew a certificate with the original issuing CA.
The certificate lifecycle is not set in stone. Different organizations will have different stages, combine stages, or leave out entire stages entirely. As long as the certificates are discovered, created, stored, monitored, and renewed, then that is considered a certificate lifecycle.
Manual vs Automated Infrastructure
One of the most important parts of a company’s data security policy is the certificate management infrastructure put into place within the organization. A manual infrastructure involves having an employee create a spreadsheet to keep track of validity periods, policies, revocations, and configuration data of all the certificates within the organization. This method will work with a smaller company with an infrastructure only dealing with a few certificates, but many larger companies can have thousands upon thousands of certificates, making manual infrastructures too complicated. The other option is to create an automated certificate lifecycle infrastructure, which is the more common method. Below is a table highlighting the differences between manual and automated certificate management infrastructures.
Handled via a spreadsheet and a user keeping track of all the certificates within the organization
Streamlined and handled automatically; Certificates renewed/replaced/revoked as soon as necessary
Costs many man hours
Less cost and no man hours needed
Must be constantly kept track of by the employee in charge to ensure certificates do not expire
Is constantly watched by the software set up in the infrastructure, allowing for quick renewal or replacement of certificates
Easy and quick to implement; Only a spreadsheet is required
The software must be implemented correctly, or certificates will not be monitored correctly
One of the most important reasons to have a strong, automated certificate management system is if you have your own Public Key Infrastructure (PKI). A PKI is an infrastructure created to authenticate users based on digital certificates. PKIs can encrypt communications as well. The most common PKI is TLS/SSL, which uses both symmetric and asymmetric encryption in securing connections between two users. The core trust of a PKI comes from the certificates traded between the two sides of the connection. Most PKIs use a two layer architecture, which includes a Root CA and an Issuing CA.
Root CA is a certificate authority that is kept offline and creates a certificate for the online Issuing CA. This creates a chain of trust with all certificates issued by the Issuing CA, as the Root CA is kept offline so it is therefore secure from malicious intent. Issuing CAs distribute certificates for end users and devices. The less commonly used three tier architecture for a PKI includes an Intermediate CA between the Root and Issuing CA, which act as a go between for the Root and Issuing CA. The reason automated certificate management is mainly used by PKIs is because it is more secure to create a PKI correctly once and then let the automated services keep the certificates up to date. This cuts down on the cost to the company, the man hours required to keep the PKI running, and human error. Since so many organizations are creating their own PKI, proper certificate management is key to any company’s security plan.
Another reason that so much importance is put onto certificate management is the need for every device and user that is connected to the Internet to have a digital certificate. Whenever a user or a device connects to a website, the authenticity of their digital certificate is checked, along with the certificate of the website. By having a strong chain of trust and a valid certificate, you can go anywhere on the Internet. However, a certificate is invalid or expired, if the user or device that certificate belongs to cannot go to most websites, as a secure connection cannot be established. The same holds true for website certificates. If their digital certificate is invalid, then users will not or cannot use that website, for fear of getting malware or viruses on their device.
One more reason to ensure strong certificate management is so that breaches do not occur in an organization. If a certificate were to be allowed into a network, even though it has untrusted CAs in its chain of trust, then the owner of that certificate could steal sensitive data or otherwise misuse company data for malicious purposes. Also, if the certificates are not stored properly, then an attacker could steal that certificate and pose as a legitimate user, while stealing, changing, or deleting sensitive data.
Other Certificate Uses
There are a number of other uses for digital certificates, which are listed below.
Point of Sales System
Internet of Things Devices
SSH Key Management
Customer Service Websites
Certificate Management with Encryption Consulting
Encryption Consulting provides a variety of services relating to certificate management. We offer PKI assessments,CP/CPS development for PKIs, and PKI Design and Implementation services. Our PKI assessment will assess the current certificate management practices of our customer and help with the development of a strategy and roadmap for certificate management. Our CP/CPS development and PKI design and implementation services provide assistance in creating and implementing all the stages of a PKI, from on-premises to the cloud. We can provide our services via video or in person, at the customer’s behest. We also provide services to help develop and implement certificate management systems into new and current infrastructure.