The TLS handshake, certificate pinning, mTLS, Zero Trust architecture and how to implement it, securing microservices end to end, encryption at rest, what Vault does, DDoS attacks and mitigation, PII compliance, and GDPR — what a senior Java engineer must know to design and defend secure systems.
Published September 25, 2026
How to use this lesson
Security architecture questions reward layered defences (no single control is trusted alone) and concrete mechanisms. Structure answers as:
identity (who is calling);
transport (is the channel protected);
authorisation (may they do this);
data (is it protected at rest and in logs);
detection (would we notice);
response.
Q1. What happens in a TLS handshake?
Short answer:TLS 1.3 (simplified; one round trip):
ClientHello: the supported versions and cipher suites, a random value, and key shares (ephemeral Diffie-Hellman public keys, for example X25519), plus SNI (the host name).
ServerHello: the chosen cipher suite and the server's key share. Both sides now compute the shared secret (ECDHE) and derive the session keys; everything after this is encrypted.
The server sends its certificate (chain) and CertificateVerify (a signature over the handshake with its private key, proving it owns the certificate), then Finished.
The client validates the certificate: the chain up to a trusted CA, the host name, validity dates, and revocation (OCSP stapling). Then it sends Finished.
Application data flows, encrypted with symmetric AEAD ciphers (AES-GCM, ChaCha20-Poly1305).
Key properties:
forward secrecy (ephemeral keys: a stolen server key can't decrypt past sessions);
authentication of the server (and optionally of the client, in mTLS);
integrity.
TLS 1.2 needed two round trips, and allowed weaker options; TLS 1.3 removed RSA key exchange, CBC ciphers and more. Session resumption (PSK) and 0-RTT reduce latency, but 0-RTT data can be replayed, so use it only for idempotent requests.
Q2. What is mTLS?
Short answer: In mutual TLS, both sides present and verify certificates: the server authenticates the client too. It gives strong service-to-service identity and encryption, and it's a core building block of Zero Trust.
Where it's used: service-to-service traffic inside a platform, partner or B2B APIs, IoT devices, and bank integrations.
The operational challenge is certificate lifecycle management: issuing, short-lived certificates with automatic rotation, and trust bundles. A service mesh (Istio, Linkerd) automates this with sidecars or ambient mode, using SPIFFE/SPIRE identities (spiffe://cluster/ns/booking/sa/booking-svc), so application code doesn't change.
In Spring Boot (without a mesh):SSL bundles configure the key store and trust store (spring.ssl.bundle.*), server.ssl.client-auth=need on the server, and a client RestClient or WebClient configured with the bundle.
Authorisation still matters: mTLS proves which service is calling. Add policies for what each service may call (mesh authorisation policies), plus user-level tokens propagated for end-user context.
Short answer: The client accepts only a specific certificate or public key (or a small set) for a host, rather than any certificate signed by any trusted CA. It defends against compromised or misissued CAs, and against man-in-the-middle proxies. It's mostly used in mobile apps and high-security clients.
Pin the public key (the SPKI hash), not the whole certificate, so certificates can be renewed with the same key; always include backup pins (a second key), otherwise a key rotation or loss bricks the app until users update.
The risks: operational outages when certificates change; rotation needs careful planning; debugging proxies stop working.
Modern guidance is cautious: browsers dropped HPKP (HTTP public key pinning) because of the self-inflicted outage risk. Prefer Certificate Transparency monitoring, and pinning only where the threat model justifies it (for example, banking apps), with a remote-config kill switch.
Q4. What is Zero Trust architecture? How do you implement Zero Trust security?
Short answer:"Never trust, always verify": no implicit trust based on network location (being "inside the VPN or cluster" grants nothing). Every request is authenticated, authorised and encrypted, based on identity, device posture and context, with least privilege, and an assume-breach mindset (NIST SP 800-207).
Implementation:
Strong identity for users: SSO with MFA (phishing-resistant: FIDO2 or passkeys); conditional access (device health, location, risk).
Strong identity for workloads:mTLS with workload identities (SPIFFE); cloud IAM roles instead of static keys.
Per-request authorisation: at the gateway, and in each service (token validation, fine-grained policies with OPA); service-to-service allow-lists (mesh authorisation policies, Kubernetes NetworkPolicies with default deny).
Least privilege and just-in-time access: short-lived credentials (Vault dynamic secrets); temporary admin access with approval; no standing production access.
Micro-segmentation: limit lateral movement.
Encrypt everything in transit (including inside the network) and at rest.
Continuous monitoring: centralised logs and audits, anomaly detection (UEBA), and automated response.
Replace the VPN with identity-aware proxies / ZTNA for employee access to internal tools.
Roll it out incrementally: start with identity (SSO and MFA), then service mTLS, then policies and segmentation.
Q5. How do you secure microservices?
Short answer: In layers:
The edge: the API gateway terminates TLS, runs a WAF, rate limits, validates OAuth2 tokens, and blocks unknown routes.
Service to service:mTLS (a mesh) for identity and encryption; token propagation (the user's token, or token exchange for a downscoped token) so services know the end user; authorisation policies on which services may call which.
Inside each service:
Spring Security resource server validating JWTs (issuer, audience);
method and object-level authorisation;
input validation;
secure defaults (no exposed Actuator endpoints beyond health and info, or put them on a separate management port).
Secrets: Vault or a cloud secrets manager; dynamic database credentials; no secrets in images, Git or environment dumps.
minimal base images (distroless), running as non-root, with read-only filesystems;
image scanning (Trivy).
The platform: Kubernetes RBAC; NetworkPolicies; Pod Security Standards; separate namespaces and accounts; least-privilege IAM (IRSA or workload identity).
Data: encryption at rest, field-level encryption for sensitive data, personal data minimised in logs.
Detection and response: audit logs, centralised security monitoring (SIEM), alerts, and an incident response plan.
Q6. What is data encryption at rest? What is Vault?
Short answer:
Encryption at rest protects stored data (disks, databases, backups, object storage) if the media or snapshots are stolen.
The layers:disk or volume encryption (EBS, LUKS); database TDE (transparent data encryption); storage service encryption (S3 SSE-KMS); and application-level (field-level) encryption for the most sensitive fields (card data, identity numbers), so even DBAs and database dumps don't expose them.
Envelope encryption: data is encrypted with a data key (DEK); the DEK is encrypted with a key-encryption key (KEK) in a KMS or HSM. Rotating the KEK doesn't require re-encrypting all the data.
Key management is the real security: access policies, rotation, audit, separation of duties.
For searchable fields, use deterministic encryption or blind indexes (HMAC of the value), accepting the leakage trade-offs.
HashiCorp Vault is a secrets management system:
it stores static secrets (a KV store) with fine-grained policies and audit;
it generates dynamic secrets (short-lived database credentials, cloud credentials) on demand, which are revoked automatically;
encryption as a service (the Transit engine: apps send data to encrypt or decrypt, without ever holding the keys);
a PKI engine (issuing short-lived certificates);
authentication through Kubernetes service accounts, cloud IAM, OIDC or AppRole.
Spring integration: Spring Cloud Vault. Alternatives: AWS Secrets Manager and KMS, Azure Key Vault, GCP Secret Manager.
Q7. What is a DDoS attack? How do you mitigate it?
Short answer: A distributed denial-of-service attack uses many sources (botnets) to exhaust a target's resources, so legitimate users can't be served. The types:
volumetric (floods that saturate bandwidth: UDP floods, amplification attacks such as DNS, NTP or memcached reflection);
protocol attacks (exhausting connection state: SYN floods);
application-layer (L7) attacks (floods of expensive HTTP requests, like search or login, that look legitimate; slowloris).
Mitigation, in layers:
Absorb it at the edge:CDN and anycast networks with DDoS scrubbing (Cloudflare, AWS Shield plus CloudFront, Akamai, Azure DDoS Protection). Don't expose origin IPs (allow only the CDN's IP ranges).
Filter at L7: a WAF with rate-based rules, bot management, challenges (JavaScript or CAPTCHA) for suspicious traffic, geo or IP reputation blocking.
Application design:
rate limiting per IP, user and API key;
caching (served from the CDN or cache without touching the backend);
timeouts and limits on request size, header size, connections and slow clients;
make the expensive operations authenticated or queued;
autoscaling, with caps (cost);
graceful degradation, and load shedding of non-critical features.
Preparation: a DDoS response runbook, a contact with the provider, traffic baselines and alerts, and cost-protection plans (some providers credit scaling costs caused by attacks).
Key points to cover: the source answer (firewalls, traffic analysis, cloud-based DDoS protection) is right, but incomplete. Add L7 attacks, the CDN/anycast absorption, rate limiting, hiding the origin, and application-level limits.
Q8. What is PII compliance? What is GDPR?
Short answer:
PII (personally identifiable information) is data that identifies a person directly (name, email, phone, identity documents) or indirectly (combinations of IP, device ID, location, booking details). Sensitive categories (health, biometrics, financial or identity numbers) need extra protection.
PII compliance means following the applicable laws (GDPR in the EU, India's DPDP Act 2023, CCPA/CPRA in California, HIPAA for US health data) and standards (PCI DSS for card data) through:
data inventory and classification (know what you hold, where, and why);
data minimisation and purpose limitation; retention limits, with automatic deletion;
access control, encryption, masking in non-production environments and logs, pseudonymisation for analytics;
consent management, and privacy notices;
data subject rights workflows;
vendor management (data processing agreements), and breach notification processes.
GDPR (the EU General Data Protection Regulation, in force since 2018) applies to anyone processing EU residents' personal data, wherever the company is based. Its core:
principles: lawfulness, fairness and transparency; purpose limitation; data minimisation; accuracy; storage limitation; integrity and confidentiality; accountability;
rights: access, rectification, erasure ("right to be forgotten"), restriction, portability, objection, and rights about automated decision-making;
obligations:privacy by design and by default, DPIAs for high-risk processing, records of processing, a DPO where required, breach notification within 72 hours to the authority, and rules on international transfers (adequacy decisions, standard contractual clauses);
fines of up to €20 million or 4% of global annual turnover, whichever is higher.
Engineering implications:
erasure must reach every copy: databases, caches, search indices, data warehouses, logs and backups (crypto-shredding helps: delete the per-user key);
personal data kept out of logs;
data residency for regional storage;
export APIs for portability;
consent flags checked in processing pipelines.
Follow-up questions this topic invites — and their answers
Q: What's the difference between encryption, hashing and encoding?
A: Encryption is reversible with a key (confidentiality). Hashing is one-way (integrity checks, and password storage with slow salted algorithms such as bcrypt or Argon2). Encoding (Base64) is reversible without any key, and gives no security.
Q: How should passwords be stored?
A: With an adaptive, salted, slow hash: bcrypt, scrypt, Argon2 or PBKDF2 (Spring's DelegatingPasswordEncoder defaults to bcrypt). Never encrypt passwords reversibly, and never use fast hashes such as SHA-256 on their own.
Q: What is crypto-shredding?
A: Encrypting each user's (or tenant's) data with its own key, and deleting the key to make all copies, including backups, unreadable. It's a practical way to honour erasure across immutable storage.
Q: What's the difference between a WAF and a network firewall?
A: A network firewall filters by IP, port and protocol (L3/L4). A WAF inspects HTTP requests (L7) for attack patterns (injection, XSS, bots, abusive rates) and can apply application-aware rules.
