.NET 4.5 में डिफ़ॉल्ट सुरक्षाप्रोटोकॉल

Question

उन सर्वरों के साथ संचार करने के लिए डिफ़ॉल्ट सुरक्षा प्रोटोकॉल क्या है जो समर्थन करते हैं TLS 1.2? विल .NETडिफ़ॉल्ट रूप से, उच्चतम सुरक्षा सर्वर साइड पर समर्थित प्रोटोकॉल चुन सकते हैं या मैं स्पष्ट रूप से कोड की इस पंक्ति जोड़ने के लिए कार्य करें:

System.Net.ServicePointManager.SecurityProtocol = 
SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

क्या कोड बदलने के अलावा इस डिफ़ॉल्ट को बदलने का कोई तरीका है?

अंत में, .NET 4.0केवल समर्थन करता है TLS 1.0? यानी मुझे सपोर्ट करने के लिए क्लाइंट प्रोजेक्ट्स को 4.5 में अपग्रेड करना होगा TLS 1.2।

मेरी प्रेरणा SSLv3क्लाइंट की ओर से समर्थन को हटाने की है, भले ही सर्वर इसका समर्थन करता है (मशीन रजिस्ट्री में इसे निष्क्रिय करने के लिए मेरे पास पहले से ही एक पॉवरशेल स्क्रिप्ट है) और सर्वर का समर्थन करने वाले उच्चतम टीएलएस प्रोटोकॉल का समर्थन करने के लिए।

अपडेट: को देखते हुए ServicePointManagerकक्षा में .NET 4.0मैं के लिए कोई प्रगणित मान देख TLS 1.0और 1.1। दोनों में .NET 4.0/4.5, डिफ़ॉल्ट है SecurityProtocolType.Tls|SecurityProtocolType.Ssl3। उम्मीद है कि यह डिफ़ॉल्ट SSLv3रजिस्ट्री में अक्षम होने से नहीं टूटेगा ।

हालाँकि, मैंने निर्णय लिया है कि मुझे सभी ऐप्स को सभी एप्लिकेशन के सभी बूटस्ट्रैपिंग कोड में .NET 4.5स्पष्ट रूप से जोड़ना होगा SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;।

यह विभिन्न एपिस और सेवाओं के आउटबाउंड अनुरोधों को डाउनग्रेड नहीं करेगा SSLv3और उच्चतम स्तर का चयन करना चाहिए TLS।

क्या यह दृष्टिकोण उचित या भारी लगता है? मेरे पास अपडेट करने के लिए कई एप्लिकेशन हैं, और मैं उन्हें भविष्य के सबूत देना चाहता हूं क्योंकि मैंने सुना है कि TLS 1.0कुछ प्रदाताओं द्वारा निकट भविष्य में भी पदावनत किया जा सकता है।

एक ग्राहक के रूप में एपीआई के लिए बाहर जाने वाले अनुरोध, रजिस्ट्री में SSL3 को अक्षम करने से भी .NET फ्रेमवर्क में प्रभाव पड़ता है? मैं डिफ़ॉल्ट रूप से देखता हूं, टीएलएस 1.1 और 1.2 सक्षम नहीं हैं, क्या हमें इसे रजिस्ट्री के माध्यम से सक्षम करना है? आरई http://support.microsoft.com/kb/245030 ।

थोड़ी जांच के बाद, मेरा मानना ​​है कि रजिस्ट्री सेटिंग्स का कोई प्रभाव नहीं पड़ेगा क्योंकि वे आईआईएस (सर्वर उपकुंजी) और ब्राउज़रों (क्लाइंट सबकी) पर लागू होते हैं।

क्षमा करें, यह पोस्ट कई प्रश्नों में बदल गई, "शायद" उत्तर के साथ।

Comments

FYI करें: TLS के आस-पास नवीनतम सर्वोत्तम प्रथाएँ: docs.microsoft.com/en-us/dotnet/framework/network-programming/…

— JohnLBevan

जो लोग इसके लिए सबसे अच्छा जवाब देखना चाहते हैं, उनके लिए वोटों के आधार पर छाँटें!

— नवयुवती

संबंधित SO Q & A: stackoverflow.com/questions/41618766// पाठकों को इस प्रश्न पर ध्यान देना चाहिए कि उम्र बढ़ने और नई सिफारिशें 2020 तक लागू हैं।

— कोई वापसी नहीं

Answer 1

टिप्पणी छोड़ने वालों में से कुछ ने कहा है कि System.Net.ServicePointManager.SecurityProtocolविशिष्ट मूल्यों पर सेटिंग का मतलब है कि आपका ऐप भविष्य के टीएलएस संस्करणों का लाभ नहीं ले पाएगा जो भविष्य के अपडेट में .NET में डिफ़ॉल्ट मान बन सकते हैं। प्रोटोकॉल की एक निश्चित सूची को निर्दिष्ट करने के बजाय, आप उन प्रोटोकॉल को चालू या बंद कर सकते हैं जिनके बारे में आप जानते हैं और परवाह करते हैं, किसी अन्य को छोड़ दें जैसा कि वे हैं।

