1. Learning Outcomes#

2. एक साधारण समस्या से शुरुआत करें#

मान लीजिए user ने आपकी Java-based banking application में login किया।

User browser से request जाती है:

Request में username, session token, account information या दूसरी sensitive information हो सकती है।

अब मुख्य सवाल है:

अगर browser और server के बीच data plain form में travel करे, तो रास्ते में मौजूद कोई attacker उसे पढ़ सके तो क्या होगा?

वह:

• password या token देख सकता है,
• request बदल सकता है,
• fake server बनकर user को confuse कर सकता है,
• sensitive business data capture कर सकता है।

यही कारण है कि केवल application का secure होना पर्याप्त नहीं है।

Communication path भी secure होना चाहिए।

3. Data in Transit क्या है?#

English definition: Data in transit is data that is actively moving from one system, device, network component, or service to another.

सरल भाषा में, data जब एक जगह से दूसरी जगह जा रहा होता है, तब वह data in transit कहलाता है।

उदाहरण:

• browser से API Gateway तक request,
• mobile app से backend तक API call,
• API Gateway से Java service तक request,
• Order Service से Payment Service तक communication,
• application से remote database तक connection।

इसे data at rest से अलग समझिए।

इस chapter का मुख्य focus data in transit protection है।

4. Network Communication को Protect करना क्यों आवश्यक है?#

Network को केवल एक invisible wire मत समझिए।

एक request कई components से होकर जा सकती है।

हर communication segment एक संभावित attack surface है।

अगर किसी segment पर plaintext traffic है, तो उस segment तक access रखने वाला attacker data observe या manipulate कर सकता है।

यह attacker हमेशा कोई बाहरी hacker ही हो, ऐसा आवश्यक नहीं है।

Risk आ सकता है:

• compromised machine से,
• malicious network participant से,
• गलत cloud/network configuration से,
• compromised internal workload से,
• unauthorized infrastructure access से।

इसलिए modern distributed systems में यह assumption उपयोगी है:

5. TLS क्या है?#

English definition: Transport Layer Security (TLS) is a cryptographic protocol used to protect communication between systems over a network.

TLS का काम दो communicating parties के बीच एक protected communication channel बनाना है।

आप TLS को एक secure tunnel जैसा सोच सकते हैं।

Client और server पहले secure connection establish करते हैं।

उसके बाद application data उस protected connection से travel करता है।

TLS को समझने के लिए अभी cryptographic mathematics जानना आवश्यक नहीं है।

System design level पर आपको मुख्यतः यह समझना है कि TLS तीन महत्वपूर्ण security properties देता है:

1. Encryption
2. Integrity
3. Authentication, सामान्य HTTPS case में मुख्यतः server authentication

अब इन्हें एक-एक करके समझते हैं।

6. Encryption#

English definition: Encryption transforms readable data into a protected form so that unauthorized observers cannot understand its contents.

मान लीजिए client यह information भेज रहा है:

Authorization: Bearer <token>

Plaintext connection में network traffic देखने वाला attacker token पढ़ सकता है।

TLS होने पर network पर भेजे जाने वाले application data को cryptographically protect किया जाता है।

Attacker packets capture कर ले, तब भी उसे original application content आसानी से readable नहीं मिलना चाहिए।

लेकिन encryption अकेला पर्याप्त नहीं है।

अगर attacker encrypted data को modify कर सके और receiver modification detect न कर सके, तो दूसरी समस्या पैदा होगी।

इसलिए integrity भी आवश्यक है।

7. Integrity#

English definition: Integrity protection allows the receiver to detect unauthorized modification of protected data while it is being transmitted.

मान लीजिए user ने request भेजी:

Transfer ₹1,000

और कोई attacker उसे बदलकर:

Transfer ₹10,000

करने की कोशिश करे।

Secure transport का उद्देश्य केवल data छिपाना नहीं है।

Receiver को यह भी assurance चाहिए कि protected communication को रास्ते में unauthorized तरीके से modify नहीं किया गया।

TLS cryptographic integrity protection देता है।

इसलिए transport security के दो अलग सवाल हैं:

• क्या unauthorized observer data पढ़ सकता है?
• क्या attacker data silently बदल सकता है?

TLS दोनों risks को address करने में मदद करता है।

8. Server Authentication#

English definition: Server authentication allows a client to verify that it is communicating with the intended server rather than an impostor.

मान लीजिए आपने browser में अपनी banking website खोली।

Encryption हो भी जाए, लेकिन अगर encrypted connection attacker के fake server के साथ बना है, तो encryption का फायदा क्या हुआ?

इसलिए client को यह verify करना होता है कि सामने वाला server वही है जिसके साथ communication intended था।

यहाँ certificates महत्वपूर्ण role निभाते हैं।

सरल flow:

यह exact cryptographic handshake का पूरा implementation नहीं है।

यह system-design mental model है।

Client blindly server पर trust नहीं करता।

पहले server identity verify की जाती है।

फिर protected communication continue होता है।

9. HTTP और HTTPS में क्या अंतर है?#

English definition: HTTP is an application-layer protocol used for exchanging web requests and responses, while HTTPS is HTTP communication protected using TLS.

सरल शब्दों में:

HTTPS = HTTP over TLS

HTTP request का business meaning वही रह सकता है।

उदाहरण:

• GET /products
• POST /orders
• headers
• request body
• response body

लेकिन HTTPS में transport layer TLS से protect होती है।

10. TLS Connection को सरल Mental Model से समझें#

TLS setup को high level पर दो phases में समझ सकते हैं।

Phase 1: Secure relationship establish करना#

Client और server secure parameters establish करते हैं।

Client server identity validate करता है।

दोनों encrypted communication के लिए आवश्यक cryptographic state establish करते हैं।

Phase 2: Application data exchange#

इसके बाद HTTP request/response protected channel से travel करती है।

आपको interview में handshake की हर cryptographic message याद होना आवश्यक नहीं है, जब तक question specifically उस depth पर न जाए।

System design में अधिक महत्वपूर्ण प्रश्न हैं:

• TLS कहाँ terminate होगा?
• कौन-सा component plaintext देख सकता है?
• backend communication भी encrypted है या नहीं?
• certificates कौन manage करेगा?
• rotation कैसे होगी?
• service identity कैसे verify होगी?

11. TLS Termination क्या है?#

English definition: TLS termination is the point where a component ends a TLS connection, decrypts the protected traffic, and processes or forwards the resulting application data.

यही concept distributed architecture में बहुत महत्वपूर्ण है।

मान लीजिए architecture है:

यहाँ TLS connection Load Balancer पर terminate हो रही है।

इसका अर्थ:

1. Client से Load Balancer तक traffic encrypted है।
2. Load Balancer TLS connection accept करता है।
3. Load Balancer application request को plaintext form में access कर सकता है।
4. Load Balancer से Java Service तक दूसरा connection बनता है।
5. यदि वह connection HTTP है, तो internal segment encrypted नहीं है।

इस architecture को देखकर केवल यह कहना कि "हम HTTPS use कर रहे हैं" पर्याप्त नहीं है।

सही सवाल है:

HTTPS कहाँ तक?

12. TLS Termination Point Security Boundary क्यों है?#

English definition: A security trust boundary is a point where the system's trust assumptions or security exposure changes.

जब traffic encrypted है, intermediate network observers application payload नहीं पढ़ सकते।

लेकिन जहाँ TLS terminate होती है, वहाँ component को plaintext application data मिल सकता है।

इसलिए TLS termination करने वाले component की security महत्वपूर्ण है।

उदाहरण:

• Load Balancer
• reverse proxy
• API Gateway
• ingress proxy
• service mesh proxy
• application service स्वयं

Design review में पूछिए:

• कौन TLS terminate करता है?
• उस component को कौन manage करता है?
• क्या वहाँ sensitive data logs में जा सकता है?
• termination के बाद traffic कहाँ जाता है?
• अगला hop encrypted है या plaintext?

यह analysis architecture के trust boundaries को स्पष्ट करता है।

13. TLS Passthrough क्या है?#

English definition: TLS passthrough forwards encrypted TLS traffic without terminating or decrypting the TLS session at the intermediary.

