सुरक्षित वेब सेवाएँ: HTTPS बनाम SOAP + WS-Security पर REST। कौनसा अच्छा है? [बन्द है]

Question

मैं किसी भी तरह से सुरक्षा विशेषज्ञ नहीं हूं, लेकिन मैं रीस्ट-स्टाइल वेब सेवाओं का निर्माण करने का समर्थन करता हूं।

एक नई सेवा बनाने के लिए जिसके पास डेटा होना आवश्यक है वह सुरक्षित है। हमने एक बहस में प्रवेश किया है कि कौन सा दृष्टिकोण अधिक सुरक्षित है - HTTPS के साथ REST या WS-Security के साथ SOAP WS।

मैं इस धारणा के तहत हूं कि हम सभी वेब सेवा कॉल के लिए HTTPS का उपयोग कर सकते हैं और यह दृष्टिकोण सुरक्षित होगा। जिस तरह से मैं इसे देखता हूं, "अगर HTTPS बैंक और वित्तीय वेब साइटों के लिए पर्याप्त है, तो यह मेरे लिए काफी अच्छा है"। फिर से, मैं इस स्थान में विशेषज्ञ नहीं हूं, लेकिन मुझे लगता है कि इन लोगों ने इस समस्या के बारे में बहुत कठिन सोचा है और HTTPS के साथ सहज हैं।

एक सहकर्मी असहमत है और कहता है कि SOAP और WS-Security एकमात्र रास्ता है।

इस पर बोर्ड भर में वेब लगता है।

हो सकता है कि यहां का समुदाय प्रत्येक के पेशेवरों और विपक्षों को तौल सकता है? धन्यवाद!

Comments

मूल रूप से परिवहन स्तर की सुरक्षा और संदेश स्तर की सुरक्षा का एक विकल्प है

— फ्लैश

बस जोड़ने के लिए .. iseebug.com/category/web-service

— वाइब्स

Answer 1

HTTPS नेटवर्क पर संदेश के प्रसारण को सुरक्षित करता है और क्लाइंट को सर्वर की पहचान के बारे में कुछ आश्वासन प्रदान करता है। यह आपके बैंक या ऑनलाइन स्टॉक ब्रोकर के लिए महत्वपूर्ण है। क्लाइंट को प्रमाणित करने में उनकी रुचि कंप्यूटर की पहचान में नहीं, बल्कि आपकी पहचान में है। तो कार्ड नंबर, उपयोगकर्ता नाम, पासवर्ड आदि का उपयोग आपको प्रमाणित करने के लिए किया जाता है। कुछ सावधानियों को आमतौर पर यह सुनिश्चित करने के लिए लिया जाता है कि सबमिशन के साथ छेड़छाड़ नहीं की गई है, लेकिन पूरे सत्र में जो कुछ भी होता है उसे आपके द्वारा शुरू किया गया माना जाता है।

WS-Security संदेश के निर्माण से लेकर उसके उपभोग तक की गोपनीयता और अखंडता सुरक्षा प्रदान करता है। इसलिए यह सुनिश्चित करने के बजाय कि संचार की सामग्री केवल सही सर्वर द्वारा पढ़ी जा सकती है यह सुनिश्चित करता है कि इसे केवल सर्वर पर सही प्रक्रिया द्वारा पढ़ा जा सकता है। यह मानने के बजाय कि सुरक्षित रूप से शुरू किए गए सत्र में सभी संचार प्रमाणीकृत उपयोगकर्ता के हैं, जिनमें से प्रत्येक पर हस्ताक्षर किए जाने हैं।

यहाँ नग्न मोटरसाइकिल चलाने वाले एक मनोरंजक स्पष्टीकरण है:

https://docs.microsoft.com/archive/blogs/vbertocci/end-to-end-security-or-why-you-shouldnt-drive-your-motorcycle-naked

इसलिए WS-Security HTTPS से अधिक सुरक्षा प्रदान करता है, और SOAP REST की तुलना में अधिक समृद्ध API प्रदान करता है। मेरी राय है कि जब तक आपको वास्तव में अतिरिक्त सुविधाओं या सुरक्षा की आवश्यकता नहीं है, तब तक आपको SOAP और WS-Security के ओवरहेड को छोड़ देना चाहिए। मुझे पता है कि यह एक पुलिस-आउट का एक सा है, लेकिन वास्तव में कितना संरक्षण के बारे में फैसले (न सिर्फ निर्माण करने के लिए अच्छा होगा) क्या उन लोगों द्वारा किए जाने की आवश्यकता है जो समस्या को गहनता से जानते हैं।