अन्य प्रोटोकॉल को प्रभावित किए बिना TLS 1.1 और 1.2 चालू करना:

System.Net.ServicePointManager.SecurityProtocol |= 
    SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

|=दूसरों को बंद किए बिना इन झंडों को चालू करने के उपयोग पर ध्यान दें।

अन्य प्रोटोकॉल को प्रभावित किए बिना SSL3 को बंद करने के लिए:

System.Net.ServicePointManager.SecurityProtocol &= ~SecurityProtocolType.Ssl3;

Comments

यह वास्तव में सही उत्तर है। स्वीकृत उत्तर सुनिश्चित करेगा कि आपका ऐप हमेशा नए टीएलएस संस्करणों को बंद कर देगा, जब तक कि आप वापस नहीं जाते और अपना कोड अपडेट नहीं करते।

— कॉनर

@Gerten नहीं, यह एक बिटवाइज़ है या, इसलिए यह उचित बिट्स को चालू करता है यदि वे बंद हैं। यदि वे बिट पहले से ही हैं, तो कोई परिवर्तन नहीं होता है।

— स्कॉट

और इसके बराबर का [Net.ServicePointManager]::SecurityProtocol = ([Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls11 -bor [Net.SecurityProtocolType]::Tls12) पॉवरशेल इनवोक-रेस्टमेथोड एक ही अंतर्निहित .NET फ्रेमवर्क लाइब्रेरी पर निर्भर करता है।

— मार्टिन हॉलिंगवर्थ

चूंकि कोई भी इस कोड को रखने के बारे में बात नहीं कर रहा है, मैंने अपने ASP.NET MVC एप्लिकेशन के लिए इसे सफलतापूर्वक Global.asax.cs के Application_Start में डाल दिया। मैं देख रहा था कि कैसे मेरे SMTP अनुरोधों को TLS1.2 पर भेजा जाए और TLS1.0 से अधिक नहीं। मैंने जोड़ा और = ~ SecurityProtocolType.Tls को बंद करने के लिए TLS 1.0

— ग्रेग वेर्स

वीबी में बराबर हैNet.ServicePointManager.SecurityProtocol = Net.ServicePointManager.SecurityProtocol OR Net.SecurityProtocolType.Tls12 OR Net.SecurityProtocolType.Tls12

— Codespaced

Answer 2

System.Net.ServicePointManager.SecurityProtocol.NET में डिफ़ॉल्ट दोनों 4.0/4.5है SecurityProtocolType.Tls|SecurityProtocolType.Ssl3।

.NET 4.0समर्थन करता है, TLS 1.0जबकि .NET 4.5समर्थन करता हैTLS 1.2

हालांकि, एक आवेदन लक्ष्यीकरण .NET 4.0अभी भी करने के लिए समर्थन कर सकते हैं TLS 1.2, तो .NET 4.5एक ही वातावरण में स्थापित किया गया है। .NET 4.5के शीर्ष पर .NET 4.0, प्रतिस्थापित करता है System.dll।

मैंने इस बात को सत्यापित किया है fiddler4कि एक .NET 4.0प्रोजेक्ट में सही सुरक्षा प्रोटोकॉल के साथ और मैन्युअल रूप से एन्यूमेरेटेड मान सेट करके :

ServicePointManager.SecurityProtocol = (SecurityProtocolType)192 |
(SecurityProtocolType)768 | (SecurityProtocolType)3072;

संदर्भ:

namespace System.Net
{
    [System.Flags]
    public enum SecurityProtocolType
    {
       Ssl3 = 48,
       Tls = 192,
       Tls11 = 768,
       Tls12 = 3072,
    }
}

यदि आप केवल .NET 4.0स्थापित वातावरण के साथ हैक का प्रयास करते हैं , तो आपको अपवाद मिलेगा:

अखंडित अपवाद: System.NotSupportedException: अनुरोधित सुरक्षा प्रोटोकॉल समर्थित नहीं है। System.Net.ServicePointManager.set_SecurityProtocol (SecurityProtocolType v alue) पर

हालांकि, मैं भविष्य के पैच के बाद से इस "हैक" की सिफारिश नहीं करूंगा, आदि इसे तोड़ सकते हैं। *

इसलिए, मैंने इसके लिए समर्थन हटाने का सबसे अच्छा मार्ग तय किया SSLv3है:

1. सभी अनुप्रयोगों को अपग्रेड करें .NET 4.5

2. डिफ़ॉल्ट और भविष्य के प्रमाण को ओवरराइड करने के लिए बूस्टर कोडिंग कोड में निम्नलिखित जोड़ें:

   System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

* अगर यह हैक गलत है तो कोई मुझे सही करे, लेकिन प्रारंभिक परीक्षण मुझे लगता है कि यह काम करता है

Comments

कृपया देखें imperialviolet.org/2014/12/08/poodleagain.html "यह एक अच्छे क्षण की तरह लगता है कि टीएएस 1.2 से कम एईएडी सिफर सूट के साथ सब कुछ क्रिप्टोग्राफिक रूप से टूट गया है।"

— नील

@ मैथ्यू, संदर्भServicePointManager.cs देखें स्रोत का कोड देखकर देखें ।microsoft.com/#System/net/System/Net/…

— ल्यूक हट्टन

मैं देख रहा हूं कि लोग .NET 4.5Tls12 में चूक का दावा करते हैं - लेकिन जैसा कि आपने यहां रखा है, ऐसा नहीं है। यह आपको इसका उपयोग करने का विकल्प देता हैSecurityProtocol

— डॉन चीडल

मैं इस उत्तर को अस्वीकार नहीं करूंगा क्योंकि यह बहुत उपयोगी जानकारी प्रदान करता है, लेकिन हार्डकोडेड प्रोटोकॉल संस्करण को लागू करना एक अच्छा विचार नहीं है क्योंकि यह एप्लिकेशन को सर्वोत्तम उपलब्ध एन्क्रिप्शन का उपयोग करने से प्रतिबंधित करेगा और इसके परिणामस्वरूप सड़क के नीचे सुरक्षा के मुद्दे हो सकते हैं। वास्तव में आधुनिक प्रोटोकॉल का समर्थन करने के लिए .Net के डिफ़ॉल्ट व्यवहार को बदलने के लिए रजिस्ट्री में बदलाव होता है। (हालांकि, यह ध्यान देने योग्य है कि रजिस्ट्री परिवर्तन भी SSL v3 को अक्षम करता है।)

— एजे हेंडरसन

एफडब्ल्यू 4.6 और 4.7 पर, डिफ़ॉल्ट अब support.microsoft.com/en-us/help/3069494/… केSecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 अनुसार है

— इयान केम्प

Answer 3

आप निम्न रजिस्ट्री में डिफ़ॉल्ट व्यवहार को ओवरराइड कर सकते हैं:

Key  : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 
Value: SchUseStrongCrypto
Type: REG_DWORD
Data : 1

तथा

Key  : HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319
Value: SchUseStrongCrypto
Type: REG_DWORD
Data : 1

विवरण के लिए, कृपया कार्यान्वयनServicePointManager देखें ।

Comments

धन्यवाद, मुझे इस बारे में पता नहीं था। मैं इसका परीक्षण करूंगा। मैंने इसे सेट करने के लिए एक पॉवरफुल

— ल्यूक हट्टन

रजिस्ट्री बदलने से अच्छा समाधान नहीं दिखता है। यदि आवेदन टीएलएस 1 का समर्थन करना चाहता है तो आवेदन को इसके बारे में उद्धरण लेना चाहिए। नहीं चल रहा माहौल। अन्यथा यह अन्य अनुप्रयोगों को नुकसान पहुंचा सकता है या आपके एप्लिकेशन को तैनात करने और अपग्रेड करने से नरक बना सकता है।

— मिखाइल जी

@ मिखाइल जी इसके विपरीत। रजिस्ट्री परिवर्तन बेहतर तरीका है। SChannel अंतर्निहित बातचीत की एक अमूर्तता प्रदान करता है और आप चाहते हैं कि आपका एप्लिकेशन उच्चतम समर्थित सुरक्षा स्तर जो भी हो, उसका उपयोग करे। सॉफ्टवेयर में कृत्रिम रूप से इसे सीमित करने से भविष्य में समस्याएं आती हैं जब नए प्रोटोकॉल जारी होते हैं और आपका सॉफ्टवेयर उनका उपयोग करने में असमर्थ होता है। अच्छा होगा यदि सॉफ्टवेयर में दिए गए प्रोटोकॉल से बेहतर उपयोग के लिए कहने का विकल्प हो, लेकिन भविष्य के संस्करणों को काम करने से रोके बिना इसके लिए कोई विकल्प नहीं है। हालांकि उस परिवर्तन के साथ SSL v3 को अक्षम कर दिया गया था

— एजे हेंडरसन

कमांड-लाइन: reg add HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /v SchUseStrongCrypto /t REG_DWORD /d 1 /reg:64(और / या /reg:32)

— केविन स्माइथ

@MikhailG: रजिस्ट्री सेट करने से पुराने प्रोटोकॉल का समर्थन करने से एप्लिकेशन को रोका नहीं जा सकता। यह केवल डिफॉल्ट्स को बदलता है (जिसमें अब तक tls 1.0 शामिल है)। इसके अलावा, .Net 4.6+ में डिफ़ॉल्ट व्यवहार मजबूत क्रिप्टो का उपयोग करना है; उस स्थिति में यह रजिस्ट्री प्रविष्टि केवल मजबूत क्रिप्टो को अक्षम करने के साधन के रूप में उपयोगी होगी।

— ब्रायन

Answer 4

.regएक्सटेंशन और निम्न सामग्री के साथ एक टेक्स्ट फ़ाइल बनाएं :

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

या इसे निम्न स्रोत से डाउनलोड करें:

https://tls1test.salesforce.com/s/NET40-Enable-TLS-1_2.reg

स्थापित करने के लिए डबल-क्लिक करें ...

Comments

आपके द्वारा प्रदान किया गया लिंक SSL प्रमाणपत्र समस्या है।

— नाथनअल्डनसेर

जब मैं इन रजिस्ट्री कुंजी को जोड़ता हूं, तब भी मेरे पास यह मुद्दा है। कोई उपाय ?

— समिज्जो

@Samidjo - क्या .NET संस्करण का उपयोग कर रहे हैं? ल्यूक का जवाब मेरी तुलना में बहुत अधिक विस्तार में जाता है, लेकिन ऐसा लगता है कि आपको कम से कम .NET 4.5 स्थापित करना होगा। इसके अलावा, यदि आपने अभी बदलाव किया है, तो आपको ऐप पूल को रीसायकल करना पड़ सकता है। ये तरह तरह के अनुमान हैं, इसलिए अधिक विस्तार के बिना मैं बहुत अधिक मदद करने में सक्षम हो सकता हूं :)

