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) म्हणून जन्माला आला, जो नेटस्केपने ९० च्या दशकाच्या मध्यात बनवला. जेव्हा IETF ने तो ताब्यात घेतला आणि १९९९ मध्ये त्याचं मानकीकरण केलं, तेव्हा त्यांनी त्याचं नाव Transport Layer Security ठेवलं — अंशतः नेटस्केपच्या ट्रेडमार्क ओझ्यापासून दूर राहण्यासाठी, अंशतः कारण ते डेटा transit मध्ये असताना सुरक्षित करतं [2]. हे नाव हेतू वर्णन करतं, OSI स्टॅकमधील त्याची जागा नव्हे.

OSI मॉडेलमध्ये त्याची प्रत्यक्ष जागा कुठे आहे

जर तुम्ही TLS ला सात-लेयर OSI मॉडेलमध्ये व्यवस्थित बसवण्याचा प्रयत्न केलात, तर तुम्हाला त्रास होईल, आणि ती तुमची चूक नाही. TLS वरील Wikipedia नोंद आणि अनेक नेटवर्क इंजिनिअर्स म्हणतात त्याप्रमाणे, TLS नीटपणे बसतच नाही [3]. सर्वात सामान्य प्रामाणिक वर्णन:

• ते ट्रान्सपोर्ट लेयरच्या (लेयर 4 / TCP) वर चालतं.
• ते अॅप्लिकेशन लेयरच्या (लेयर 7 / HTTP) खाली बसतं.
• OSI च्या भाषेत, ते जी कार्ये करतं — एन्क्रिप्शन, सेशन प्रस्थापन — ती साधारणपणे प्रेझेंटेशन (6) आणि सेशन (5) लेयर्सशी जुळतात.

TCP/IP मॉडेलमध्ये (जे प्रत्यक्ष इंटरनेटशी खरोखर जुळतं), वेगळी प्रेझेंटेशन किंवा सेशन लेयर नसते, त्यामुळे लोक त्यांच्या मूडनुसार TLS ला आळसाने “ट्रान्सपोर्ट” किंवा “अॅप्लिकेशन” खाली फाईल करतात. यापैकी एकही अचूकपणे बरोबर नाही. सर्वात बचाव करण्याजोगी गोष्ट तुम्ही म्हणू शकता: TLS हा एक सेशन/प्रेझेंटेशन-लेयर सुरक्षा प्रोटोकॉल आहे जो आपलं काम करण्यासाठी ट्रान्सपोर्ट-लेयर प्रोटोकॉलवर अवलंबून असतो [4].

हे टर्मिनेशनसाठी का महत्त्वाचं आहे? कारण TLS ही TCP ला गुंडाळणारी एक वेगळी लेयर असणं हेच नेमकं लोड बॅलन्सरला ते सोलून काढण्यास, त्याच्याशी व्यवहार करण्यास, आणि आतला ट्रॅफिक पुढे पाठवण्यास सक्षम करतं. जर एन्क्रिप्शन TCP मध्येच बेक केलेलं असतं, तर तुम्ही दोघांना स्वच्छपणे वेगळं करू शकला नसता. हे लेयरिंगच टर्मिनेशन एक संकल्पना म्हणून अस्तित्वात असण्याचं संपूर्ण कारण आहे.

मग TLS टर्मिनेशन म्हणजे काय?

TLS टर्मिनेशन म्हणजे तो बिंदू जिथे एन्क्रिप्टेड कनेक्शन संपतं आणि ट्रॅफिक डिक्रिप्ट होतो. एवढंच. “terminate” हा शब्द फक्त म्हणजे “इथे 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 ऑफलोडिंग तो अंतर्गत हॉप man-in-the-middle डोकावण्यासाठी उघडा ठेवू शकतो [8].

पासथ्रू

प्रॉक्सी काहीही डिक्रिप्ट करत नाही. तो एन्क्रिप्टेड स्ट्रीम बाइट-दर-बाइट बॅकएंडकडे पाठवतो, जो सर्टिफिकेट धारण करतो आणि स्वतः TLS टर्मिनेट करतो. हुशार प्रॉक्सी अजूनही ClientHello मधील अनएन्क्रिप्टेड SNI (Server Name Indication) फील्डमध्ये डोकावून हुशारीने राउट करतात — ते त्यांना पेलोड डिक्रिप्ट न करता क्लायंटला कोणतं होस्टनेम हवं आहे ते सांगतं [9].

फायदा खरी सुरक्षा आहे: क्लायंटपासून थेट बॅकएंडपर्यंत एन्क्रिप्शन अखंड असतं, डिक्रिप्शन फक्त गंतव्यस्थानी होतं. तोटा म्हणजे तुम्ही लेयर 7 वर सर्व काही गमावता — पाथ राउटिंग नाही, हेडर मॅनिप्युलेशन नाही, WAF नाही, कुकी-आधारित स्टिकी सेशन्स नाहीत. तुम्ही मुळात एक मूर्ख TCP पाईप आहात. जेव्हा बॅकएंड आधीच स्वतःचे सर्ट्स व्यवस्थापित करतात, किंवा जेव्हा अनुपालन (compliance) मागणी करतं की प्रॉक्सीने कधीही प्लेनटेक्स्ट पाहू नये, तेव्हा पासथ्रू अर्थपूर्ण ठरतं.

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