अब दूसरा design देखें:

यहाँ Load Balancer TLS payload decrypt नहीं करता।

TLS connection Java Service पर terminate हो सकती है।

इसका लाभ:

• intermediary plaintext application payload नहीं देखता,
• cryptographic endpoint actual backend service हो सकता है।

लेकिन trade-off भी है।

अगर intermediary application-level HTTP content नहीं देख सकता, तो कुछ Layer-7 capabilities सीमित हो सकती हैं।

उदाहरण के लिए intermediary को request path, HTTP headers या application routing information inspect करने की आवश्यकता हो सकती है।

इसलिए passthrough हमेशा automatically "best" design नहीं है।

14. TLS Termination + Re-encryption#

एक बहुत common distributed pattern है:

यहाँ:

• पहला TLS connection Client → Gateway है।
• Gateway उसे terminate करता है।
• Gateway application request inspect कर सकता है।
• फिर Gateway → Service के लिए नया TLS connection establish होता है।

यह traffic को दोनों network segments पर encrypt करता है।

लेकिन ध्यान रखें:

यह एक continuous TLS session नहीं है।

Gateway plaintext data access कर सकता है।

इसलिए इसे समझते समय "encrypted on every hop" और "single cryptographic end-to-end session" के बीच अंतर रखना चाहिए।

तीन architectures की तुलना#

कौन-सा सही है?

उत्तर architecture requirements पर निर्भर करता है।

यही system design trade-off है।

15. क्या Internal Network पर HTTP चलाना ठीक है?#

एक common सोच है:

"यह traffic private VPC के अंदर है, इसलिए encryption की आवश्यकता नहीं है।"

यह dangerous assumption हो सकती है।

English definition: Internal transport encryption protects service-to-service communication even when traffic remains inside infrastructure controlled by the organization.

मान लीजिए:

User से Gateway तक protection है।

लेकिन Gateway के बाद sensitive information plaintext में move कर सकती है।

अगर internal environment का कोई workload compromise हो जाए या network visibility unexpectedly available हो, तो internal plaintext traffic risk बन सकता है।

Modern security thinking में network location को identity का substitute नहीं मानना चाहिए।

इसलिए sensitive distributed systems में internal TLS एक महत्वपूर्ण design consideration है।

16. Secure Service-to-Service Communication#

English definition: Secure service-to-service communication protects data and verifies communication participants when one backend service communicates with another.

Microservices architecture में browser ही केवल client नहीं होता।

एक service दूसरी service की client बन सकती है।

उदाहरण:

Order Service को Payment Service से बात करनी है।

यहाँ कम-से-कम दो questions हैं:

1. communication encrypted है?
2. Order Service को कैसे पता कि वह genuine Payment Service से बात कर रही है?

और एक तीसरा अलग सवाल भी है:

3. Payment Service को कैसे पता कि caller वास्तव में Order Service है?

पहले दो में TLS help कर सकता है।

तीसरे के लिए mutual authentication useful हो सकती है।

यहीं mTLS आता है।

17. Mutual TLS यानी mTLS#

English definition: Mutual TLS is a TLS configuration in which both communicating parties present and validate certificates, allowing both sides to authenticate each other's cryptographic identity.

Normal public HTTPS flow में आमतौर पर client server certificate validate करता है।

mTLS में दोनों तरफ verification होती है।

सरल mental model:

इससे service-to-service environment में cryptographic service identity establish करने में मदद मिलती है।

लेकिन यहाँ एक बहुत महत्वपूर्ण distinction है।

वह authorization का विषय है।

18. TLS Authentication और Application Authentication अलग हैं#

English definition: Transport authentication verifies the identity associated with the secure network connection, while application authentication verifies the identity of the application user, service principal, session, or API caller according to application-level rules.

मान लीजिए:

Client HTTPS से Java API को call करता है।

Request में OAuth access token भी है।

दोनों का purpose अलग है।

Layer 1: TLS#

यह transport channel protect करता है।

यह encryption, integrity और certificate-based identity verification provide कर सकता है।

Layer 2: Application Authentication#

यह पूछता है:

Caller कौन है?

उदाहरण:

• user token,
• session,
• OAuth access token,
• signed service credential।

Layer 3: Authorization#

यह पूछता है:

इस caller को क्या करने की अनुमति है?

उदाहरण:

• यह user order देख सकता है?
• यह service payment initiate कर सकती है?
• यह admin endpoint access कर सकता है?

इसलिए यह design गलत है:

"हम HTTPS use करते हैं, इसलिए authorization की आवश्यकता नहीं।"

और यह भी गलत है:

"हम JWT use करते हैं, इसलिए TLS की आवश्यकता नहीं।"

दोनों अलग threats address करते हैं।

19. Certificate क्या करता है?#

English definition: A digital certificate binds an identity, such as a hostname or service identity, to a public key and is signed within a trust system that a verifier can validate.

Certificate को digital identity document जैसा mental model दे सकते हैं।

Server कहता है:

"मैं api.example.com हूँ।"

लेकिन client केवल यह claim सुनकर trust नहीं करता।

Client certificate validation करता है।

High level पर client questions पूछता है:

• certificate trusted authority chain से जुड़ा है?
• certificate intended server identity से match करता है?
• certificate अभी valid period में है?
• certificate cryptographically valid है?

इसमें कई implementation details हो सकती हैं, लेकिन system design level पर इतना समझना आवश्यक है:

Certificate होना और certificate validate होना दो अलग चीजें हैं।

20. Certificate Trust Chain#

Certificate trust को एक chain की तरह समझ सकते हैं।

Client के पास trusted roots का एक trust store होता है।

Server certificate किसी trusted hierarchy से validate होना चाहिए।

अगर chain trusted नहीं है, तो secure client को connection reject करना चाहिए।

Java ecosystem में JVM/application trust configuration इस process में relevant हो सकती है।

लेकिन design principle वही है:

Unknown certificate को blindly accept मत कीजिए।

21. Hostname / Service Identity Validation क्यों जरूरी है?#

मान लीजिए certificate cryptographically valid है।

लेकिन वह किसी दूसरे server के लिए जारी किया गया है।

क्या client को उसे accept करना चाहिए?

नहीं।

Client को यह भी verify करना होता है कि certificate जिस identity के लिए valid है, वह intended destination के अनुरूप है।

इसलिए केवल:

"certificate signed है"

पर्याप्त नहीं है।

Identity matching भी आवश्यक है।

22. Certificate Validation Disable करना क्यों खतरनाक है?#

Development के दौरान कभी-कभी error मिलता है:

• self-signed certificate,
• unknown CA,
• hostname mismatch,
• expired certificate,
• incomplete certificate chain।

Beginner shortcut हो सकता है:

"SSL verification off कर देते हैं।"

इससे request चल सकती है।

लेकिन आपने security problem solve नहीं की।

आपने security check ही हटाया।

यह ऐसा है जैसे building के security guard ने ID reject की और आपने solution के रूप में guard को ही हटा दिया।

Correct approach है root cause ठीक करना।

उदाहरण:

• सही certificate deploy करें,
• सही trust chain provide करें,
• correct hostname use करें,
• trust store properly configure करें,
• expiration issue resolve करें।

23. Certificate Expiration#

English definition: Certificate expiration is the point after which a certificate is no longer considered valid according to its defined validity period.

Certificates forever-valid credentials नहीं होने चाहिए।

उनकी validity limited होती है।

यह security के लिए useful है।

लेकिन इससे operational responsibility आती है।

अगर production certificate expire हो गया, तो clients connection reject कर सकते हैं।

परिणाम:

• API unavailable,
• service-to-service calls fail,
• customer requests fail,
• cascading failures हो सकती हैं।

इसलिए certificate management केवल security team का paperwork नहीं है।

यह availability concern भी है।

24. Certificate Rotation#

English definition: Certificate rotation is the controlled replacement of certificates and related key material before old credentials become unusable or unsafe.

अच्छी rotation strategy में सामान्यतः यह सोच शामिल होती है:

1. certificate expiry monitor करें,
2. renewal expiry से काफी पहले शुरू करें,
3. automated issuance/renewal prefer करें,
4. new certificate deploy करें,
5. clients की trust compatibility verify करें,
6. rollout observe करें,
7. पुराने material को safe तरीके से retire करें।

जब केवल server certificate renew हो और same trusted CA hierarchy बनी रहे, तो client trust configuration को हमेशा बदलने की आवश्यकता नहीं होती।

लेकिन CA या trust-root rotation अधिक sensitive हो सकती है।

ऐसे case में overlap useful हो सकता है।

25. Trust Rotation में Overlap क्यों उपयोगी है?#

मान लीजिए services केवल पुराने CA पर trust करती हैं।

आप अचानक नया CA certificate deploy कर देते हैं।

कुछ clients नया chain trust नहीं करेंगे।

Outage हो सकती है।

Safer migration mental model:

यह controlled migration है।

26. Java Services में इसका Practical Meaning#

आपकी Java service TLS को स्वयं terminate कर सकती है या उसके सामने infrastructure component TLS terminate कर सकता है।

उदाहरण 1:

यहाँ Java service certificate और TLS endpoint manage करती है।

उदाहरण 2:

यहाँ external TLS Gateway पर terminate होती है और backend connection फिर से TLS से protected है।

उदाहरण 3:

Gateway और Java Service एक-दूसरे की service identity mutually verify कर सकते हैं।

System designer के रूप में आपको केवल Java configuration syntax नहीं देखना है।

आपको पूरा trust path देखना है।

27. Secure API Boundary को कैसे सोचें?#

पहले सीखी गई API boundary पर अब security layer जोड़ें।

मान लीजिए system architecture है:

अब हर arrow पर सवाल पूछिए:

Mobile App → API Gateway#

• TLS है?
• client server certificate validate करता है?
• sensitive data URL में तो नहीं है?

API Gateway → Order Service#

• communication encrypted है?
• Gateway की service identity verify होती है?
• backend service identity verify होती है?

Order Service → Payment Service#

• sensitive payment information protected है?
• दोनों services की identity establish होती है?
• authorization अलग से enforce होती है?

Order Service → Database#

• remote database traffic protected है?
• database server identity verify होती है?

इस तरह security architecture component list से नहीं, communication boundaries से evaluate करें।

28. Sensitive Data URL में क्यों नहीं रखना चाहिए?#

English definition: Sensitive data in URLs can be exposed through systems that record, display, forward, or retain URLs even when the network transport itself uses HTTPS.

मान लीजिए API है:

GET /reset-password?token=very-sensitive-token

HTTPS network transport को protect कर सकता है।

लेकिन URL कई अन्य जगहों पर दिखाई दे सकता है:

• application logs,
• reverse-proxy logs,
• monitoring systems,
• browser history,
• analytics systems,
• debugging traces,
• copied links,
• referrer behavior in some scenarios।

इसलिए यह सोच गलत है:

"HTTPS है, तो URL में कुछ भी डाल सकते हैं।"

TLS network transport protect करता है।

वह हर downstream logging या application-handling risk automatically solve नहीं करता।

Sensitive values को design करते समय purpose-specific safer location और handling strategy चुननी चाहिए।

29. क्या HTTPS पूरी Network Metadata छिपा देता है?#

नहीं।

TLS application payload के महत्वपूर्ण हिस्सों को protect करता है, लेकिन network communication का हर observable fact necessarily invisible नहीं हो जाता।

उदाहरण के लिए infrastructure को सामान्यतः यह पता हो सकता है कि:

• कौन-सा source IP communication कर रहा है,
• destination IP क्या है,
• कब connection हुआ,
• कितना traffic exchange हुआ।

Hostname discovery भी network architecture, DNS behavior और TLS/network features पर निर्भर कर सकती है।

System design में इसलिए precise statement use करें:

TLS application communication को secure करता है; वह network activity को magically invisible नहीं बनाता।

30. TLS और Logging#

TLS traffic को network path पर protect करता है।

लेकिन TLS termination के बाद application plaintext request देख सकती है।

अगर application फिर sensitive headers log कर दे, तो confidentiality फिर टूट सकती है।

उदाहरण:

इसलिए secure transport के साथ secure logging भी आवश्यक है।

Avoid logging:

• passwords,
• access tokens,
• session secrets,
• private keys,
• sensitive personal fields,
• unnecessary authorization headers।

Transport security एक layer है, complete data-protection strategy नहीं।

31. End-to-End Encryption शब्द को सावधानी से समझें#

English definition: End-to-end encryption means encryption is maintained between the intended cryptographic endpoints so that intermediaries outside those endpoints cannot read the protected content.

System design discussions में यह phrase कभी-कभी loosely use होती है।

दो architectures देखें।

Architecture A: TLS terminates at Gateway#

दोनों network segments encrypted हैं।

लेकिन Gateway plaintext देखता है।

इसलिए यह encrypted hop-by-hop communication है, जिसमें re-encryption है।

Architecture B: TLS passes through intermediary#

यहाँ intermediary TLS terminate नहीं करता।

Cryptographic endpoint service हो सकती है।

Interview में इसलिए केवल "end-to-end encrypted" कहने के बजाय exact termination points बताना बेहतर है।

32. TLS Termination और Load Balancing Trade-Off#

TLS passthrough से intermediary application data नहीं देखता।

लेकिन Layer-7 Load Balancer को कभी-कभी HTTP information चाहिए:

• host,
• path,
• headers,
• routing rules।

अगर TLS Load Balancer पर terminate होती है, तो वह ये capabilities provide कर सकता है।

लेकिन फिर Load Balancer trusted component बन जाता है।

इसलिए trade-off:

कोई universal answer नहीं है।

Design context matters।

33. TLS Performance Overhead#

English definition: TLS performance overhead is the additional computation, latency, memory, and operational work required to establish and maintain cryptographically protected connections.

TLS free नहीं है।

कुछ overhead आता है:

• connection establishment,
• cryptographic operations,
• certificate processing,
• encryption/decryption CPU cost,
• additional operational management।

लेकिन conclusion यह नहीं होना चाहिए:

"Performance चाहिए इसलिए encryption हटा दें।"

सही approach है:

Security requirement को maintain करते हुए performance optimize करें।

Modern systems इसके लिए approaches use कर सकते हैं जैसे:

• connection reuse,
• efficient connection pooling,
• session resumption where supported,
• properly sized infrastructure,
• optimized TLS libraries/runtime,
• hardware acceleration where appropriate,
• avoiding unnecessary connection churn।

34. Connection Reuse क्यों Useful है?#

अगर हर छोटे request के लिए बिल्कुल नया secure connection establish करना पड़े, तो setup work बार-बार होगा।

Long-lived connections या connection pooling setup overhead को amortize कर सकते हैं।

Java applications में HTTP clients और service clients अक्सर connection pools use करते हैं।

लेकिन pool use करना security validation skip करने का reason नहीं है।

पहली priority सही secure behavior है।

फिर performance tuning।

35. Secure Communication Architecture Example#

मान लीजिए हमें e-commerce platform design करना है।

Components:

• Web Client
• API Gateway
• Order Service
• Payment Service
• Inventory Service

एक reasonable security-oriented design:

इस design में:

External boundary#

Web Client → API Gateway

Public network communication TLS protected है।

Client Gateway certificate validate करता है।

Internal service boundary#

Gateway → Order Service

mTLS दोनों service identities establish करने में मदद कर सकता है।

Sensitive payment boundary#

Order Service → Payment Service

Traffic encrypted है और service identities mutually verified हैं।

Authorization#

Payment Service फिर भी business authorization perform कर सकती है।

उदाहरण:

• caller Order Service है,
• लेकिन क्या उसे refund operation call करने की permission है?

mTLS identity देता है।

Authorization policy permission decide करती है।

36. Service Mesh कहाँ मदद कर सकता है?#

Large microservices environment में हर service के लिए manually certificates issue, renew, distribute और rotate करना operationally कठिन हो सकता है।

Service-mesh style infrastructure कुछ environments में:

• workload identity,
• certificate issuance,
• mTLS,
• certificate rotation,
• policy enforcement

को automate करने में मदद कर सकता है।