— दाना

एक हाल ही में लागू किया पैच support.microsoft.com/en-us/help/4019114/... एक सर्वर के लिए https बाकी अनुरोध पर विफल हमारे .net 4.5.2 आवेदन का कारण बना। इन चाबियों ने हमारी समस्या हल कर दी।

— क्लेनक्स

Answer 5

मैंने पाया है कि जब मैं केवल टीएलएस 1.2 को निर्दिष्ट करता हूं कि यह अभी भी 1.1 तक बातचीत करेगा। System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

मैंने इसे अपने .net 4.5 वेब ऐप के लिए Global.asax स्टार्टअप विधि में निर्दिष्ट किया है।

Comments

सर्वर पर समर्थित सुरक्षा प्रोटोकॉल क्या है? मेरा मानना ​​है कि यहां भी कारक है और हो सकता है कि 1.1 सर्वर पर नवीनतम हो। www.passionatecoder.ca

— एहसान

Upvoted क्योंकि यह एकमात्र उत्तर है जो बताता है कि कोड की लाइन कहां है जो समाधान है।

— jgerman

क्लाइंट (जैसे आपका C # WebClient) और सर्वर (एपीआई सर्वर जिसे आप कॉल कर रहे हैं) उच्चतम प्रोटोकॉल का उपयोग करने के लिए बातचीत करेंगे जो दोनों का समर्थन करते हैं। इसलिए यदि आपका क्लाइंट टीएलएस 1.2 का समर्थन करता है, लेकिन सर्वर केवल टीएलएस 1.1 - क्लाइंट टीएलएस 1.1 का उपयोग करेगा (जब तक कि आप अपने क्लाइंट से टीएलएस 1.1 को रिमूव नहीं करते हैं - उस स्थिति में वे पारस्परिक रूप से समर्थित प्रोटोकॉल नहीं पा सकते हैं, और क्लाइंट त्रुटि करेगा)

— डॉन Cheadle

Global.asax.cs में System.Net का उपयोग करना था

— पैट्रिक

Answer 6

निम्नलिखित कोड होगा:

• प्रिंट सक्षम प्रोटोकॉल
• उपलब्ध प्रोटोकॉल प्रिंट करें
• यदि प्लेटफ़ॉर्म इसका समर्थन करता है तो TLS1.2 को सक्षम करें और यदि यह आरंभ करने के लिए सक्षम नहीं है
• सक्षम होने पर SSL3 को अक्षम करें
• प्रिंट अंतिम परिणाम

स्थिरांक:

• 48 एसएसएल 3 है
• 192 TLS1 है
• 768 TLS1.1 है
• 3072 TLS1.2 है

अन्य प्रोटोकॉल प्रभावित नहीं होंगे। यह भविष्य के प्रोटोकॉल (Tls1.3, आदि) के साथ संगत बनाता है।

कोड

// print initial status
    Console.WriteLine("Runtime: " + System.Diagnostics.FileVersionInfo.GetVersionInfo(typeof(int).Assembly.Location).ProductVersion);
    Console.WriteLine("Enabled protocols:   " + ServicePointManager.SecurityProtocol);
    Console.WriteLine("Available protocols: ");
    Boolean platformSupportsTls12 = false;
    foreach (SecurityProtocolType protocol in Enum.GetValues(typeof(SecurityProtocolType))) {                
        Console.WriteLine(protocol.GetHashCode());
        if (protocol.GetHashCode() == 3072){
            platformSupportsTls12 = true;
        }
    }
    Console.WriteLine("Is Tls12 enabled: " + ServicePointManager.SecurityProtocol.HasFlag((SecurityProtocolType)3072));    


// enable Tls12, if possible
    if (!ServicePointManager.SecurityProtocol.HasFlag((SecurityProtocolType)3072)){
        if (platformSupportsTls12){
            Console.WriteLine("Platform supports Tls12, but it is not enabled. Enabling it now.");
            ServicePointManager.SecurityProtocol |= (SecurityProtocolType)3072;
        } else {
            Console.WriteLine("Platform does not supports Tls12.");
        }
    }

// disable ssl3
   if (ServicePointManager.SecurityProtocol.HasFlag(SecurityProtocolType.Ssl3)) { 
      Console.WriteLine("Ssl3SSL3 is enabled. Disabling it now.");
      // disable SSL3. Has no negative impact if SSL3 is already disabled. The enclosing "if" if just for illustration.
      System.Net.ServicePointManager.SecurityProtocol &= ~SecurityProtocolType.Ssl3;                      
   }
    Console.WriteLine("Enabled protocols:   " + ServicePointManager.SecurityProtocol);

उत्पादन

Runtime: 4.7.2114.0
Enabled protocols:   Ssl3, Tls
Available protocols: 
0
48
192
768
3072
Is Tls12 enabled: False
Platform supports Tls12, but it is not enabled. Enabling it now.
Ssl3 is enabled. Disabling it now.
Enabled protocols:   Tls, Tls12

Answer 7

मुझे समस्या तब हुई जब मेरे ग्राहक ने टीएलएस को 1.0 से 1.2 तक उन्नत किया। मेरा अनुप्रयोग .net फ्रेमवर्क 3.5 का उपयोग कर रहा है और सर्वर पर चलता है। इसलिए मैंने इसे इस तरह से तय किया:

1. प्रोग्राम को ठीक करें

कॉल करने से पहले HttpWebRequest.GetResponse () इस कमांड को जोड़ें:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls | SecurityProtocolTypeExtensions.Tls11 | SecurityProtocolTypeExtensions.Tls12;

2 नई कक्षाएं जोड़कर एक्सटेंशन 2 DLL: System.Net और System.Security.Authentication

    namespace System.Net
    {
        using System.Security.Authentication;
        public static class SecurityProtocolTypeExtensions
        {
            public const SecurityProtocolType Tls12 = (SecurityProtocolType)SslProtocolsExtensions.Tls12;
            public const SecurityProtocolType Tls11 = (SecurityProtocolType)SslProtocolsExtensions.Tls11;
            public const SecurityProtocolType SystemDefault = (SecurityProtocolType)0;
        }
    } 

    namespace System.Security.Authentication
    {
        public static class SslProtocolsExtensions
        {
            public const SslProtocols Tls12 = (SslProtocols)0x00000C00;
            public const SslProtocols Tls11 = (SslProtocols)0x00000300;
        }
    } 

2. Microsoft बैच अपडेट करें

डाउनलोड बैच:

• Windows 2008 R2 के लिए: windows6.1-kb3154518-x64.msu
• विंडोज़ 2012 R2 के लिए: windows8.1-kb3154520-x64.msu

डाउनलोड बैच और अधिक विवरण के लिए आप यहां देख सकते हैं:

https://support.microsoft.com/en-us/help/3154518/support-for-tls-system-default-versions-included-in-the-.net-framework-3.5.1-on-windows-7 -sp1 और सर्वर-2008-R2-SP1

Comments

क्या स्रोत कोड को बदले बिना सिक्योरिटीप्रोटोकॉल को बदलना संभव है? मशीन की तरह ।config या app.config।

— अहानकेँडी १i ’१i

वाह। यह वर्ष पुरस्कार का जादू है..स्टफ ... वहीं। आप उपनगरों रॉक!

— ग्रेनडाकर

Answer 8

रजिस्ट्री परिवर्तन तंत्र ने संघर्ष के बाद मेरे लिए काम किया। दरअसल मेरा आवेदन 32 बिट के रूप में चल रहा था। इसलिए मुझे पथ के तहत मूल्य बदलना पड़ा।

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft.NETFramework\v4.0.30319

मान का प्रकार DWORD होना चाहिए और 0 से ऊपर का मान होना चाहिए। 1 उपयोग करें।

Comments

यह सही नहीं है। .NET 4.5.2 के लिए, इसे 1 (या उससे ऊपर) पर सेट करना होगा; लेकिन .NET 4.6 के लिए, यह पर्याप्त है कि इसे 0 पर सेट नहीं किया जाए (अर्थात यह परेशान हो सकता है)।

— जिरका हनिका

ओह, मैं .Net 4.6 में परीक्षण नहीं किया। मेरे निष्कर्ष blogpost joymonscode.blogspot.com/2015/08/… में हैं

— जॉय जॉर्ज कुंजिक्कुरु

आपके द्वारा उल्लेखित रजिस्ट्री कुंजी को "Wow6432Node" पढ़ना चाहिए। आपने किसी कारण से "नोड" भाग को छोड़ दिया। मैंने आपकी प्रतिक्रिया को संपादित करने की कोशिश की लेकिन मेरा परिवर्तन केवल 4 अक्षर थे इसलिए यह मुझे नहीं होने देगा। : \

— जेफरी लेकोर्स

मुझे इस सेटिंग को डिफ़ॉल्ट के रूप में सक्रिय होने के लिए IIS को उछाल देना पड़ा।

— जेफ मिशेल

Answer 9

मैं .NET 4.5.2 के तहत चल रहा हूं, और मैं इनमें से किसी भी जवाब से खुश नहीं था। जैसा कि मैं एक प्रणाली से बात कर रहा हूं जो टीएलएस 1.2 का समर्थन करता है, और एसएसएल 3, टीएलएस 1.0 और टीएलएस 1.1 के रूप में देख रहा हूं, सभी टूटे हुए और उपयोग के लिए असुरक्षित हैं, मैं इन प्रोटोकॉल को सक्षम नहीं करना चाहता। .NET 4.5.2 के तहत, SSL3 और TLS 1.0 प्रोटोकॉल दोनों डिफ़ॉल्ट रूप से सक्षम हैं, जिन्हें मैं निरीक्षण करके कोड में देख सकता हूं ServicePointManager.SecurityProtocol। .NET 4.7 के तहत, नया हैSystemDefaultप्रोटोकॉल मोड जो स्पष्ट रूप से ओएस को प्रोटोकॉल के चयन के लिए सौंपता है, जहां मेरा मानना ​​है कि रजिस्ट्री या अन्य सिस्टम कॉन्फ़िगरेशन सेटिंग्स पर भरोसा करना उचित होगा। हालाँकि यह .NET 4.5.2 के तहत समर्थित नहीं लगता है। फॉरवर्ड-कम्पेटिबल कोड लिखने के हितों में, कि जब टीएलएस 1.2 भविष्य में अनिवार्य रूप से टूट जाता है, तब भी सही निर्णय लेते रहेंगे, या जब मैं .NET 4.7+ में अपग्रेड करता हूं और ओएस को एक उपयुक्त प्रोटोकॉल का चयन करने के लिए अधिक जिम्मेदारी सौंपता हूं। , मैंने निम्नलिखित कोड अपनाया:

SecurityProtocolType securityProtocols = ServicePointManager.SecurityProtocol;
if (securityProtocols.HasFlag(SecurityProtocolType.Ssl3) || securityProtocols.HasFlag(SecurityProtocolType.Tls) || securityProtocols.HasFlag(SecurityProtocolType.Tls11))
{
    securityProtocols &= ~(SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls | SecurityProtocolType.Tls11);
    if (securityProtocols == 0)
    {
        securityProtocols |= SecurityProtocolType.Tls12;
    }
    ServicePointManager.SecurityProtocol = securityProtocols;
}

यह कोड तब पता चलेगा जब किसी ज्ञात असुरक्षित प्रोटोकॉल को सक्षम किया गया है, और इस मामले में, हम इन असुरक्षित प्रोटोकॉल को हटा देंगे। यदि कोई अन्य स्पष्ट प्रोटोकॉल नहीं रहता है, तो हम इस बिंदु पर .NET द्वारा समर्थित एकमात्र ज्ञात सुरक्षित प्रोटोकॉल के रूप में TLS 1.2 को सक्षम करेंगे। यह कोड आगे की ओर संगत है, क्योंकि यह नए प्रोटोकॉल प्रकारों को ध्यान में रखेगा जो भविष्य में जोड़े जाने के बारे में नहीं जानते हैं, और यह नए के साथ अच्छा भी खेलेंगेSystemDefault.NET 4.7 में स्थिति, जिसका अर्थ है कि मुझे भविष्य में इस कोड को फिर से नहीं देखना पड़ेगा। मैं बिना किसी विशेष सुरक्षा प्रोटोकॉल के हार्ड-कोडिंग के बजाय इस तरह से एक दृष्टिकोण अपनाने की जोरदार सिफारिश करूंगा, अन्यथा आपको नए सुरक्षा प्रोटोकॉल को अपग्रेड करने के लिए अपने क्लाइंट को एक नए संस्करण के साथ फिर से जोड़ना होगा और बदलना होगा जब टीएलएस 1.2। अनिवार्य रूप से टूट गया है, या अधिक संभावना है कि आपको अपने सर्वर पर वर्षों से चालू असुरक्षित प्रोटोकॉल को छोड़ना होगा, जिससे आपके संगठन को हमलों का निशाना बनाया जा सके।

Comments

यह उत्तर सबसे अधिक सोचा गया लगता है, हालांकि, जब तक मैं कुछ याद नहीं कर रहा हूं, मुझे यकीन नहीं है कि जब भी टीएलएस 1.2 अनिवार्य रूप से टूटता है तो यह आगे संगत होगा। मैं अपने .NET 4.7.2 ऐप में जो देख रहा हूं, उससे SecurityProtocolType.SystemDefaultध्वज का मूल्यांकन होता है 0, इसलिए if (securityProtocols == 0)टीएलएस 1.2 के लिए बिटवाइज समावेशी या ध्वज के साथ जांच करना हमेशा टीएलएस 1.2 को शामिल करेगा, भले ही यह "ब्रेक" हो, सही? यहां तेज शूटिंग नहीं। मैं सही मायने में आगे का सबसे अच्छा रास्ता खोजने की कोशिश कर रहा हूं।

— ग्रिस्वाल्ड_911

मैंने इसे शामिल करने के लिए आपके कोड को संशोधित कर दिया है और यह काम के लिए और संगत प्रतीत होता है if (!Enum.IsDefined(typeof(SecurityProtocolType), 0) && securityProtocols == 0) { securityProtocols |= SecurityProtocolType.Tls12; }:।

— Griswald_911

@ Griswald_911, मैं अपने 4.7.2 कंसोल एप्लिकेशन में समान कोड का पालन करता हूं, और मैंने पाया कि यह लाइन securityProtocols |= SecurityProtocolType.Tls12;(बिना ब्लॉक के) SystemDefault को बनाए नहीं रखती है, सुरक्षाप्रोटोकॉल केवल TLS2 है। तो क्या आपका मतलब है कि कब SystemDefault, कोई मूल्य अद्यतन नहीं होना चाहिए? आगे संगत के संबंध में, क्या आप मान रहे हैं कि OS टीएलएस 1.3 जैसे नए प्रोटोकॉल को सक्षम करने का ध्यान रखेगा?

— यांग

@ यंग - सही। लाइन securityProtocols |= SecurityProtocolType.Tls12;' will add TLS 1.2, but because the SecurityProtocolType` enum में एक [Flags]विशेषता है, और SystemDefault एन्यूमरेशन मान है 0, SystemDefault मान पहले से सेट होने पर भी छीन लिया जाएगा। अंतिम परिणाम यह है कि आप या तो SevicePointManager.SecurityProtocol 0 पर सेट कर सकते हैं , या अन्य गणना मूल्यों के किसी भी संयोजन के लिए। यदि आप इसे SystemDefault पर सेट करते हैं, तो आप मूल रूप से प्रोटोकॉल को स्वयं निर्दिष्ट करने और OS का निर्णय लेने से चूक रहे हैं।

— ग्रिस्वाल्ड_911

@Yang - बिंदु यह है कि, SystemDefault का मान सेट करने के बाद, आपके ऐप को ओएस निर्दिष्ट करने वाले सभी का उपयोग करना चाहिए - जो कि विंडोज 10. के नवीनतम संस्करणों में TLS 1.2 है। विचार यह है कि, भविष्य में जब TLS 1.3 बन जाएगा। मानक, आपको उस कार्यक्षमता को प्राप्त करने के लिए अपने आवेदन को संशोधित नहीं करना चाहिए। यहां दस्तावेज़ीकरण देखें , जहां SystemDefault "ऑपरेटिंग सिस्टम का उपयोग करने के लिए सबसे अच्छा प्रोटोकॉल चुनने और ऐसे प्रोटोकॉल को ब्लॉक करने की अनुमति देता है जो सुरक्षित नहीं हैं"।

— ग्रिस्वाल्ड_911

Answer 10

Microsoft ने हाल ही में इसके आस-पास सर्वोत्तम प्रथाओं को प्रकाशित किया है। https://docs.microsoft.com/en-us/dotnet/framework/network-programming/tls

सारांश

लक्ष्य .Net फ्रेमवर्क 4.7, SecurityProtocol को सेट करने वाले किसी भी कोड को हटा दें, इस प्रकार OS यह सुनिश्चित करेगा कि आप सबसे सुरक्षित समाधान का उपयोग करें।

एनबी: आपको यह भी सुनिश्चित करना होगा कि टीएलएस का नवीनतम संस्करण आपके ओएस पर समर्थित और सक्षम है।

OS                          TLS 1.2 support

Windows 10                  \_ Supported, and enabled by default.
Windows Server 2016         /   
Windows 8.1                 \_ Supported, and enabled by default.
Windows Server 2012 R2      /
Windows 8.0                 \_ Supported, and enabled by default.
Windows Server 2012         /
Windows 7 SP1               \_ Supported, but not enabled by default*.
Windows Server 2008 R2 SP1  /
Windows Server 2008         -  Support for TLS 1.2 and TLS 1.1 requires an update. See Update to add support for TLS 1.1 and TLS 1.2 in Windows Server 2008 SP2.
Windows Vista               -  Not supported.

* To enable TLS1.2 via the registry see https://docs.microsoft.com/en-us/windows-server/security/tls/tls-registry-settings#tls-12 

    Path: HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS1.2\Server

        Property: Enabled
        Type: REG_DWORD
        Value: 1

        Property: DisabledByDefault 
        Type: REG_DWORD
        Value: 0

    Path: HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS1.2\Client

        Property: Enabled
        Type: REG_DWORD
        Value: 1

        Property: DisabledByDefault 
        Type: REG_DWORD
        Value: 0

अधिक जानकारी और पुराने ढांचे के लिए, कृपया MS लिंक देखें।

Comments

समस्या यह है कि यदि आप दिशानिर्देशों का पालन नहीं करते हैं, तो 1.1 और tls 1.2, विंडोज 7 और सर्वर 2008 पर tls 1.1 और tls 1.2 पर काम नहीं करेगा क्योंकि वे रजिस्ट्री परिवर्तन के बिना इन ओएस में "सक्षम" (जो भी अर्थ हो) नहीं हैं। यह सिस्टमडिफॉल्ट को डिजाइन द्वारा तोड़ा गया अभ्यास बनाता है। Microsoft ने वास्तव में इसे गड़बड़ कर दिया।

— osexpert

अच्छा लगा, धन्यवाद @osexpert, अच्छी पकड़। मैंने समर्थित OS पर जानकारी शामिल करने के लिए उत्तर में संशोधन किया है, इसलिए पुराने OS पर चलने वाले लोगों के लिए कोई आश्चर्य की बात नहीं है जहाँ सिर्फ 4.7 को लक्षित करना पर्याप्त नहीं है।

— जॉनब्लेवन

NB: कुछ OS पर नए प्रोटोकॉल को सक्षम करने के लिए एक KB भी है: support.microsoft.com/en-my/help/3140245/…

— JohnLevan

अगर रजिस्ट्री सेटिंग्स एक विकल्प नहीं हैं, तो मुझे लगता है कि यह .NET if (System.Environment.OSVersion.Version < new Version(6, 2) /* Windows 8 */) ServicePointManager.SecurityProtocol |= SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12; else ServicePointManager.SecurityProtocol = SecurityProtocolType.SystemDefault;

— 4.7+ के

Answer 11

पूर्णता के लिए, यहां एक पॉवरशेल स्क्रिप्ट है जो पूर्वोक्त रजिस्ट्री कुंजियों को सेट करती है:

new-itemproperty -path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -name "SchUseStrongCrypto" -Value 1 -PropertyType "DWord";
new-itemproperty -path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" -name "SchUseStrongCrypto" -Value 1 -PropertyType "DWord"

Answer 12

जैसा कि ऊपर उल्लेख किया गया है हार्ड-कोडिंग ServicePointManager.SecurityProtocolया स्पष्ट SchUseStrongCrypto कुंजी का एक विकल्प :
आप .NET को बता सकते हैं कि SystemDefaultTlsVersions कुंजी के साथ डिफ़ॉल्ट SCHANNEL सेटिंग्स का उपयोग करें,
जैसे:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319] "SystemDefaultTlsVersions"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319] "SystemDefaultTlsVersions"=dword:00000001