“केक ठेवा आणि खाही” हा पर्याय. प्रॉक्सी क्लायंटचं TLS टर्मिनेट करतो, डिक्रिप्ट करतो, त्याला हवी ती लेयर-7 जादू करतो, मग बॅकएंडकडे एक अगदी नवीन TLS कनेक्शन उघडतो आणि पाठवण्यापूर्वी पुन्हा एन्क्रिप्ट करतो [10]. Red Hat च्या OpenShift डॉक्स या “re-encrypt” रूट प्रकाराचं नेमकं असंच वर्णन करतात: TLS राउटरवर टर्मिनेट होतं, मग राउटर पॉडकडे ताजं एन्क्रिप्शन प्रस्थापित करतो [10].

तुम्हाला तपासणी आणि एक एन्क्रिप्टेड अंतर्गत हॉप दोन्ही मिळतात. किंमत म्हणजे दुप्पट क्रिप्टो काम आणि थोडं अधिक कॉन्फिग (आता तुम्ही दोन ठिकाणी सर्ट्स व्यवस्थापित करता). नियंत्रित वर्कलोड्ससाठी — HIPAA अंतर्गत आरोग्यसेवा डेटा, PCI-DSS अंतर्गत कार्ड डेटा — हे अनेकदा योग्य उत्तर असतं, कारण ते फ्रेमवर्क्स फक्त समोरच्या दरवाजावर नव्हे तर अविश्वासार्ह सेगमेंट्सवर transit मध्ये एन्क्रिप्शनची अपेक्षा करतात [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 कच्चे बाइट्स पाठवत नाही — ते संभाषणाचे रेकॉर्ड्स मध्ये तुकडे करतं. प्रत्येक रेकॉर्डला एक कंटेंट प्रकार असतो: handshake (22), application data (23), किंवा alert (21) [3]. TLS 1.3 मधील एक सुबक प्रायव्हसी युक्ती: खरा कंटेंट प्रकार एन्क्रिप्टेड पेलोडमध्ये लपवला जातो, आणि बाहेरचा हेडर नेहमी तो “application data” आहे असा दावा करतो. त्यामुळे एक नेटवर्क निरीक्षक हँडशेक संदेश तुमच्या प्रत्यक्ष ट्रॅफिकपासून वेगळेही ओळखू शकत नाही [3]. टर्मिनेशन करणाऱ्या गोष्टीला ही सर्व रेकॉर्ड यंत्रणा समजून घ्यावी लागते — हेच नेमकं कारण आहे की हे क्षुल्लक नसलेलं काम आहे जे तुम्हाला केंद्रीकृत करावंसं वाटेल.

SSL विरुद्ध TLS बद्दल एक शब्द, कारण या संज्ञा गोंधळलेल्या आहेत

तुम्हाला “SSL termination” आणि “TLS termination” सर्वत्र, AWS आणि Nginx डॉक्ससह, एकमेकांच्या जागी वापरलेलं दिसेल. तांत्रिकदृष्ट्या ते चुकीचं आहे, आणि हा या लेखाच्या सुरुवातीच्या त्याच नावाच्या गोंधळासारखाच आहे.

SSL मृत आहे. SSL च्या सर्व आवृत्त्या deprecated आणि असुरक्षित आहेत. IETF ने अधिकृतपणे जून २०१५ मध्ये SSL 3.0 ला मारलं, मुख्यतः २०१४ मध्ये Google संशोधकांनी शोधलेल्या POODLE हल्ल्या मुळे — एक एक्सप्लॉइट ज्याने हल्लेखोराला कनेक्शन SSL 3.0 वर डाउनग्रेड करू दिलं आणि सेशन कुकीज एका वेळी एक बाइट डिक्रिप्ट करू दिल्या [13]. TLS ने त्याला अधिक मजबूत सायफर्स, उत्तम प्रमाणीकरण, आणि नेमक्या त्या पॅडिंग आणि रीनेगोशिएशन छिद्रांच्या दुरुस्त्यांसह बदललं [13].

मग तरीही प्रत्येकजण “SSL” का म्हणतो? निव्वळ वारसा. ही संज्ञा ९० च्या दशकात आणि २००० च्या सुरुवातीच्या काळात उद्योगाच्या मेंदूत कोरली गेली, सर्टिफिकेट विक्रेते अजूनही “SSL certificates” विकतात, आणि लोक “TLS” पेक्षा “SSL” खूप जास्त शोधतात [14]. जेव्हा कोणी २०२६ मध्ये “SSL termination” म्हणतं, तेव्हा त्यांचा अर्थ जवळजवळ निश्चितपणे TLS termination असतो — खाली असलेला प्रोटोकॉल TLS 1.2 किंवा 1.3 असतो. शब्दसंग्रहाला तुम्हाला अडखळवू देऊ नका, पण तुमचं प्रत्यक्ष कॉन्फिग SSL आणि जुन्या TLS आवृत्त्या अक्षम करतं याची खात्री करा. जर तुम्हाला उत्सुकता असेल तर या आवृत्त्यांचा इतिहास The SSL Store ने छान मांडला आहे [15].

तुम्ही दुर्लक्ष करू शकत नाही असा सुरक्षा तडजोड

इथे मी ठाम मत मांडेन. साधं TLS टर्मिनेशन — एजवर डिक्रिप्ट, बॅकएंडकडे प्लेनटेक्स्ट — ठीक आहे जोपर्यंत ते ठीक नसतं तोपर्यंत. धोका अंतर्गत हॉप आहे. तुमच्या नेटवर्कच्या आत पाय रोवलेला कोणीही, एक चुकीचं कॉन्फिगर केलेला सिक्युरिटी ग्रुप, किंवा एक तडजोड झालेली शेजारची सेवा संभाव्यतः तो ट्रॅफिक वाचू शकते जो तुम्ही संरक्षित आहे असं गृहीत धरलं होतं कारण वापरकर्त्याला एक पॅडलॉक दिसलं.

बऱ्याच अंतर्गत-केवळ, चांगल्या प्रकारे विभागलेल्या सेटअप्ससाठी, तो धोका स्वीकारार्ह असतो आणि साधेपणा जिंकतो. पण ज्या क्षणी तुम्ही नियंत्रित डेटा हाताळता, तेव्हा पुनर्विचार करा:

• HIPAA अपेक्षा करतं की इलेक्ट्रॉनिक संरक्षित आरोग्य माहिती फक्त सार्वजनिक हॉपवर नव्हे तर अविश्वासार्ह नेटवर्क्सवर एन्क्रिप्टेड राहावी [11].
• PCI-DSS आणि तत्सम फ्रेमवर्क्स कार्डधारक डेटासाठी एंड टू एंड मजबूत एन्क्रिप्शनसाठी आग्रह करतात [11].
• Zero-trust आर्किटेक्चर्स डीफॉल्टनुसार अंतर्गत नेटवर्क शत्रुत्वाचं आहे असं गृहीत धरतात, ज्यामुळे प्लेनटेक्स्ट बॅकएंड हॉप्स पूर्णपणे बाद होतात.

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

मी देईन तो व्यावहारिक नियम: तुमची विश्वास सीमा कुठे आहे ते ठरवा, मग तुमचा टर्मिनेशन बिंदू त्या सीमेवर ठेवा. जर एज ही तुमची सीमा असेल, तर तिथे टर्मिनेट करा. जर तुम्हाला तुमच्या स्वतःच्या नेटवर्कवर विश्वास नसेल, तर री-एन्क्रिप्ट करा किंवा mTLS वापरा जेणेकरून संरक्षित झोन थेट अॅपपर्यंत विस्तारेल.

सर्व एकत्र आणणं

जर तुम्ही फक्त काही गोष्टी लक्षात ठेवल्या:

• नाव असूनही SSL/TLS हा ट्रान्सपोर्ट-लेयर प्रोटोकॉल नाही. तो TCP (खरा ट्रान्सपोर्ट) च्या वर चालतो आणि एका सेशन/प्रेझेंटेशन लेयर रॅपरसारखा वागतो. हेच लेयरिंग टर्मिनेशन मुळात शक्य करतं.
• TLS टर्मिनेशन म्हणजे फक्त ती जागा जिथे एन्क्रिप्शन संपतं आणि डिक्रिप्शन घडतं — सामान्यतः बॅकएंड CPU वाचवण्यासाठी, सर्ट्स केंद्रीकृत करण्यासाठी, आणि लेयर-7 राउटिंग व तपासणी अनलॉक करण्यासाठी लोड बॅलन्सर किंवा प्रॉक्सीकडे ढकललं जातं.
• तीन प्रकार आहेत: टर्मिनेट (प्लेनटेक्स्ट बॅकएंड), पासथ्रू (एन्क्रिप्टेड बॅकएंड, L7 नाही), आणि री-एन्क्रिप्ट (L7 सह एन्क्रिप्टेड बॅकएंड). तुम्ही तुमच्या अंतर्गत नेटवर्कवर विश्वास ठेवता की नाही यावर आधारित निवडा.
• “SSL” हा एक मृत प्रोटोकॉल आहे पण एक जिवंत शब्द आहे. जेव्हा लोक SSL termination म्हणतात तेव्हा त्यांचा अर्थ 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