Comments

एक अतिरिक्त बिंदु - ट्रांसमिशन सुरक्षा के लिए ट्रांसमिशन सर्जक के प्रमाणीकरण की आवश्यकता होती है। उदाहरण के लिए, कोई भी अच्छा एसएसएच नहीं है अगर सभी को पासवर्ड पता है। वितरित अनुप्रयोगों में बहु-परत सुरक्षा महत्वपूर्ण है। थिंक आइडेंटिटी, इंटीग्रिटी, एकाउंटेबिलिटी

— आइडेन बेल

मैंने दूसरे दिन एक दिलचस्प मिश्रण देखा। हमारा एक बड़ा, F500 ग्राहक REST और SOAP (रीड-ओनली डेटा एक्सेस, बाकी के लिए SOAP) के मिश्रण का उपयोग कर रहा है और विभिन्न सुरक्षा योजनाओं के उपयोग से बचने के लिए दोनों के लिए WS-Sec का उपयोग करने का निर्णय लिया है। वे REST कॉल के लिए HTTP हेडर में WS-Sec हेडर जानकारी डालकर ऐसा कर रहे हैं। उनकी सुरक्षा मध्यस्थ को पता है कि चेक करने के लिए उन्हें किसी भी स्थान से कैसे निकालना है। पहली बार मैंने इस दृष्टिकोण को देखा था।

— sfitts

Answer 2

अन्य सुरक्षा निर्भर परिवहन है जबकि SOAP सुरक्षा नहीं है।

REST अंतर्निहित परिवहन से सुरक्षा उपायों को विरासत में लेता है जबकि SOAP WS- सुरक्षा के माध्यम से अपना स्वयं का परिभाषित करता है।

जब हम HTTP पर REST के बारे में बात करते हैं, तो लागू किए गए सभी सुरक्षा उपायों को HTTP विरासत में मिला है और इसे परिवहन स्तर की सुरक्षा के रूप में जाना जाता है।

परिवहन स्तर की सुरक्षा, आपके संदेश को तार पर रहते हुए सुरक्षित करती है - जैसे ही वह तार छोड़ता है, संदेश अधिक सुरक्षित नहीं होता है।

लेकिन, WS- सुरक्षा के साथ, इसकी संदेश स्तर सुरक्षा - भले ही संदेश परिवहन चैनल को छोड़ देता है, फिर भी इसे संरक्षित किया जाएगा। इसके अलावा - संदेश स्तर की सुरक्षा के साथ आप संदेश को आंशिक रूप से एन्क्रिप्ट कर सकते हैं [संपूर्ण संदेश नहीं, लेकिन केवल आपके इच्छित भाग] - लेकिन परिवहन स्तर की सुरक्षा के साथ आप ऐसा नहीं कर सकते।

WS- सुरक्षा के पास प्रमाणीकरण, अखंडता, गोपनीयता और गैर-प्रतिशोध के उपाय हैं जबकि SSL गैर-प्रत्यावर्तन [2-पैर वाले OAuth के साथ समर्थन नहीं करता है]।

प्रदर्शन-वार एसएसएल डब्ल्यूएस-सुरक्षा की तुलना में बहुत तेज है।

धन्यवाद...

Comments

मेरी माफी लेकिन मुझे इसे सुधारने की जरूरत है। विकी फॉर रेस्ट को देखें : आरईएसटी को शुरू में HTTP के संदर्भ में वर्णित किया गया था, लेकिन यह उस प्रोटोकॉल तक सीमित नहीं है। SOAP का WS-Security से कोई लेना-देना नहीं है और REST / SOAP कार्यान्वयन कुछ हद तक किसी भी मामले में अंतर्निहित परिवहन पर निर्भर करते हैं। SOAP XML- आधारित है और इसमें WS-Security को बाद में एप्लिकेशन-डेटा सुरक्षा कार्यान्वयन के रूप में स्तरित किया गया था। अन्यथा अच्छी जानकारी।

— डेरेल टीग