Answer 13

इस समस्या का सबसे अच्छा समाधान कम से कम .NET 4.6 या बाद के उन्नयन के लिए प्रतीत होता है, जो स्वचालित रूप से मजबूत प्रोटोकॉल और साथ ही मजबूत सिफर का चयन करेगा।

यदि आप .NET 4.6 में अपग्रेड नहीं कर सकते हैं, तो सेटिंग की सलाह

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

और रजिस्ट्री सेटिंग्स का उपयोग करना:

HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft.NETFramework \ v4.0.30319 - SchUseStrongCrypto = DWORD of 1 HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow64NNode \ Microsoft.NETFramework \ v4.0.30319 - SchUseStrongCrypto = DWORD 1

टीएलएस 1.0 और एक मजबूत सिफर के अलावा कुछ और का उपयोग करने के परिणामस्वरूप।

मेरे परीक्षण में, केवल Wow6432Node में सेटिंग से कोई फर्क पड़ा, भले ही मेरा परीक्षण एप्लिकेशन किसी भी CPU के लिए बनाया गया था।

Comments

स्पष्टता: आपको केवल सेटिसविज़न मैनजर.सुरक्षाप्रोटोकॉल या रजिस्ट्री सेटिंग्स सेट करने की आवश्यकता है। दोनों करने की कोई जरूरत नहीं है। मेरे आवेदन के लिए, मैंने सिर्फ ServicePointManager.SecurityProtocol को चुना। मेरा तर्क यह है कि रजिस्ट्री की स्थापना पूरी मशीन को प्रभावित करती है, और मैं नहीं चाहता था कि किसी और का आवेदन टूट जाए क्योंकि यह टीएलएस 1.0 पर निर्भर था।

