tls

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

Overview

Secure Data in Transit
- HSTS
Securing Web Services
K8s Cert Manager
Set Up Mutual TLS Authentication
Resources
More on DevSecOps

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:

https://www.howsmyssl.com

https://browserleaks.com/ssl

TLS 1.1 and TLS 1.0 should be disabled.

HSTS
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:

https://www.ssllabs.com/analyze.html?d=hashicorp.com&latest

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
```
Alternately:
```
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

Sample response:

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

https://www.cloudbees.com/blog/how-to-set-up-mutual-tls-authentication

Obtain the version to ensure that the utility is working:
```
openssl version
```
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:
```
/etc/nginx/certs/ca
```
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.

Resources

https://codeburst.io/mutual-tls-authentication-mtls-de-mystified-11fa2a52e9cf

More on DevSecOps

This is one of a series on DevSecOps:

Wilson Mar

tls