जैसा कि मैंने ऊपर उल्लेख किया है कि REST एक विशेष परिवहन पर निर्भर नहीं करता है - हालाँकि ज्यादातर समय में इसे HTTP के संदर्भ में समझाया गया था। लेकिन, REST किसी भी सुरक्षा के बारे में बात नहीं करता है। यह पूरी तरह से सुरक्षा के लिए अंतर्निहित परिवहन पर निर्भर करता है - इसे HTTP या कुछ भी होने दें। SOAP में - यह स्पष्ट रूप से एक सुरक्षा मानक को परिभाषित करता है जो परिवहन पर निर्भर नहीं करता है। WS-Security SOAP के लिए डिज़ाइन किया गया है। यदि आप SOAP के साथ परिवहन स्तर की सुरक्षा का उपयोग करना चाहते हैं तो कोई समस्या नहीं है, आप इसका उपयोग कर सकते हैं। REST एक वास्तुशिल्प पैटर्न है, यह सुरक्षा के बारे में बात नहीं करता है।

— प्रभात सिरियाडेना

सुपर प्रभात! धन्यवाद यह उपयोगी था

— sunleo

Answer 3

तकनीकी रूप से, आपने इसे जिस तरह से कहा है, न तो सही है, क्योंकि SOAP विधि का संचार सुरक्षित नहीं है, और REST विधि ने वैध उपयोगकर्ताओं को प्रमाणित करने के बारे में कुछ नहीं कहा।

HTTPS से हमलावरों को रोकता निगाह रख दो प्रणालियों के बीच संचार पर। यह भी पुष्टि करता है कि होस्ट सिस्टम (सर्वर) वास्तव में होस्ट सिस्टम है जिसे उपयोगकर्ता एक्सेस करना चाहता है।

WS- सुरक्षा अनधिकृत अनुप्रयोगों (उपयोगकर्ताओं) को सिस्टम तक पहुँचने से रोकता है।

यदि किसी RESTful सिस्टम में उपयोगकर्ताओं को प्रमाणित करने का एक तरीका है और WS-Security के साथ SOAP एप्लिकेशन HTTPS का उपयोग कर रहा है, तो वास्तव में दोनों सुरक्षित हैं। यह डेटा को प्रस्तुत करने और एक्सेस करने का एक अलग तरीका है।

Answer 4

विकी लेख देखें :

बिंदु से बिंदु स्थितियों में गोपनीयता और डेटा अखंडता को ट्रांसपोर्ट लेयर सिक्योरिटी (टीएलएस) के उपयोग के माध्यम से वेब सेवाओं पर भी लागू किया जा सकता है, उदाहरण के लिए, https पर संदेश भेजकर।

WS- सुरक्षा हालाँकि संदेशों की अखंडता और गोपनीयता बनाए रखने की व्यापक समस्या को संबोधित करती है, जब तक कि संदेश को मूल नोड से नहीं भेजा गया था, ताकि तथाकथित अंत सुरक्षा प्रदान की जा सके।

अर्थात्:

• HTTPS एक परिवहन परत (पॉइंट-टू-पॉइंट) सुरक्षा तंत्र है
• WS- सुरक्षा एक अनुप्रयोग परत (एंड-टू-एंड) सुरक्षा तंत्र है।

Answer 5

जैसा कि आप कहते हैं, REST बैंकों के लिए काफी अच्छा है, इसलिए आपके लिए पर्याप्त होना चाहिए।

सुरक्षा के दो मुख्य पहलू हैं: 1) एन्क्रिप्शन और 2) पहचान।

एसएसएल / एचटीटीपीएस में संचारित तार पर एन्क्रिप्शन प्रदान करता है। लेकिन आपको यह भी सुनिश्चित करने की आवश्यकता होगी कि दोनों सर्वर यह पुष्टि कर सकते हैं कि वे जानते हैं कि वे किससे बात कर रहे हैं। यह एसएसएल क्लाइंट सर्टिफिकेट, शेयर सीक्रेट्स आदि के माध्यम से हो सकता है।

मुझे यकीन है कि कोई भी ऐसा मामला बना सकता है जो SOAP "अधिक सुरक्षित" हो, लेकिन शायद किसी भी महत्वपूर्ण तरीके से नहीं। नग्न मोटरसाइकल सादृश्य प्यारा है, लेकिन अगर सही मतलब है कि पूरे इंटरनेट असुरक्षित है।

