Protecting Data in Transit: Trust Chains
Web traffic is protected in-flight when it is transferred via TLS encrypted links using HTTPS. HTTPS is a protocol that is based on encryption algorithms using asymmetrical keys. Asymmetrical keys are managed, packaged and distributed via certificates.
Browsers, applications and servers trust certificates and their associated encryption keys based on their trust of the issuing parties known as Certificate Authorities (CA). Public web sites are identified by public/private certificates pairs that are purchased from one of the well known CAs. Their certificate pairs contain an identity component signed by the Certificate Authority and an encryption key that is encrypted by the CA.
Certificates are used to validate server identity and encrypt payloads so that clients can trust the source and content of data they receive. All of this depends on the ability of certificates to securely represent their intended parties.
This trust is implemented via trust chains of Root Certificate Authorities and their child Intermediate Certificate Authorities.
Programs trust certificates signed by CAs in their CA trust list. Public CAs are well known by virtue of the fact that the their root and intermediate Certificate Signing Authority certificates come pre-installed in browsers, applications and some operating systems.
Corporate issued certificates are trusted inside their infrastructure if their internal CAs public certificate is installed in corporate browsers and operating systems certificate authority trust stores. This is one of the reasons large corporations automatically install their corporate standard browsers.
Self-signed certificates can be useful in a development environment because they can be used for on-box testing. Developers can create a local signing certificate that is used for local server certificates. They can then install the local signing certificate in their O/S and application trust stores. This lets the developer issue as many certificates as they want for local testing.
Self-signed certificates can be useful for link encryption where host validation and repudiation is not an issue. This is often useful in a Cloud environment where all link traffic must be encrypted and where hosts are repeatedly created or destroyed as in auto-scale environments.
AWS, for example, uses trusted certificates on ELBs while using self signed certificates between the ASG hosts and the ELB. The ELB is configured to trust all certificates on the load balanced servers. This means the server HTTPS certificates can be self signed by the individual servers.
Self-signed certificates can be useful for private communication between servers in a pool. You see this in cloud environments with clustered products that that have some kind of internal communication bus.
The same self-signing certificate can be installed on each pool server. That same certificate is used to create the back-side bus encrypted link certificates. Each pool server will trust the pseudo-self-signed connections from the other pool servers because they all have the same self-singing root cert.
Browsers, applications and servers trust certificates and their associated encryption keys based on their trust of the issuing parties known as Certificate Authorities (CA). Public web sites are identified by public/private certificates pairs that are purchased from one of the well known CAs. Their certificate pairs contain an identity component signed by the Certificate Authority and an encryption key that is encrypted by the CA.
- Server identity is encrypted in the server certificate with the Certificate Authority public key.
- Server traffic is encrypted by the server using the private encryption key embedded in the Server's private certificate.
- Server traffic is decrypted by clients using the public encryption key embedded the server's public certificate.
Certificates are used to validate server identity and encrypt payloads so that clients can trust the source and content of data they receive. All of this depends on the ability of certificates to securely represent their intended parties.
Public Trust Chains
This trust is implemented via trust chains of Root Certificate Authorities and their child Intermediate Certificate Authorities. Programs trust certificates signed by CAs in their CA trust list. Public CAs are well known by virtue of the fact that the their root and intermediate Certificate Signing Authority certificates come pre-installed in browsers, applications and some operating systems.
Well known Certificate Authorities charge fees for their certificates. Fees are based on the certificate expiration date, the number of Subject Alternate Names included in the certificate, any wild card status and various other factors. Companies save costs by using these expensive certificates only at the edges of their organizations where 3rd party trust is important.
Corporate Trust Chains
Certificate authorities are just programs that issue certificates signed using the CA's certificate. This means that companies can issue their own certificates using an internal CA. Corporations can then issue as many certificates as they wish for internal traffic without paying fees to the well known CAs.
Corporate issued certificates are trusted inside their infrastructure if their internal CAs public certificate is installed in corporate browsers and operating systems certificate authority trust stores. This is one of the reasons large corporations automatically install their corporate standard browsers.
Browsers and programs can base trust on any number of corporate and public CAs as long as their Root Certificates are installed in the trust stores.
Self Signing
Certificates can be issued by anyone that can create a Certificate Authority root cert. Anyone can create a CA root certificate to create their own signing authority. This tends to be of limited use since no one will trust these self-signed certificates since they don't trust the root certificate.
Self-signed certificates can be useful in a development environment because they can be used for on-box testing. Developers can create a local signing certificate that is used for local server certificates. They can then install the local signing certificate in their O/S and application trust stores. This lets the developer issue as many certificates as they want for local testing.Self-signed certificates can be useful for link encryption where host validation and repudiation is not an issue. This is often useful in a Cloud environment where all link traffic must be encrypted and where hosts are repeatedly created or destroyed as in auto-scale environments.
AWS, for example, uses trusted certificates on ELBs while using self signed certificates between the ASG hosts and the ELB. The ELB is configured to trust all certificates on the load balanced servers. This means the server HTTPS certificates can be self signed by the individual servers.
Self-signed certificates can be useful for private communication between servers in a pool. You see this in cloud environments with clustered products that that have some kind of internal communication bus.The same self-signing certificate can be installed on each pool server. That same certificate is used to create the back-side bus encrypted link certificates. Each pool server will trust the pseudo-self-signed connections from the other pool servers because they all have the same self-singing root cert.
Trust chains are not required where certificates are only used for encryption and where host validation and repudiation is disabled. Most application platforms automatically do host and certificate validation. Validation must be explicitly disabled if trust validation is to be disabled.
Federated Trust
<to be written later>
Comments
Post a Comment