Log in
SkillPilotAI
Plans

Encryption, HTTPS/TLS & Secrets Management

Encrypt data on the way (in transit) and on disk (at rest), and keep passwords/API keys outside the code in a safe vault.

42.1 Why is it used?

  • Without HTTPS, anyone at the Wi-Fi or ISP level can read a password or card number (man-in-the-middle).
  • If a disk or backup is stolen, at-rest encryption keeps the data useless.
  • If DB passwords and API keys are hardcoded in code or Git, a leak is almost certain.
  • Compliance such as PCI-DSS, RBI guidelines and the DPDP Act requires encryption and key management.
  • A central secrets store makes rotation, audit (who read which key when) and access control easy.

42.2 How it works

  • TLS handshake: client and server verify the certificate and agree on a session key, then data is encrypted with symmetric (AES). TLS 1.3 is fast and secure.
  • Certificate: a CA (like Let's Encrypt, DigiCert) signs the domain's certificate and the browser trusts it.
  • TLS termination: HTTPS is decrypted at the load balancer/CDN, and traffic goes to the backend over HTTP or over TLS again (re-encryption).
  • mTLS: certificates on both sides, for service-to-service trust (service mesh like Istio).
  • At-rest encryption: disks, DBs, S3 objects encrypted with AES-256; keys live in KMS.
  • Envelope encryption: encrypt data with a Data Key, encrypt the Data Key with the KMS Master Key. The master key never leaves KMS.
  • Secrets management: the app fetches secrets from the vault at runtime; dynamic secrets (temporary DB user) and automatic rotation.
  • Hashing passwords: passwords are not encrypted, they are stored hashed with bcrypt/Argon2.
TLS handshake (simple)
  1. 1.1. Browser -> Server: ClientHello
  2. 2.2. Server -> Browser: certificate (CA signed)
  3. 3.3. Browser verifies the certificate with the CA
  4. 4.4. Key share, a session key is made on both sides
  5. 5.5. Data is encrypted with fast symmetric AES

The handshake builds the session key with asymmetric crypto, then all data travels with symmetric AES.

Envelope encryption (KMS)
  1. 1.Card data -> encrypt with Data Key, AES-256 -> Encrypted data
  2. 2.Encrypt the Data Key with the KMS Master Key -> Encrypted Data Key (stored with the encrypted data)
  3. 3.The Master Key never leaves KMS
  4. 4.Decrypt: open the Data Key with KMS, then decrypt the data

Passwords: do not encrypt, HASH with bcrypt / Argon2.

Journey of card data in a payment app
  1. 1.User App: card details over TLS 1.3 up to the CDN / ALB
  2. 2.CDN / ALB terminates TLS (cert: Let's Encrypt, expiry monitored)
  3. 3.mTLS to the Payment Service; card is tokenised
  4. 4.Payment Service fetches the DB password and API key from Vault / Secrets Manager at startup
  5. 5.Payments DB: AES-256 at rest + backups, master key in AWS KMS
  6. 6.Secrets auto-rotate every 30 days, every secret access goes to the audit log

Wrong: secrets in .env / Git = a leak is almost certain, rotate immediately. If cert expiry is not monitored, the site goes down.

42.3 Tools you can use

ToolTypeHow it is used
HashiCorp VaultSecrets manager (open-source/enterprise)Multi-cloud secrets, dynamic DB credentials, PKI certificates, encryption-as-a-service.
AWS KMSManaged key managementManages encryption keys for S3, EBS, RDS; envelope encryption, CloudTrail audit.
AWS Secrets ManagerManaged secrets storeStores DB passwords, API keys; automatic rotation with RDS.
Azure Key VaultAzure keys + secrets + certsSecrets, keys and TLS certificates of Azure apps in one place, accessed with Managed Identity.
GCP Secret Manager / Cloud KMSGCP managed servicesTo manage secrets and encryption keys of GCP workloads.
Let's Encrypt + cert-managerFree CA + Kubernetes cert automationFree TLS certificates; cert-manager issues and renews them automatically in Kubernetes.

42.4 Comparison: HashiCorp Vault vs AWS Secrets Manager vs Azure Key Vault

PointHashiCorp VaultAWS Secrets ManagerAzure Key Vault
TypeSelf-hosted or HCP managedFully managed AWSFully managed Azure
Cloud supportMulti-cloud + on-premMainly AWSMainly Azure
Dynamic secretsYes, temporary DB/cloud credsNo, rotation via LambdaNo, mostly static secrets
Key managementEncryption via the Transit engineTogether with KMSKeys, secrets, certs all built in
Setup effortHigh - HA, unseal, upgradesLowLow
CostOSS free, ops cost; enterprise is expensivePer secret per month + API callsPer operation, cheap
Best forLarge multi-cloud / hybrid setupsAWS native appsAzure native apps

42.5 When to choose which

  • HashiCorp Vault: a hybrid or multi-cloud setup, need dynamic credentials and PKI.
  • AWS Secrets Manager + KMS: the whole app is on AWS and you need RDS password rotation.
  • Azure Key Vault: Azure / AKS workloads, passwordless access with Managed Identity.
  • Do TLS termination at the LB/CDN (CloudFront, ALB, Nginx); use mTLS for sensitive internal traffic.

42.6 Real-world example

Such a scenario: the journey of card data in a payment app

  1. The user enters card details in the app, and the data goes TLS 1.3 encrypted up to the CDN/LB.
  2. The load balancer terminates TLS and forwards to the payment service over mTLS inside the internal network.
  3. At startup the payment service gets the DB password and gateway API key from Vault/Secrets Manager, with nothing hardcoded in code.
  4. The card number is tokenised; any sensitive data that is stored is AES-256 encrypted, with the key in KMS.
  5. The DB disk and backups are encrypted with a KMS key, so even a stolen backup cannot be read.
  6. The DB password rotates automatically every 30 days and every secret access is recorded in the audit log.

42.7 Interview tips

  • Committing secrets to a .env file or Git repo; if leaked, rotate immediately.
  • Not monitoring certificate expiry: the whole site goes down the moment it expires.
  • Encrypting passwords instead of hashing them; use bcrypt/Argon2 for passwords.
  • Interview tip: you should be able to explain the flow of envelope encryption and TLS termination.