Answer 6

मुझे अभी तक टिप्पणी जोड़ने की आवश्यकता नहीं है या मैंने इसे बेल के उत्तर में जोड़ दिया है। मुझे लगता है कि बेल ने दो दृष्टिकोणों के शीर्ष स्तर के पेशेवरों और विपक्षों को संक्षेप में प्रस्तुत करने का बहुत अच्छा काम किया। बस कुछ अन्य कारक जिन पर आप विचार करना चाहते हैं:

1) क्या आपके ग्राहकों और आपकी सेवा के बीच अनुरोधों को बिचौलियों के माध्यम से जाने की आवश्यकता है जो पेलोड तक पहुंच की आवश्यकता है? यदि ऐसा है तो WS-Security एक बेहतर फिट हो सकता है।

2) पारस्परिक प्रमाणीकरण नामक एक सुविधा का उपयोग करके ग्राहकों की पहचान के लिए सर्वर के साथ आश्वासन प्रदान करने के लिए एसएसएल का उपयोग करना वास्तव में संभव है। हालाँकि, इसे कॉन्फ़िगर करने की जटिलता के कारण कुछ बहुत ही विशिष्ट परिदृश्यों के बाहर इसका अधिक उपयोग नहीं होता है। इसलिए बेल सही है कि WS-Sec यहां ज्यादा बेहतर है।

3) सामान्य तौर पर एसएसएल बड़े पैमाने पर प्रबंधन मुद्दों के कारण सेटअप और रखरखाव (सरल कॉन्फ़िगरेशन में भी) के लिए एक भालू हो सकता है। ऐसा कोई व्यक्ति जो आपके प्लेटफॉर्म के लिए यह करना जानता हो, वह एक बड़ा धन होगा।

4) यदि आपको किसी प्रकार की क्रेडेंशियल मैपिंग या आइडेंटिटी फेडरेशन करने की आवश्यकता हो सकती है तो WS-Sec ओवरहेड के लायक हो सकता है। ऐसा नहीं है कि आप REST के साथ ऐसा नहीं कर सकते, आपके पास बस आपकी मदद करने के लिए कम संरचना है।

5) चीजों की क्लाइंट साइड पर सभी WS-Security goop को सही स्थानों पर ले जाना एक दर्द से अधिक हो सकता है जितना आपको लगता है कि इसे करना चाहिए।

अंत में, हालांकि यह वास्तव में बहुत सारी चीजों पर निर्भर करता है, जिन्हें हम जानने की संभावना नहीं रखते हैं। अधिकांश स्थितियों के लिए मैं कहूंगा कि या तो दृष्टिकोण "पर्याप्त रूप से सुरक्षित" होगा और इसलिए मुख्य निर्णायक कारक नहीं होना चाहिए।

Comments

बैंकिंग उन लोगों में से एक है जो "अधिकांश" स्थितियों में नहीं हैं।

— ब्रायन ब्राइस

Answer 7

Brace yourself, here there's another coming :-)

आज मुझे अपनी प्रेमिका को HTTPS के विपरीत WS-Security की अभिव्यंजक शक्ति के बीच का अंतर समझाना पड़ा। वह एक कंप्यूटर वैज्ञानिक है, इसलिए भले ही वह सभी XML mumbo जंबो को नहीं जानती हो, वह समझती है (शायद मुझसे बेहतर) एन्क्रिप्शन या हस्ताक्षर का क्या मतलब है। हालाँकि मुझे एक मजबूत छवि चाहिए थी, जो उसे वास्तव में समझा सके कि कौन सी चीजें उपयोगी हैं, बजाय इसके कि वे कैसे कार्यान्वित की जाती हैं (जो थोड़ी देर बाद आई, उसने इसे नहीं छोड़ा :-))।

