TLS v1.3 (Transport Layer Security), the latest successor to SSL, secures network communications with https protocol and mTLS (mutual TLS) using x.509 format certificates
https://www.rfc-editor.org/rfc/rfc8446 is the technical specification for TLS.
https://www.wikiwand.com/en/X.509 is the technical specification for X.509, the format of public key certificates.
NOTE: Content here are my personal opinions, and not intended to represent any employer (past or present). “PROTIP:” here highlight information I haven’t seen elsewhere on the internet because it is hard-won, little-know but significant facts based on my personal research and experience.
Secure Data in Transit
Data in-transit is what moves between one system and another. It includes data moving between resources within an organization (such as passwords, secrets, keys), and outside services.
Protecting data in transit means ensuring a triad of conditions:
- confidentiality (privacy of not being seen by unauthorized others eavesdropping)
- integrity of the data (not corrupted, tampered by others)
- availability of the data (when and where needed, despite disasters)
Reliability groups together integrity and availability.
A server can ensure that it interacts with only a known set of users (rather than anonymous users) by requiring use of mTLS (mutual TLS) on both ends of the communication – where a TLS certificate (from a CA) is installed on the sit’s clients. mTLS enables websites to choose which requesters to communicate with. A client-side TLS certificate proves that the client is known to the server. There is are additional conditions:
- level of authentication (only those who are known have access)
- level of authorization (access is limited to specific actions - add, list, view, change, delete, etc.)
HashiCorp Consul automates enablement of mTLS for communication between app services. Even legacy apps can use mTLS because Consul intercepts traffic as a proxy in a service mesh. Use of a proxy architecture enables Consul to enforce mTLS across clouds and platforms. Consul can create signed certificates automatically. Its approach enables rapid and comprehensive upgrade of new TLS versions and cipher suites in the future, avoiding slow massive upgrade of code in all apps. https://learn.microsoft.com/en-us/security/engineering/solving-tls1-problem
Quick response is necessary DocuSign Connect HMAC (Hash-Based Message Authentication Codes) See https://developers.docusign.com/platform/webhooks/connect/hmac/ https://www.jscape.com/blog/what-is-hmac-and-how-does-it-secure-file-transfers
Most websites today have obtained SSL (Secure Socket Layer) certificates from a CA (Certificate Authority) to use https (instead of http) protocol (through port 443) for encrypted communication with browsers. TLS is also used to wrap FTP (FTPS, not to be confused with SFTP which uses the SSH protocol), IMAP (IMAPS), POP3 (POP3S), and SMTP (SMTPS), among others.
Additionally, companies such as DocuSign also encrypt files being transferred. DocuSign uses HMAC to create a hash.
On browsers, a lock icon appears next to the URL address to indicate use of encryption. Regular http is dangerous because someone (a man in the middle) can intercept the traffic and insert malicious code before forwarding to the user’s browser. TLS (Transport Layer Security) is essentially the newer version of SSL.
The latest version, currently TLS v1.3, is used to provide the highest security. That is because cryptographic algorithms can be cracked over time. TLS 1.3 removed use of ECDHE_RSA among the three ciphers: QUIC, X25519, and AES_128_GCM. Microsoft enabled TLS 1.3 by default in 2020. The list of which browser supports TLS 1.3 is at https://caniuse.com/tls1-3
Verify whether your browser and website together supports TLS 1.3 certificates:
TLS 1.1 and TLS 1.0 should be disabled.
Ensure that the website insists on use of encrypted traffic using HTTPS (over port 443) rather than insecure HTTPS (over port 80) by use of the HSTS (HTTP Strict Transport Security) policy mechanism:
HSTS works by the server responding to client agents in HTTPS containing a response header field such as
Strict-Transport-Security: max-age=3153600; includeSubDomains; preload
which specifies a year of seconds the user agent should only access the server using HTTPS protocol.
HSTS was published as RFC 6797 (on 19 November 2012) for browsers to be programmed to recognize the header and automatically upgrade to use HTTPS. See the version of each browser added the feature.
HSTS should also work with utilities such as curl. Many websites that prefer HTTPS still listen for connections over HTTP in order to redirect the user to the HTTPS URL.
curl --head http://github.com
A redirect such as the following is insecure and provides an opportunity for attackers to capture information about the visitor (such as cookies from a previous secure session), or to maliciously redirect the user to a phishing site:
HTTP/1.1 301 Moved Permanently Location: https://github.com/
The HTTP protocol has been found to be vulnerable against man-in-the-middle attacks where traffic is intercepted and then forwarded.
When HSTS is enabled, the response to:
curl --head http://irs.gov
would look like this:
HTTP/1.0 301 Moved Permanently Location: https://irs.gov/ Strict-Transport-Security: max-age=31536000 Server: BigIP Connection: Keep-Alive Content-Length: 0
curl --head http://cisa.gov HTTP/1.1 301 Moved Permanently Server: AkamaiGHost Content-Length: 0 Location: https://cisa.gov/ Cache-Control: max-age=0 Expires: Sat, 08 Oct 2022 14:05:59 GMT Date: Sat, 08 Oct 2022 14:05:59 GMT Connection: keep-alive
Websites may request at hstspreload.org to be added to the Preload list used by websites.
Securing Web Services
“Let’s Encrypt” provides free automated TLS certificates for all applications. Their free certificates are valid for 90 days. Paid certificates are valid for years at a time.
K8s Cert Manager
The Kubernetes Cert Manager service is useed to apply for certs and automate the renewal process. It’s fast and easy and works seemlessly on EKS.
To install it:
$ kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.1.0/cert-manager.yaml
To see what was installed:
kubectl get pods -n cert-manager
The main service watches for changes in Kubernetes and then acts to create certificate requests if needed. Test with the staging issuer:
cd cert-manager kubectl create -f staging-issuer.yaml
For the production issuer:
kubectl create -f prod-issuer.yaml
See resources created:
kubectl get clusterissuers
NAME READY AGE letsencrypt-prod True 96s letsencrypt-staging True 108s
Create the TLS certificate on our application to modify the ingress rule.
View changesin the
ngx-ing.yaml in the same directory:
apiVersion: extensions/v1beta1 kind: Ingress metadata: annotations: cert-manager.io/cluster-issuer: letsencrypt-prod kubernetes.io/ingress.class: nginx name: ngx namespace: default spec: tls: - hosts: - k8s.castlerock.ai secretName: ngx-tls-cert rules: - host: k8s.castlerock.ai http: paths: - backend: serviceName: ngx servicePort: 80
The changes are:
cert-manager.io/cluster-issuer: letsencrypt-prod- tells that we want to issue TLS and the cluster issuer to use to get that certificate.
tls- specifies which domain we want as well as where to store the TLS secrets once obtained them from the service.
To troubleshoot, look at custom resources:
kubectl get orders kubectl get certificates kubectl get certificaterequests
These are the actions created when the ingress rule specifies a TLS service.
Check your domain again and see that it works with encryption.
Set Up Mutual TLS Authentication
Obtain the version to ensure that the utility is working:
To make it easier to handle different certificates for different parts of the application, have certificate to a subdomain.
A subdomain constraint to your routes:
constraints subdomain: 'admin' do resources :users # or ActiveAdmin.routes(self) for the ActiveAdmin gem end
Create a CA (Certificate Authority) to sign both the server and client certificate requests.
Root CAs are not used to sign certificates directly.
Root CAs are used to create trusted intermediate CAs to sign certificates.
The root CA needs to be kept very secure, such as in a disconnected (air gapped) computer.
Designate a folder to keep CA keys and certificates. On a Linux machine:
Identify the key length of 4096 for the CA. The encryption algorithms 3DES or AES with a 256 bit key length are acceptable here and a strong password is desirable. (SHA1 shouldn’t be used anymore)
Create a new private key with a password for the CA:
openssl genrsa -aes256 -out ca/ca.key 4096 chmod 400 ca/ca.key
Create the root CA certificate with a validity of two years using the SHA256 hash algorithm :
openssl req -new -x509 -sha256 -days 730 -key ca/ca.key -out ca/ca.crt
Leave all attribute fields blank by entering .. Only the CommonName will be 42CA to identify the certificate.
chmod 444 ca/ca.crt
Verify the root certificate to check the validity (2 years).
openssl x509 -noout -text -in ca/ca.crt
The Issuer and Subject are both 42CA because this is a root certificate, which are always self-signed.
Create a CSR (Certificate Signing Request) from the server. The request is to create a certificate for a specific domain name. Usually, the CA and the certificate requester are two different companies who don’t want to share their private keys. That’s why this middle step is needed.
First, we’ll create a private key for the server and then the CSR. Use a 2048 bit keys because the key is only valid for a year, and 4096 bits would slow down the TLS handshake.
The -aes256 option is omitted so a password doesn’t have to be entered every time the web server is started.
openssl genrsa -out server/client-ssl.bauland42.com.key 2048 chmod 400 server/client-ssl.bauland42.com.key openssl req -new -key server/client-ssl.bauland42.com.key -sha256 -out server/client-ssl.bauland42.com.csr
A dot is entered for each CSR detail. But the Common Name has to be the server’s fully qualified domain name. For example, “client-ssl.bauland42.com”.
Use the root CA to sign the CSR (for a year). You’ll be prompted to enter the root CA’s password.
openssl x509 -req -days 365 -sha256 \ -in server/client-ssl.bauland42.com.csr -CA ca/ca.crt \ -CAkey ca/ca.key -set_serial 1 -out server/client-ssl.bauland42.com.crt chmod 444 server/client-ssl.bauland42.com.crt
Verify the Validity, the Issuer (42CA), and the Subject (client-ssl.bauland42.com):
openssl x509 -noout -text -in server/client-ssl.bauland42.com.crt
Verify the chain of trust. Although, it’s not really a chain – the root CA signed the server certificate directly.
openssl verify -CAfile ca/ca.crt server/client-ssl.bauland42.com.crt server/client-ssl.bauland42.com.crt: OK
It’s best if the user created the client’s CSR so that the server wouldn’t see the user’s private key. To generate the client certificate:
openssl genrsa -out client/heiko.key 2048 openssl req -new -key client/heiko.key -out client/heiko.csr openssl x509 -req -days 365 -sha256 -in client/heiko.csr \ -CA ca/ca.crt -CAkey ca/ca.key -set_serial 2 -out client/heiko.crt
The server would sign the CSR and return the certificate to the user.
We’ll use the serial number 2 for this certificate.
Make use of the client certificates.
More on DevSecOps
This is one of a series on DevSecOps:
- ci-cd (Continuous Integration and Continuous Delivery)
- User Stories for DevOps
- Git and GitHub vs File Archival
- Git Commands and Statuses
- Git Commit, Tag, Push
- Git Utilities
- Data Security GitHub
- GitHub API
- Choices for DevOps Technologies
- Pulumi Infrastructure as Code (IaC)
- Java DevOps Workflow
- AWS DevOps (CodeCommit, CodePipeline, CodeDeploy)
- AWS server deployment options
- Cloud services comparisons (across vendors)
- Cloud regions (across vendors)
- Azure Cloud Onramp (Subscriptions, Portal GUI, CLI)
- Azure Certifications
- Azure Cloud Powershell
- Bash Windows using Microsoft’s WSL (Windows Subsystem for Linux)
- Azure Networking
- Azure Storage
- Azure Compute
- Digital Ocean
- Packer automation to build Vagrant images
- Terraform multi-cloud provisioning automation
Hashicorp Vault and Consul to generate and hold secrets
- Powershell Ecosystem
- Powershell on MacOS
- Jenkins Server Setup
- Jenkins Plug-ins
- Jenkins Freestyle jobs
- Docker (Glossary, Ecosystem, Certification)
- Make Makefile for Docker
- Docker Setup and run Bash shell script
- Bash coding
- Docker Setup
- Dockerize apps
- Kubernetes Operators
- Threat Modeling
- API Management Microsoft
- Scenarios for load
- Chaos Engineering