F5 DUMP‎ > ‎

Certificates and SSL

posted 17 Jun 2016, 13:59 by Donald Ross   [ updated 25 Aug 2016, 01:32 ]
Certificates and SSL

How Does the SSL Certificate Create a Secure Connection?

When a browser attempts to access a website that is secured by SSL, the browser and the web server establish an SSL connection using a process called an “SSL Handshake” (see diagram below). Note that the SSL Handshake is invisible to the user and happens instantaneously.

Essentially, three keys are used to set up the SSL connection: the public, private, and session keys. Anything encrypted with the public key can only be decrypted with the private key, and vice versa.

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

Class 1 for individuals, intended for email.
Class 2 for organizations, for which proof of identity is required.
Class 3 for servers and software signing, for which independent verification and checking of identity and authority is done by the issuing certificate authority.
Class 4 for online business transactions between companies.
Class 5 for private organizations or governmental security.

Trust Models
For PKI to work, the capabilities of CAs must be readily available to users. The model that has been shown to this point is the simple trust model. This simple trust model may not work as PKI implementations get bigger. Conceptually, every computer user in the world would have a certificate.
However, actually accomplishing this would be extremely complex and would create enormous scaling or growth issues.
PKI was designed to allow hierarchies, bridges, and meshes of trust to be established. These trusts can be fairly granular from a control perspective. Granularity refers to the ability to manage individual resources in the CA network.
Four main types of trust models are used with PKI:
In the following sections, we will examine each of these models. We will detail how each model works and discuss its advantages and disadvantages.

In a hierarchical trust model, the intermediate CAs only trust information that is provided from the root CA. Additionally, the root CA will also trust intermediate CAs that are in their hierarchy. This allows a high level of control at all levels of the hierarchical tree. This might be the most common implementation in a large organization that wants to extend its certificate- processing capabilities. Hierarchical models allow tight control over certificate-based activities. Figure 7.16 illustrates the hierarchical trust structure. In this situation, the intermediate CAs only trust the CAs directly above them or below them.
Root CA systems can have trusts between them, as well as between intermediate and leaf CAs. A leaf CA is merely a CA that is at the very end of a CA network or chain. This structure allows you to be creative and efficient when you create hybrid systems.

In a bridge trust model, a peer-to-peer relationship exists between the root CAs. Each of the root CAs can communicate with each other, allowing cross- certification. This allows a certification process to be established between organizations or departments. Each of the intermediate CAs trusts only the CAs above and below it, but the CA structure can now be expanded without creating additional layers of CAs.
Additional flexibility and interoperability between organizations are the primary advantages of a bridge model. The lack of trustworthiness of the root CAs can be a major disadvantage. If one of the root CAs does not maintain tight internal security around its certificates, a security problem can be created. An illegitimate certificate could become available to all of the users in the bridge structure and its subordinate or intermediate CAs.
This model may be useful if you are dealing with a large geographically dispersed organization or you have two organizations that are working together. A large geographically dispersed organization could maintain a root CA at each remote location. The root CAs would have their own internal hierarchy, and users would be able to access certificates from any place in the CA structure. Figure 7.17 illustrates a bridged structure. In this example, the intermediate CAs communicate with only their respective root CA. All cross certification is handled between the two root CA systems.

The mesh model expands the concepts of the bridge model by supporting multiple paths and multiple root CAs. Each of the root CAs shown in Figure 7.18 has the ability to cross certify with the other root CAs in the mesh. This may also be referred to as a web structure. Although not shown in the illustration, each of these root CAs would also communicate with the intermediate CAs in their respective hierarchies.

This structure may be useful in a situation where several organizations must cross certify certificates. The advantage of this is that you have more flexibility when you configure the CA structures. The major disadvantage of a mesh is that each root CA must be trustworthy in order to maintain security.

A hybrid structure can use the capabilities of any or all of the structures that have been discussed in the previous sections. You can be extremely flexible when you build a hybrid trust structure.
The flexibility of this model also allows you to create hybrid environments. Figure 7.19 illustrates such a structure. Notice that in this structure, the single intermediate CA server on the right side of the illustration is the only server that is known by the CA below it. The subordinates of the middle-left CA are linked to the two CAs on its sides. These two CAs do not know about the other CAs, because they are linked only to the CA that provides them a connection. The two intermediate servers in the middle of the illustration and their subordinates trust each other. They do not trust others that are not in the link.

The major difficulty with hybrid models is that they can become complicated and confusing. A user can unintentionally acquire trusts that they should not have obtained. In our example, a user could accidentally be assigned to one of the CAs in the middle circle. As a member of that circle, they could access certificate information that should be available only from their root CA. Relationships between CAs can continue long past their usefulness. Unless someone is aware them, these relationships can exist even after the parent organizations have terminated their relationships.