लेकिन इससे complexity खत्म नहीं होती।

Complexity का location बदलता है।

अब आपको mesh control plane, policies, certificate authority, proxy behavior और observability समझनी होगी।

इसलिए interview में केवल:

"service mesh लगा देंगे"

कहना पर्याप्त नहीं है।

Explain करें कि आप कौन-सी problem solve कर रहे हैं।

37. TLS क्या नहीं करता?#

यह section बहुत महत्वपूर्ण है।

TLS powerful है, लेकिन यह हर security problem solve नहीं करता।

TLS अकेले नहीं रोकता:

• valid authenticated user द्वारा malicious business action,
• broken authorization,
• SQL injection,
• application vulnerability,
• insecure data logging,
• compromised server process,
• stolen valid application token का misuse,
• incorrect business logic।

इसे layers की तरह समझें।

हर layer अलग responsibility address करती है।

38. Common Insecure Shortcuts#

1. Certificate validation disable करना#

Problem solve नहीं होती।

Identity verification हट जाती है।

2. Internal network को automatically trusted मानना#

Compromised internal workloads और configuration mistakes को ignore किया जाता है।

3. केवल external TLS करना#

Gateway के बाद sensitive traffic plaintext रह सकती है।

4. HTTPS को authorization समझना#

Secure transport permissions decide नहीं करता।

5. Sensitive token URL में डालना#

Transport encryption के बाहर logs/history जैसे exposure paths हो सकते हैं।

6. Certificate renewal manually याद रखने पर निर्भर रहना#

Human memory production availability strategy नहीं है।

Monitoring और automation बेहतर हैं।

7. TLS termination points document न करना#

Team को पता ही नहीं चलता कि plaintext कहाँ available है।

39. Trust Boundary Review Checklist#

किसी architecture diagram में हर network arrow को देखिए।

हर arrow के लिए पूछिए:

1. कौन connect कर रहा है?
2. destination कौन है?
3. traffic encrypted है?
4. server identity verify होती है?
5. client identity verify करनी है?
6. TLS कहाँ terminate होती है?
7. termination के बाद plaintext कौन देख सकता है?
8. अगला hop encrypted है?
9. certificate कौन issue और rotate करता है?
10. failure होने पर क्या impact होगा?
11. sensitive data URL/log में leak हो सकती है?
12. authentication और authorization कहाँ enforce होते हैं?

अगर आप इन questions का जवाब दे सकते हैं, तो transport security architecture काफी स्पष्ट हो जाती है।

40. एक Design Scenario#

मान लीजिए architecture है:

User से Load Balancer तक traffic encrypted है।

लेकिन उसके बाद दोनों internal hops plaintext हैं।

अब business कहता है कि Payment Service sensitive financial information process करती है।

क्या केवल public HTTPS पर्याप्त है?

नहीं।

हम architecture को बदल सकते हैं:

अब हर network segment protected है।

Payment boundary पर mutual service identity भी establish की जा सकती है।

फिर भी authorization Payment Service में या appropriate policy layer पर separately enforce करनी होगी।

41. Failure Scenario: Certificate Expired#

मान लीजिए Payment Service का certificate expire हो गया।

Order Service connection establish नहीं कर पा रही।

Possible chain:

यह security failure ही नहीं, availability failure भी है।

इसलिए operations में:

• expiry monitoring,
• alerts,
• automated renewal,
• deployment validation,
• rotation testing

महत्वपूर्ण हैं।

42. Failure Scenario: Wrong Trust Configuration#

मान लीजिए server ने नया certificate deploy किया।

लेकिन कुछ Java service instances का trust store updated नहीं है।

Result:

कुछ instances connection accept करती हैं।

कुछ reject करती हैं।

अब intermittent failures आ सकती हैं।

यह debugging difficult बना सकता है।

इसलिए certificate changes को सामान्य application deployment जितनी operational discipline से handle करना चाहिए।

43. Security और Operational Complexity का Trade-Off#

Security controls complexity बढ़ा सकते हैं।

उदाहरण:

mTLS के साथ manage करना पड़ सकता है:

• certificate issuance,
• identity mapping,
• trust stores,
• certificate rotation,
• revocation strategy,
• debugging,
• observability।

लेकिन इसका मतलब यह नहीं कि control unnecessary है।

Design question यह है:

Risk के अनुसार कौन-सा security control justified है और उसे operationally reliable कैसे बनाया जाए?

High-value financial service और low-risk internal demo application की requirements अलग हो सकती हैं।

लेकिन sensitive production communication में convenience के लिए validation disable करना justified trade-off नहीं है।

44. Security, Performance और Operability Balance#

एक अच्छे system-design answer में तीनों dimensions दिखाई देने चाहिए।

Security#

• encrypted communication,
• certificate validation,
• appropriate service identity,
• least-trust assumptions।

Performance#

• connection reuse,
• pooling,
• capacity planning,
• avoiding unnecessary handshakes।

Operability#

• automated certificate renewal,
• expiration monitoring,
• clear ownership,
• safe rotation,
• observability।

Architecture तभी production-ready लगता है जब तीनों dimensions साथ सोचें।

45. System Design Interview में कैसे Explain करें?#

Interviewer पूछ सकता है:

"How would you secure communication between services?"

Weak answer:

"HTTPS use करेंगे।"

यह अधूरा है।

Better answer में reasoning दिखनी चाहिए।

एक professional structure:

अब इस answer का meaning समझें।

आप केवल technology name नहीं बता रहे।

आप बता रहे हैं:

• boundaries identify करेंगे,
• TLS placement decide करेंगे,
• internal communication evaluate करेंगे,
• mTLS का purpose समझते हैं,
• auth layers अलग रखते हैं,
• certificate lifecycle सोचते हैं,
• trust boundaries recognize करते हैं।

यही system-design reasoning है।

46. Interview Trade-Off Question#

Interviewer पूछ सकता है:

"Why not terminate TLS at the load balancer and use HTTP internally?"

आपका answer context-aware होना चाहिए।

आप कह सकते हैं:

यह balanced answer है।

आप blindly नहीं कह रहे:

"Internal HTTP हमेशा गलत है।"

आप risk explain कर रहे हैं और decision factors बता रहे हैं।

47. Interview में Draw करने लायक Diagram#

Diagram explain करते समय बोलें:

1. public traffic HTTPS है,
2. Gateway एक trust boundary है,
3. backend traffic भी encrypted है,
4. service-to-service identity के लिए mTLS use किया जा सकता है,
5. authorization application layer पर अलग है,
6. certificates automated lifecycle से manage होंगे।

यह concise और strong system-design explanation है।

48. Final Mental Model#

पूरे chapter को एक simple chain में याद रखिए:

49. Chapter Recap#

इस chapter से सबसे महत्वपूर्ण बातें:

• Network पर travel करने वाला sensitive data protect होना चाहिए।
• HTTPS का अर्थ HTTP communication को TLS से protect करना है।
• TLS confidentiality, integrity और server authentication provide करता है।
• TLS कहाँ terminate होती है, यह architecture का critical security decision है।
• TLS termination करने वाला component plaintext data देख सकता है।
• Gateway पर TLS terminate होने के बाद backend HTTP use करना internal plaintext exposure create कर सकता है।
• Re-encryption हर network hop को protect कर सकती है, लेकिन Gateway फिर भी plaintext देखता है।
• TLS passthrough intermediary को payload decrypt किए बिना traffic forward करने देता है।
• mTLS दोनों communicating services की cryptographic identity verify करने में मदद करता है।
• TLS authentication, application authentication और authorization अलग responsibilities हैं।
• Certificate validation में trust और intended identity verification महत्वपूर्ण हैं।
• Validation disable करना safe production solution नहीं है।
• Certificate expiry application outage में बदल सकती है।
• Renewal और rotation automate और monitor करनी चाहिए।
• Sensitive secrets URLs में रखना avoid करना चाहिए।
• TLS performance overhead real है, लेकिन encryption हटाना उसका सही solution नहीं है।
• System-design interview में हमेशा communication boundaries, TLS termination, internal encryption, service identity, certificate lifecycle और trade-offs explain करें।