Protecting data in-transit. Encryption Basics
Web traffic is protected in-flight when it is transferred via TLS encrypted links using the HTTPS protocol. HTTPS is a protocol for payload encryption that is based on algorithms using encryption asymmetrical keys. Asymmetrical keys are managed, packaged and distributed with via certificates
Companies often change strategy when moving to the cloud. They then want to encrypt all traffic based on the idea that they encrypt traffic on networks that they don't own. They don't own the underlying cloud provider network so all traffic must be encrypted.
They can assume that applications are always accessed through their load balances. This can be enforced through cloud and network security. In the end, only the Load Balancer requires a publicly trusted certificate for its link encryption. TLS connections for the application servers behind the load balancer can be signed using any type of self-signed or transient CA. Local certificates can be regenerated every time a new machine is built and destroyed with the machine when it is de-provisioned.
Encryption Basics
Asymmetrical encryption relies on a key pair where one key can decrypt any data that is encrypted by the other. Data encrypted with Key-A can be decrypted with Key-B only. Key-A cannot be used to decrypt data encrypted with Key-A. Key-B cannot be derived by knowing Key-A.
Internet encryption relies on asymmetry and key anonymity in order to create secure links over a public and untrusted Internet. A server or party can publish a public key that other parties can use to encrypt their data. The server then can decrypt the message using the corresponding private key. Encrypted messages are secure as long as the server keeps the private key secret. Private keys must be protected.
Note: Digital signing is an inverse. An entity signs something by encrypting it using its private key. A third party can then decrypt the signed item by using the originating entity's public key. The originator protects the private key insuring that no one else can generate a message decryptable via the entity's public key.
Web Server Encryption Basics
Browsers and Web Servers communicate securely by using asymmetrical public/private key encryption. Encryption keys are distributed in envelopes called Certificates.
- A client connects to a server and requests the server's public certificate.
- The server then returns the certificate.
- The browser verifies the certificate expiration date and that the name of the certificate matches the server name.
- The browser verifies that the certificate is still valid optionally checking repudiation.
- The browser encrypts its message payload and a key/seed using the public key.
- The browser sends the encrypted payload which is then decrypted by the server.
- The server replies to the browser using the public key that was contained in the original encrypted request.
Encryption Relies on Certificates
Encryption keys are bound to a sever and vouched for through digitally signed certificates. A Certificate Authority (CA) issues certificates that contain encryption keys. They digitally sign the certificate using their own CA keys. The signed item includes encryption keys and other information describing the identity of the CA holder and the CA issuer.
Normal Web Server certificates are essentially static, bound to a host name. Web server certificates include the value of the host name of the server they should be used on. This means a certificate can only be used by single host because the calling party can match the certificate encrypted host name value against that in the request.
It is possible to add multiple alternate host names in the Subject Alternate Name fields. It is also possible to order a wildcard based certificate that specifies the associated hosts via wildcard and domain name combinations. Many organizations frown on wildcard certificates because they can be used on any matching hosts, possibly even unapproved ones.
When and where
A lot of companies use TLS encrypted links at the edge of their organization talking to other organizations or the internet. Edge nodes and relatively rare making certificate issuance and maintenance relatively straightforward. They often assume that the interior of their network is secure and do not encrypt in-network traffic.Companies often change strategy when moving to the cloud. They then want to encrypt all traffic based on the idea that they encrypt traffic on networks that they don't own. They don't own the underlying cloud provider network so all traffic must be encrypted.
Cloud Complications
Full network encryption means that load balanced applications require certificates in multiple tiers. This means there can be significantly more hosts and corresponding certificates.
Cloud environments are very dynamic. Application deployments often build new machines for each deployment. Cloud infrastructure supports dynamic addition and removal of application hosts based on demand. Cloud infrastructure also has its own naming convention for new hosts. All of this combines to create a bit of a certificate management headache. Teams may have to issue new certificates for every new web endpoint whenever they are initially provisioned or re-provisioned over the top of old instances.
Cloud workarounds
Cloud environments can optimize this problem by making a couple assumptions. I'm using AWS ELBs as an example here.
They can assume that applications are always accessed through their load balances. This can be enforced through cloud and network security. In the end, only the Load Balancer requires a publicly trusted certificate for its link encryption. TLS connections for the application servers behind the load balancer can be signed using any type of self-signed or transient CA. Local certificates can be regenerated every time a new machine is built and destroyed with the machine when it is de-provisioned.
Comments
Post a Comment