TLS टर्मिनेशन की पूरी समझ (और क्या SSL वाकई ट्रांसपोर्ट लेयर है?)

दो सवाल लगातार आपस में घुलमिल जाते हैं: “TLS टर्मिनेशन क्या है” और “क्या SSL ट्रांसपोर्ट लेयर की चीज़ है?” लोग मान लेते हैं कि दूसरे का जवाब साफ़-साफ़ हाँ है — इसका नाम ही तो शाब्दिक रूप से Transport Layer Security है, है ना? खैर। इस नामकरण ने बहुत से समझदार लोगों को भी चकमा दिया है, और यह उलझन सीधे इस बात में रिस जाती है कि लोग टर्मिनेशन के बारे में कैसे सोचते हैं। तो मुझे दोनों को सुलझाने दीजिए, क्योंकि एक बार जब लेयर वाला सवाल समझ में आ जाता है, तो टर्मिनेशन जादू जैसा लगना बंद कर देता है।

लेयर वाले सवाल का छोटा जवाब

यह रहा सीधा-सपाट संस्करण: TLS ट्रांसपोर्ट लेयर पर नहीं चलता, भले ही इसके नाम में “Transport” लिखा हो। यह ट्रांसपोर्ट लेयर के ऊपर चलता है।

जब आपका ब्राउज़र HTTPS पर किसी सर्वर से बात करता है, तो असली ट्रांसपोर्ट अब भी TCP ही होता है। यह लेयर 4 है। TCP पोर्ट, सीक्वेंसिंग, रीट्रांसमिशन, और भरोसेमंद बाइट-स्ट्रीम वाली चीज़ें संभालता है। TLS उसके ऊपर बैठता है, बाइट्स को एन्क्रिप्शन में लपेटता है, और प्लेनटेक्स्ट को ऊपर आपके इस्तेमाल किए जा रहे ऐप्लिकेशन प्रोटोकॉल (HTTP, SMTP, IMAP, gRPC, जो भी हो) को सौंप देता है। आधिकारिक स्पेसिफ़िकेशन, RFC 8446, TLS 1.3 को एक ऐसे प्रोटोकॉल के रूप में बताती है जो “क्लाइंट/सर्वर ऐप्लिकेशन को इंटरनेट पर इस तरह संवाद करने देता है जिसे ताक-झाँक, छेड़छाड़, और संदेश की जालसाज़ी रोकने के लिए डिज़ाइन किया गया है” — और यह साफ़ तौर पर अपने नीचे TCP जैसे किसी भरोसेमंद ट्रांसपोर्ट को मानकर चलती है [1]।

तो नाम में “Transport” क्यों? ईमानदारी से कहें तो यह ज़्यादातर ब्रांडिंग का एक ऐतिहासिक हादसा है। इस प्रोटोकॉल ने अपनी ज़िंदगी SSL (Secure Sockets Layer) के रूप में शुरू की थी, जिसे Netscape ने 90 के दशक के मध्य में बनाया था। जब IETF ने इसे अपने हाथ में लिया और 1999 में इसे मानकीकृत किया, तो उन्होंने इसका नाम बदलकर Transport Layer Security रखा — कुछ हद तक Netscape के ट्रेडमार्क के झंझट से बचने के लिए, और कुछ हद तक इसलिए क्योंकि यह ट्रांज़िट में मौजूद डेटा को सुरक्षित करता है [2]। यह नाम इरादे को बताता है, OSI स्टैक में इसकी जगह को नहीं।

OSI मॉडल में यह असल में कहाँ फ़िट होता है

अगर आप TLS को सात-लेयर वाले OSI मॉडल में सफ़ाई से बिठाने की कोशिश करेंगे, तो आपको मुश्किल होगी, और यह आपकी गलती नहीं है। जैसा कि TLS पर विकिपीडिया की एंट्री और बहुत से नेटवर्क इंजीनियर कहते हैं, TLS बस सफ़ाई से फ़िट नहीं होता [3]। सबसे आम ईमानदार वर्णन:

• यह ट्रांसपोर्ट लेयर (लेयर 4 / TCP) के ऊपर चलता है।
• यह ऐप्लिकेशन लेयर (लेयर 7 / HTTP) के नीचे बैठता है।
• OSI शब्दावली में, इसके किए जाने वाले काम — एन्क्रिप्शन, सेशन की स्थापना — मोटे तौर पर प्रेज़ेंटेशन (6) और सेशन (5) लेयर पर मैप होते हैं।

TCP/IP मॉडल में (जो असल इंटरनेट से मेल खाता है), कोई अलग प्रेज़ेंटेशन या सेशन लेयर नहीं होती, इसलिए लोग अक्सर अपने मूड के हिसाब से TLS को आलसी ढंग से “ट्रांसपोर्ट” या “ऐप्लिकेशन” के खाते में डाल देते हैं। दोनों में से कोई भी ठीक-ठीक सही नहीं है। सबसे टिकाऊ बात जो आप कह सकते हैं: TLS एक सेशन/प्रेज़ेंटेशन-लेयर सुरक्षा प्रोटोकॉल है जो अपना काम करने के लिए एक ट्रांसपोर्ट-लेयर प्रोटोकॉल पर निर्भर करता है [4]।

यह टर्मिनेशन के लिए मायने क्यों रखता है? क्योंकि TLS का TCP को लपेटने वाली एक अलग लेयर होना बिल्कुल वही चीज़ है जो किसी लोड बैलेंसर को इसे छीलकर, संभालकर, और भीतरी ट्रैफ़िक को आगे भेजने देती है। अगर एन्क्रिप्शन खुद TCP में ही पका हुआ होता, तो आप दोनों को सफ़ाई से अलग नहीं कर पाते। यह लेयरिंग ही पूरी वजह है कि टर्मिनेशन एक अवधारणा के रूप में मौजूद है।

तो TLS टर्मिनेशन है क्या?

TLS टर्मिनेशन वह बिंदु है जहाँ एन्क्रिप्टेड कनेक्शन खत्म होता है और ट्रैफ़िक डिक्रिप्ट हो जाता है। बस इतना ही। “टर्मिनेट” शब्द का मतलब बस इतना है कि “यहीं TLS टनल रुकती है।”

एक साधारण दुनिया में, वह बिंदु आपका ऐप्लिकेशन सर्वर होता है। क्लाइंट सीधे आपके ऐप तक एक HTTPS कनेक्शन खोलता है, ऐप के पास सर्टिफ़िकेट और प्राइवेट की होती है, यह रिक्वेस्ट को डिक्रिप्ट करता है, प्रोसेस करता है, रिस्पॉन्स को एन्क्रिप्ट करता है। एंड टू एंड, एक ही हॉप।

लेकिन बड़े पैमाने पर लगभग कोई भी इसे इस तरह नहीं चलाता। इसके बजाय, आप आगे कुछ रखते हैं — एक लोड बैलेंसर, Nginx या HAProxy जैसा कोई रिवर्स प्रॉक्सी, एक API गेटवे, एक CDN एज नोड। वह आगे वाला डिवाइस TLS हैंडशेक करता है, ट्रैफ़िक को डिक्रिप्ट करता है, और अब प्लेनटेक्स्ट बन चुकी रिक्वेस्ट को आपके बैकएंड सर्वरों को आगे भेज देता है, आमतौर पर किसी भरोसेमंद आंतरिक नेटवर्क पर सादे HTTP के ज़रिए [5]। “टर्मिनेशन” आपके ऐप से हटकर एज पर आ गया है। इसे SSL ऑफ़लोडिंग भी कहते हैं, क्योंकि आप क्रिप्टोग्राफ़िक काम को अपने बैकएंड से उतारकर कहीं और डाल रहे होते हैं।

यह रहा एक ठोस चित्र। एक यूज़र https://yourshop.com पर पहुँचता है। रिक्वेस्ट आपके लोड बैलेंसर पर उतरती है। लोड बैलेंसर:

1. ब्राउज़र के साथ TLS हैंडशेक पूरा करता है।
2. सर्टिफ़िकेट को मान्य करता है और प्रस्तुत करता है।
3. आने वाली बाइट्स को एक सामान्य HTTP रिक्वेस्ट में डिक्रिप्ट करता है।
4. उस रिक्वेस्ट को आपके किसी बैकएंड ऐप सर्वर (http://10.0.1.42:8080) को आगे भेजता है।
5. बैकएंड के सादे HTTP रिस्पॉन्स को लेता है, उसे फिर से एन्क्रिप्ट करता है, और ब्राउज़र को वापस भेज देता है।

ब्राउज़र को लगता है कि उसने yourshop.com के साथ एक सुरक्षित बातचीत की — और उसने की भी, पूरे रास्ते लोड बैलेंसर तक। आपके बैकएंड ने एन्क्रिप्शन की एक भी बाइट को कभी नहीं छुआ।

एज पर टर्मिनेट करने की झंझट क्यों उठाएँ?

यह अतिरिक्त कदम जोड़ें ही क्यों? कुछ वाकई अच्छे कारण हैं:

• यह आपके बैकएंड को क्रिप्टो के काम से बचाता है। TLS हैंडशेक और भारी एन्क्रिप्शन CPU खर्च करते हैं। यह सारा काम समर्पित लोड बैलेंसर (अक्सर हार्डवेयर एक्सेलरेशन के साथ) पर धकेलने से आपके ऐप्लिकेशन सर्वर असल में ऐप्लिकेशन लॉजिक चलाने के लिए मुक्त हो जाते हैं [6]।
• सर्टिफ़िकेट मैनेजमेंट समझदारी भरा हो जाता है। पचास ऐप सर्वरों पर सर्टिफ़िकेट और प्राइवेट की कॉपी करने और उन सबको रिन्यू करने के बजाय, आप एक ही सर्टिफ़िकेट को एक ही जगह संभालते हैं। AWS Certificate Manager जैसे टूल बिना डाउनटाइम के अपने-आप रिन्यू और रोटेट भी कर देंगे [7]।
• आप लेयर-7 फ़ीचर्स खोल देते हैं। एक बार ट्रैफ़िक डिक्रिप्ट हो जाने के बाद, प्रॉक्सी उसे पढ़ सकता है। इसका मतलब है पाथ-आधारित रूटिंग, हेडर रीराइट, स्टिकी सेशन, रिक्वेस्ट-स्तरीय मेट्रिक्स, रिस्पॉन्स कंप्रेशन, कैशिंग, और Web Application Firewall (WAF) निरीक्षण। बाइट्स के अब भी एन्क्रिप्टेड होते हुए इनमें से कुछ भी संभव नहीं है [8]।
• स्केलिंग आसान होती है। एक नया बैकएंड इंस्टेंस चालू करें और उसे बस सादा HTTP बोलने की ज़रूरत होती है। कोई TLS कॉन्फ़िग नहीं, प्रति नोड कोई सर्टिफ़िकेट प्रोविज़निंग नहीं।

लेयर-7 फ़ीचर्स वाला वह आख़िरी बिंदु ही वह है जिसे लोग कम आँकते हैं। एक लोड बैलेंसर URL पाथ के आधार पर रूट नहीं कर सकता — जैसे, /api/* को एक पूल पर और /images/* को दूसरे पर भेजना — अगर वह URL देख ही न सके। और जब तक रिक्वेस्ट एन्क्रिप्टेड है, वह URL नहीं देख सकता। दृश्यता के लिए डिक्रिप्शन ज़रूरी है। यह अकेली बात TLS के इर्द-गिर्द के ज़्यादातर आर्किटेक्चरल फ़ैसलों को चलाती है।

तीन मॉडल: टर्मिनेशन, पासथ्रू, और री-एन्क्रिप्शन

TLS टर्मिनेशन कोई एक ही चीज़ नहीं है — यह तीन पैटर्न में से एक है, और गलत वाला चुनने से असली तकलीफ़ होती है। यहाँ देखिए ये कैसे टिकते हैं।

टर्मिनेशन / ऑफ़लोडिंग

वही डिफ़ॉल्ट जिसका हमने अभी वर्णन किया। एज पर डिक्रिप्ट करो, बैकएंड को सादा HTTP। अधिकतम फ़ीचर्स, सबसे सरल बैकएंड। पेच यह है: आपके लोड बैलेंसर और आपके ऐप सर्वरों के बीच का ट्रैफ़िक बिना एन्क्रिप्शन के सफ़र करता है। किसी कसी हुई प्राइवेट VPC पर यह अक्सर स्वीकार्य होता है। किसी साझा या अविश्वसनीय नेटवर्क पर, यह एक जोखिम है — अगर कोई आपके नेटवर्क के भीतर घुस जाए, तो SSL ऑफ़लोडिंग उस आंतरिक हॉप को मैन-इन-द-मिडल ताक-झाँक के लिए खुला छोड़ सकती है [8]।

पासथ्रू

प्रॉक्सी कुछ भी डिक्रिप्ट नहीं करता। यह एन्क्रिप्टेड स्ट्रीम को बाइट-दर-बाइट बैकएंड को आगे भेज देता है, जो सर्टिफ़िकेट रखता है और खुद TLS टर्मिनेट करता है। चतुर प्रॉक्सी अब भी ClientHello में मौजूद बिना एन्क्रिप्ट किए गए SNI (Server Name Indication) फ़ील्ड में झाँककर समझदारी से रूट करते हैं — यह उन्हें पेलोड डिक्रिप्ट किए बिना ही बता देता है कि क्लाइंट किस होस्टनेम को चाहता है [9]।

इसका फ़ायदा असली सुरक्षा है: एन्क्रिप्शन क्लाइंट से लेकर पूरे रास्ते बैकएंड तक अटूट रहता है, डिक्रिप्शन केवल मंज़िल पर होता है। नुकसान यह है कि आप लेयर 7 पर सब कुछ खो देते हैं — कोई पाथ रूटिंग नहीं, कोई हेडर हेरफेर नहीं, कोई WAF नहीं, कोई कुकी-आधारित स्टिकी सेशन नहीं। आप मूलतः एक बेअक्ल TCP पाइप होते हैं। पासथ्रू तब समझ में आता है जब बैकएंड पहले से ही अपने सर्टिफ़िकेट संभालते हैं, या जब कंप्लायंस की माँग हो कि प्रॉक्सी कभी प्लेनटेक्स्ट न देखे।

री-एन्क्रिप्शन / TLS ब्रिजिंग

“आम के आम और गुठलियों के दाम” वाला विकल्प। प्रॉक्सी क्लाइंट के TLS को टर्मिनेट करता है, डिक्रिप्ट करता है, ज़रूरत के मुताबिक जो भी लेयर-7 जादू करना हो वह करता है, फिर बैकएंड के लिए एक बिल्कुल नया TLS कनेक्शन खोलता है और आगे भेजने से पहले उसे फिर से एन्क्रिप्ट करता है [10]। Red Hat के OpenShift दस्तावेज़ इस “री-एन्क्रिप्ट” रूट प्रकार का ठीक यही वर्णन करते हैं: TLS राउटर पर टर्मिनेट होता है, फिर राउटर पॉड के लिए ताज़ा एन्क्रिप्शन स्थापित करता है [10]।

आपको निरीक्षण और एक एन्क्रिप्टेड आंतरिक हॉप दोनों मिलते हैं। इसकी कीमत है दोगुना क्रिप्टो काम और थोड़ी ज़्यादा कॉन्फ़िग (अब आप दो जगहों पर सर्टिफ़िकेट संभालते हैं)। नियंत्रित वर्कलोड के लिए — HIPAA के तहत हेल्थकेयर डेटा, PCI-DSS के तहत कार्ड डेटा — यह अक्सर सही जवाब होता है, क्योंकि वे ढाँचे केवल सामने के दरवाज़े पर नहीं, बल्कि अविश्वसनीय हिस्सों में ट्रांज़िट के दौरान एन्क्रिप्शन की अपेक्षा करते हैं [11]।

जब TLS “टर्मिनेट” होता है तो असल में क्या होता है

TLS को टर्मिनेट करने के लिए आपको हैंडशेक पूरा करना होता है, इसलिए यह जानना ज़रूरी है कि इसमें क्या शामिल है। लोग इसे एक जादुई कदम के रूप में सोचते हैं, लेकिन यह क्लाइंट और सर्वर के बीच एक तय किया गया नृत्य है। यह रहा TLS 1.3 का प्रवाह, मोटे तौर पर [1]:

1. ClientHello — ब्राउज़र नमस्ते कहता है, अपने समर्थित सिफर सूट और TLS संस्करण गिनाता है, और (1.3 में) एक राउंड ट्रिप बचाने के लिए अपना की-शेयर अनुमान पहले ही डाल देता है।
2. ServerHello — सर्वर एक सिफर सूट चुनता है, अपना की-शेयर भेजता है, और लगभग तुरंत एन्क्रिप्ट करना शुरू कर देता है।
3. Certificate + सत्यापन — सर्वर अपने सर्टिफ़िकेट से अपनी पहचान साबित करता है; क्लाइंट उसे भरोसेमंद Certificate Authorities के विरुद्ध जाँचता है।
4. Finished — दोनों पक्ष पुष्टि करते हैं कि उन्होंने वही सेशन कीज़ निकाली हैं, और यहाँ से सब कुछ तेज़ सिमेट्रिक क्रिप्टो से एन्क्रिप्ट होता है।

TLS 1.3 यहाँ एक बड़ी बात है क्योंकि इसने हैंडशेक को दो राउंड ट्रिप से घटाकर एक कर दिया, और लौटने वाले क्लाइंट के लिए 0-RTT रिज़म्प्शन तक का समर्थन करता है [1]। अगर आपने कभी सोचा हो कि आधुनिक HTTPS साइटें सालों पहले की तुलना में ज़्यादा फुर्तीली क्यों महसूस होती हैं, तो यह दुबला हैंडशेक उसका एक बड़ा हिस्सा है। अगर आप तार पर हर फ़ील्ड देखना चाहते हैं तो The Illustrated TLS 1.3 Connection पर एक शानदार बाइट-दर-बाइट विवरण मौजूद है [12]।

एक बार हैंडशेक खत्म हो जाने के बाद, TLS कच्ची बाइट्स नहीं भेजता — यह बातचीत को रिकॉर्ड्स में काट देता है। हर रिकॉर्ड का एक कंटेंट टाइप होता है: हैंडशेक (22), ऐप्लिकेशन डेटा (23), या अलर्ट (21) [3]। TLS 1.3 में एक बढ़िया प्राइवेसी तरकीब: असली कंटेंट टाइप एन्क्रिप्टेड पेलोड के भीतर छिपा दिया जाता है, और बाहरी हेडर हमेशा यह दावा करता है कि यह “ऐप्लिकेशन डेटा” है। तो एक नेटवर्क पर नज़र रखने वाला यह तक नहीं बता सकता कि कौन से हैंडशेक संदेश हैं और कौन सा आपका असली ट्रैफ़िक [3]। टर्मिनेशन करने वाली चीज़ को इस पूरी रिकॉर्ड मशीनरी को समझना होता है — यही ठीक वह कारण है कि यह ऐसा गैर-मामूली काम है जिसे आप केंद्रीकृत करना चाहेंगे।

SSL बनाम TLS पर एक बात, क्योंकि ये शब्द गड़बड़ हैं

आप हर जगह “SSL टर्मिनेशन” और “TLS टर्मिनेशन” को एक-दूसरे के बदले इस्तेमाल होते देखेंगे, AWS और Nginx दस्तावेज़ों समेत। तकनीकी रूप से यह गलत है, और यह वही नामकरण वाली उलझन है जो इस लेख की शुरुआत में थी।

SSL मर चुका है। SSL के सभी संस्करण अप्रचलित और असुरक्षित हैं। IETF ने जून 2015 में SSL 3.0 को आधिकारिक रूप से खत्म कर दिया, मुख्यतः 2014 में Google के शोधकर्ताओं द्वारा खोजे गए POODLE अटैक के कारण — एक ऐसा शोषण जो हमलावर को कनेक्शन को SSL 3.0 तक नीचे गिराकर सेशन कुकीज़ को एक-एक बाइट करके डिक्रिप्ट करने देता था [13]। TLS ने इसकी जगह मज़बूत सिफर, बेहतर प्रमाणीकरण, और ठीक उन्हीं पैडिंग व रीनेगोशिएशन के छेदों के सुधार के साथ ले ली [13]।

तो हर कोई अब भी “SSL” क्यों कहता है? निरी विरासत। यह शब्द 90 के दशक और 2000 के दशक की शुरुआत में उद्योग के दिमाग में जल कर बैठ गया, सर्टिफ़िकेट विक्रेता अब भी “SSL सर्टिफ़िकेट” बेचते हैं, और लोग “TLS” से कहीं ज़्यादा “SSL” खोजते हैं [14]। जब कोई 2026 में “SSL टर्मिनेशन” कहता है, तो उसका लगभग निश्चित रूप से मतलब TLS टर्मिनेशन होता है — नीचे का प्रोटोकॉल TLS 1.2 या 1.3 ही होता है। शब्दावली को आपको लड़खड़ाने न दें, लेकिन यह ज़रूर पक्का करें कि आपकी असली कॉन्फ़िग SSL और पुराने TLS संस्करणों को बंद कर दे। इन संस्करणों का इतिहास, अगर आप उत्सुक हों, तो The SSL Store ने बढ़िया ढंग से समझाया है [15]।

वह सुरक्षा समझौता जिसे आप नज़रअंदाज़ नहीं कर सकते

यहाँ मैं अपनी राय रखूँगा। सादा TLS टर्मिनेशन — एज पर डिक्रिप्ट, बैकएंड को प्लेनटेक्स्ट — तब तक ठीक है जब तक यह ठीक नहीं रहता। जोखिम आंतरिक हॉप का है। आपके नेटवर्क के भीतर पैर जमाए कोई भी, एक गलत-कॉन्फ़िगर सिक्योरिटी ग्रुप, या एक समझौता किया हुआ पड़ोसी सर्विस संभावित रूप से उस ट्रैफ़िक को पढ़ सकता है जिसे आपने सुरक्षित मान लिया था क्योंकि यूज़र को एक ताला दिखा था।

बहुत सारे केवल-आंतरिक, अच्छी तरह विभाजित सेटअप के लिए, वह जोखिम स्वीकार्य है और सरलता जीत जाती है। लेकिन जैसे ही आप नियंत्रित डेटा संभाल रहे हों, इस पर फिर से सोचें:

• HIPAA अपेक्षा करता है कि इलेक्ट्रॉनिक संरक्षित स्वास्थ्य जानकारी अविश्वसनीय नेटवर्कों में एन्क्रिप्टेड रहे, केवल सार्वजनिक हॉप पर नहीं [11]।
• PCI-DSS और इसी तरह के ढाँचे कार्डधारक डेटा के लिए एंड टू एंड मज़बूत एन्क्रिप्शन पर ज़ोर देते हैं [11]।
• ज़ीरो-ट्रस्ट आर्किटेक्चर डिफ़ॉल्ट रूप से आंतरिक नेटवर्क को शत्रुतापूर्ण मानते हैं, जो प्लेनटेक्स्ट बैकएंड हॉप को पूरी तरह बाहर कर देता है।

यहीं म्यूचुअल TLS (mTLS) आता है। सामान्य TLS केवल सर्वर को क्लाइंट के सामने प्रमाणित करता है। mTLS एक दूसरी जाँच जोड़ता है: क्लाइंट भी एक सर्टिफ़िकेट प्रस्तुत करता है, ताकि दोनों पक्ष क्रिप्टोग्राफ़िक रूप से साबित करें कि वे कौन हैं [16]। एक माइक्रोसर्विसेज़ मेश में, सर्विसों के बीच mTLS का मतलब है कि एक बदमाश पॉड आपकी पेमेंट सर्विस से यूँ ही बात करना शुरू नहीं कर सकता — उसके पास एक मान्य सर्टिफ़िकेट नहीं है। आपका लोड बैलेंसर क्लाइंट से आने वाले mTLS को टर्मिनेट कर सकता है और अलग से बैकएंड के लिए mTLS स्थापित कर सकता है [11]। Google Cloud, Istio, और ज़्यादातर सर्विस मेश अब इसे अपने भीतर पका कर रखते हैं [16]।

व्यावहारिक नियम जो मैं दूँगा: तय करें कि आपकी ट्रस्ट सीमा कहाँ है, फिर अपने टर्मिनेशन बिंदु को उस सीमा पर रखें। अगर एज आपकी सीमा है, तो वहीं टर्मिनेट करें। अगर आप अपने ही नेटवर्क पर भरोसा नहीं करते, तो री-एन्क्रिप्ट करें या mTLS का इस्तेमाल करें ताकि सुरक्षित क्षेत्र पूरे रास्ते ऐप तक फैल जाए।

सब मिलाकर

अगर आपको बस कुछ चीज़ें याद रखनी हों:

• SSL/TLS एक ट्रांसपोर्ट-लेयर प्रोटोकॉल नहीं है नाम के बावजूद। यह TCP (असली ट्रांसपोर्ट) के ऊपर सवारी करता है और एक सेशन/प्रेज़ेंटेशन लेयर रैपर की तरह बर्ताव करता है। वही लेयरिंग ही टर्मिनेशन को मुमकिन बनाती है।
• TLS टर्मिनेशन बस वह जगह है जहाँ एन्क्रिप्शन खत्म होता है और डिक्रिप्शन होता है — आमतौर पर बैकएंड CPU बचाने, सर्टिफ़िकेट केंद्रीकृत करने, और लेयर-7 रूटिंग व निरीक्षण खोलने के लिए किसी लोड बैलेंसर या प्रॉक्सी पर धकेल दिया जाता है।
• तीन किस्में हैं: टर्मिनेट (प्लेनटेक्स्ट बैकएंड), पासथ्रू (एन्क्रिप्टेड बैकएंड, कोई L7 नहीं), और री-एन्क्रिप्ट (एन्क्रिप्टेड बैकएंड के साथ L7)। इस आधार पर चुनें कि आप अपने आंतरिक नेटवर्क पर भरोसा करते हैं या नहीं।
• “SSL” एक मरा हुआ प्रोटोकॉल है लेकिन एक ज़िंदा शब्द। जब लोग SSL टर्मिनेशन कहते हैं तो उनका मतलब TLS होता है।

अगली बार जब कोई आत्मविश्वास से आपको बताए कि SSL “ट्रांसपोर्ट लेयर की चीज़” है, तो आप शालीनता से यह बता सकते हैं कि नाम मार्केटिंग है, आर्किटेक्चर नहीं — और यह फ़र्क समझना ही वह चीज़ है जो आपको साफ़-साफ़ सोचने देती है कि कहाँ टर्मिनेट करना है।

स्रोत

1. RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3
2. SSL Deprecation: Why TLS took over internet security — Sectigo
3. Transport Layer Security — Wikipedia
4. Transport Layer Security — which layer of OSI model? — Medium
5. What is SSL/TLS termination? — HAProxy
6. New – TLS Termination for Network Load Balancers — AWS
7. Understanding TLS Termination with Load Balancers in AWS — Cloudericks
8. TLS Termination Models: Passthrough vs Termination vs Bridging — DEV Community
9. Understanding Nginx: TLS Termination vs. TLS Passthrough — Medium
10. 3 ways to encrypt communications with Red Hat OpenShift
11. Is TLS Enough for HIPAA? — HIPAA Vault
12. The Illustrated TLS 1.3 Connection: Every Byte Explained
13. SSL vs TLS: What’s the Difference — Authgear
14. Is SSL Deprecated? Transition from SSL to TLS — SSL Dragon
15. SSL and TLS Versions: Celebrating 30 Years of History — The SSL Store
16. Mutual TLS overview — Google Cloud Load Balancing