— GWC

Answer 14

के अनुसार ट्रांसपोर्ट लेयर सिक्योरिटी (TLS) .नेट फ्रेमवर्क के साथ सर्वोत्तम प्रथाओं : सुनिश्चित करने के लिए .NET फ्रेमवर्क अनुप्रयोगों सुरक्षित रहते हैं, TLS वर्शन चाहिए नहीं hardcoded किया। इसके बजाय रजिस्ट्री कुंजी सेट करें: SystemDefaultTlsVersions और SchUseStrongCrypto :

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

Answer 15

यदि आप .NET 4.7.1 या नए का उपयोग कर सकते हैं, तो यह ऑपरेटिंग सिस्टम क्षमताओं के आधार पर न्यूनतम प्रोटोकॉल के रूप में TLS 1.2 का उपयोग करेगा। प्रति Microsoft अनुशंसा:

To ensure .NET Framework applications remain secure, the TLS version should not be hardcoded. .NET Framework applications should use the TLS version the operating system (OS) supports.

Answer 16

कुंजी के लिए: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft.NETFramework \ v4.0.30319 मूल्य: SchUseStrongCrypto

आपको मान 1 पर सेट करना होगा।

Comments

मुझे लगता है कि आप निराश हो रहे हैं क्योंकि इसका एक ही जवाब @ जीरा मार्स ने पेश किया है, लेकिन कम विवरण के साथ

— स्टुअर्ट सिगलर