तो यह इस तरह से चला जाता है। मान लीजिए कि आप नग्न हैं, और आपको अपनी मोटरसाइकिल को एक निश्चित गंतव्य पर चलाना होगा। (ए) मामले में आप एक पारदर्शी सुरंग से गुजरते हैं: अश्लील व्यवहार के लिए गिरफ्तार न होने की आपकी एकमात्र आशा है कि कोई भी नहीं देख रहा है। यह वास्तव में सबसे सुरक्षित रणनीति नहीं है जिसके साथ आप बाहर आ सकते हैं ... (लड़के के माथे से पसीने की बूंद को नोटिस करें)। यह स्पष्ट रूप से एक POST के बराबर है, और जब मैं "समतुल्य" कहता हूं तो मेरा मतलब है। (बी) मामले में, आप बेहतर स्थिति में हैं। सुरंग अपारदर्शी है, इसलिए जब तक आप इसमें यात्रा करते हैं, आपका सार्वजनिक रिकॉर्ड सुरक्षित है। हालांकि, यह अभी भी सबसे अच्छी स्थिति नहीं है। आपको अभी भी घर छोड़ना होगा और सुरंग के प्रवेश द्वार तक पहुंचना होगा, और सुरंग के बाहर एक बार शायद आपको उतरना होगा और कहीं चलना होगा ... और वह HTTPS के लिए जाता है। सच, आपका संदेश सुरक्षित है जबकि यह सबसे बड़ी चैस को पार करता है: लेकिन एक बार जब आपने इसे दूसरी तरफ पहुंचाया तो आपको वास्तव में पता नहीं होगा कि वास्तविक बिंदु पर पहुंचने से पहले कितने चरणों से गुजरना होगा जहां डेटा संसाधित किया जाएगा। और निश्चित रूप से वे सभी चरण HTTP से भिन्न कुछ का उपयोग कर सकते हैं: एक शास्त्रीय MSMQ जो बफ़र्स अनुरोध करता है जिसे उदाहरण के लिए, तुरंत सेवा नहीं दी जा सकती है। यदि कोई व्यक्ति आपके डेटा को उस प्रीप्रोसेसिंग लिम्बो में रखते हैं तो क्या होता है? हम्म। (इस "हम्म" को वाक्य के अंत में मॉर्फियस द्वारा बोले गए "क्या आपको लगता है कि आप सांस ले रहे हैं?") पढ़ें। इस रूपक में पूर्ण समाधान (c) दर्द रहित रूप से है: अपने आप पर कुछ रफ़ू कपड़े और विशेष रूप से मोटरसाइकिल पर हेलमेट प्राप्त करें !!! तो आप सुरक्षित रूप से पर्यावरण की अपारदर्शिता पर भरोसा किए बिना चारों ओर जा सकते हैं। रूपक स्पष्ट रूप से स्पष्ट है: कपड़े मतलब या आसपास के बुनियादी ढांचे की परवाह किए बिना आपके साथ आते हैं, जैसा कि संदेश स्तर की सुरक्षा करती है। इसके अलावा, आप एक हिस्से को कवर करने का फैसला कर सकते हैं, लेकिन एक और खुलासा कर सकते हैं (और आप व्यक्तिगत आधार पर ऐसा कर सकते हैं: हवाई अड्डे की सुरक्षा आपके जैकेट और जूते को बंद कर सकती है, जबकि आपके डॉक्टर के पास उच्च स्तर हो सकता है), लेकिन याद रखें कि छोटी आस्तीन वाली शर्ट हैं बुरा व्यवहार भले ही आपको अपने बाइसेप्स पर गर्व हो :-) (बेहतर पोलो, या टी-शर्ट)।

मुझे यह कहते हुए खुशी हो रही है कि उसे यह बात मिल गई है! मेरा कहना है कि कपड़े का रूप बहुत शक्तिशाली है: मुझे नीति की अवधारणा को पेश करने के लिए इसका इस्तेमाल करने के लिए लुभाया गया था (डिस्को क्लब आपको खेल के जूते में नहीं जाने देंगे; आप अपने अंडरवियर में एक बैंक में पैसे निकालने के लिए नहीं जा सकते हैं; , जबकि यह एक सर्फ पर खुद को संतुलित करते हुए पूरी तरह से स्वीकार्य रूप है; और इसी तरह) लेकिन मैंने सोचा कि एक दोपहर के लिए; ;-)

आर्किटेक्चर - डब्ल्यूएस, जंगली विचार

सौजन्य: http://blogs.msdn.com/b/vbertocci/archive/2005/04/25/end-to-end-security-or-why-you-shouldn-t-drive-your-motorcycle-naked। aspx

Comments

अच्छा और सरल सादृश्य जो आपने https और ws- सुरक्षा के बीच अंतर करने के लिए दिया था। लेकिन वास्तविक इंटरनेट में, वास्तव में अधिकांश समय हम अपनी मोटरसाइकिल को नग्न करके चलाने में होते हैं: प्रदर्शन और लागत के मामले में डी-एसयूवी को हर जगह लागू करना एक ओवरकिल होगा। इसलिए हम उन परिस्थितियों को ध्यान में रखते हुए इस सादृश्य को सुधार सकते हैं जहाँ हमें कपड़े पर रखने की ज़रूरत होती है और जहाँ कपड़े पहनना अस्वाभाविक होता है।

— शशांकहॉलिक

Answer 8

मैं हर दिन इस स्थान में काम करता हूं इसलिए मैं इसे बंद करने के प्रयास में इस पर अच्छी टिप्पणियों को संक्षेप में प्रस्तुत करना चाहता हूं:

एसएसएल (HTTP / s) केवल एक परत सुनिश्चित करता है:

1. सर्वर को एक प्रमाणपत्र प्रस्तुत करने के लिए जोड़ा जा रहा है जो इसकी पहचान को प्रमाणित करता है (हालांकि इसे डीएनएस विषाक्तता के माध्यम से खराब किया जा सकता है)।
2. संचार परत को एन्क्रिप्ट किया गया है (कोई ईवेर्सड्रॉपिंग नहीं है)।

WS- सुरक्षा और संबंधित मानकों / कार्यान्वयन PKI का उपयोग करते हैं:

1. ग्राहक की पहचान साबित करें।
2. संदेश को पारगमन में संशोधित नहीं किया गया था (MITM)।
3. सर्वर को क्लाइंट को प्रमाणित / अधिकृत करने की अनुमति देता है।

अंतिम अनुरोध सेवा अनुरोधों के लिए महत्वपूर्ण है जब क्लाइंट की पहचान (कॉलर) यह जानने के लिए सर्वोपरि है कि क्या उन्हें सेवा से ऐसे डेटा प्राप्त करने के लिए अधिकृत किया जाना चाहिए। मानक एसएसएल एक तरफ़ा (सर्वर) प्रमाणीकरण है और क्लाइंट की पहचान करने के लिए कुछ भी नहीं करता है।

Answer 9

उत्तर वास्तव में आपकी विशिष्ट आवश्यकताओं पर निर्भर करता है।

उदाहरण के लिए, क्या आपको अपने वेब संदेशों की सुरक्षा करने की आवश्यकता है या गोपनीयता की आवश्यकता नहीं है और आपको केवल अंतिम पार्टियों को प्रमाणित करने और संदेश की अखंडता सुनिश्चित करने की आवश्यकता है? यदि यह मामला है - और यह अक्सर वेब सेवाओं के साथ होता है - HTTPS शायद गलत हथौड़ा है।

हालाँकि - मेरे अनुभव से - आपके द्वारा बनाए जा रहे सिस्टम की जटिलता को अनदेखा न करें। न केवल HTTPS को सही तरीके से तैनात करना आसान है, बल्कि ट्रांसपोर्ट लेयर सिक्योरिटी पर भरोसा करने वाला एप्लिकेशन डीबग करना (सादे HTTP पर) आसान है।

सौभाग्य।

Answer 10

Rest Over HTTPS तब तक एक सुरक्षित तरीका होना चाहिए जब तक कि API प्रोवाइडर एक सर्वर एंड को अधिकृत करता है। वेब एप्लिकेशन के साथ-साथ हम जो कुछ भी करते हैं, वह HTTPS और कुछ प्रमाणीकरण / प्राधिकरण के माध्यम से एक वेब एप्लिकेशन तक पहुंच बना रहा है, पारंपरिक रूप से वेब एप्लिकेशन में सुरक्षा मुद्दे नहीं थे, फिर रेस्टफुल एपीआई भी समस्या के बिना सुरक्षा मुद्दों का मुकाबला करेगा!

Answer 11

यदि आपका RESTFul कॉल XML संदेशों को HTTP अनुरोध के Html बॉडी में आगे और पीछे भेजती है, तो आपको अपने XML संदेशों में WS-Security के सभी लाभ जैसे XML सुरक्षा, का उपयोग करते समय सुरक्षा के सभी फीचर्स सक्षम होना चाहिए। SSL से उपलब्ध हैं जैसे SSL / TLS एन्क्रिप्शन।