এসএসএল ফ্যালব্যাক অক্ষম করুন এবং .NET এ আউটবাউন্ড সংযোগের জন্য কেবল টিএলএস ব্যবহার করবেন? (পুডল প্রশমন)

Question

আমি পোডল এসএসএল 3.0 ফ্যালব্যাক আক্রমণে আমাদের দুর্বলতা হ্রাস করার চেষ্টা করছি । আমাদের প্রশাসকরা ইতিমধ্যে আমাদের সার্ভারের অভ্যন্তরীণ সংযোগের জন্য টিএলএসের পক্ষে এসএসএল অক্ষম করা শুরু করেছেন। এবং আমরা আমাদের দলকে তাদের ওয়েব ব্রাউজারগুলিতে এসএসএল অক্ষম করার পরামর্শও দিয়েছি। আমি এখন আমাদের .NET কোডবেজটির দিকে নজর দিচ্ছি , যা System.Net.HttpWebRequest এর মাধ্যমে বিভিন্ন পরিষেবার সাথে এইচটিটিপিএস সংযোগ শুরু করে । আমি বিশ্বাস করি যে টিএলএস থেকে এসএসএল ফালব্যাকের অনুমতি দিলে এই সংযোগগুলি একটি এমআইটিএম আক্রমণে ঝুঁকিপূর্ণ হতে পারে। আমি এখন পর্যন্ত যা স্থির করেছি তা এখানে। আমি সঠিক কিনা তা যাচাই করতে কেউ দয়া করে এটি ডাবল-চেক করতে পারেন? এই দুর্বলতা একেবারে নতুন, সুতরাং কীভাবে এটি নেট থেকে কমিয়ে আনা যায় সে সম্পর্কে মাইক্রোসফ্টের কাছ থেকে এখনও আমার কোনও গাইডেন্স নেই:

1. সিস্টেম.নেট.সিকিউরিটি.এসএসল স্ট্রিম ক্লাসের জন্য অনুমোদিত প্রোটোকলগুলি, যা নেট থেকে নিরাপদ যোগাযোগের ব্যবস্থা করে, প্রতিটি অ্যাপডোমেনের জন্য সিস্টেম.নেট.সোর্সপোয়েন্টম্যানেজার.সিকিউরিটিপ্রোটোকল সম্পত্তি দ্বারা বিশ্বব্যাপী সেট করা হয় ।

2. .NET 4.5 এ এই সম্পত্তিটির পূর্বনির্ধারিত মান হ'ল Ssl3 | Tls(যদিও আমি এটির ব্যাক আপ করার জন্য ডকুমেন্টেশন খুঁজে পাই না)) সিকিউরিটিপ্রোটোকল টাইপ হ'ল পতাকা বৈশিষ্ট্যযুক্ত একটি এনাম, সুতরাং এটি দুটি মানের থেকে কিছুটা বিপরীত বা OR আপনি এই কোডের এই লাইন দিয়ে আপনার পরিবেশে এটি পরীক্ষা করতে পারেন:

   Console.WriteLine (System.Net.ServicePointManager.SecurityProtocol.ToString ());

3. আপনার অ্যাপ্লিকেশনটিতে কোনও সংযোগ শুরু করার আগে এটিকে ন্যায়সঙ্গত Tlsবা সম্ভবত পরিবর্তন করা উচিত Tls12:

   সিস্টেম.নেট.সেবারপয়েন্ট ম্যানেজ.সিকিউরিটিপ্রোটোকল = সিস্টেম.নেট.সিকিউরিটিপ্রোটোকল টাইপ.টলস;

4. গুরুত্বপূর্ণ: যেহেতু সম্পত্তিটি একাধিক বিটওয়াইড পতাকা সমর্থন করে, তাই আমি ধরে নিয়েছি যে হ্যান্ডশেকের সময় এসএসপ্ল্রিম স্বয়ংক্রিয়ভাবে অন্যান্য অনির্ধারিত প্রোটোকলগুলিতে ফালব্যাক করবে না । অন্যথায়, একাধিক পতাকা সমর্থন করার বিন্দু কি হবে?

টিএলএস 1.0 আপডেট বনাম 1.1 / 1.2:

গুগল সুরক্ষা বিশেষজ্ঞ অ্যাডাম ল্যাংলির মতে, টিএলএস ১.০ পরে সঠিকভাবে প্রয়োগ না করা হলে পুডেলের পক্ষে ঝুঁকিপূর্ণ বলে মনে হয়েছিল , সুতরাং আপনার একচেটিভাবে টিএলএস ১.২ এ যাওয়ার বিষয়টি বিবেচনা করা উচিত।

.NET ফ্রেমওয়ার্ক 4.7 এবং তারপরের জন্য আপডেট করুন:

নীচে অধ্যাপক ভন লেমনগারগেল দ্বারা ইঙ্গিত হিসাবে , .NET ফ্রেমওয়ার্কের ৪. version সংস্করণ থেকে শুরু করে, এই হ্যাকটি ব্যবহার করার দরকার নেই কারণ ডিফল্ট সেটিংস ওএসকে সবচেয়ে সুরক্ষিত টিএলএস প্রোটোকল সংস্করণ চয়ন করতে দেয়। দেখুন ট্রান্সপোর্ট লেয়ার সিকিউরিটি (TLS) .NET ফ্রেমওয়ার্ক সর্বোত্তম কার্যাভ্যাস আরও তথ্যের জন্য।

Comments

উপরের পয়েন্ট ২ সম্পর্কিত: দেখুন রেফারেন্সসোর্স.মাইক্রোসফটকম / # সিস্টেমেট / নেট / সিস্টেমে / নেট / P এসএসএলপ্রোটোকলস "ডিফল্ট = এসএসএল 3 | টিএলএস"

— ডাই বোক

@ ডাই বোক ডিফল্ট এখন সিস্টেমডাফল্ট

— ডটনেট /

@ মারওয়াআহমাদ যদি এটি হয় তবে আমার লিঙ্কে উত্স কোড রেফারেন্সটি ডিফল্ট (48 | 192) প্রতিফলিত করে না। যদি কোনও (0) এ সেট করা থাকে তবে এটি সিস্টেম ডিফল্টে ফিরে যেতে পারে। এটি আমার কাছে দুর্গন্ধযুক্ত এবং আমি সম্ভবত পরিবর্তনগুলি করার আগে এটি পরীক্ষা করবো কারণ এটি মিসকনফিগারেশন হতে পারে ... এবং ভুল। নেট ফ্রেমওয়ার্কে প্রোটোকল বন্ধ করে দিতে পারে ...

— ডাই বোক

Answer 1

আমরা একই জিনিস করছি। কেবলমাত্র টিএলএস ১.২ এবং কোনও এসএসএল প্রোটোকল সমর্থন করতে আপনি এটি করতে পারেন:

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

সিকিউরিটিপ্রোটোকলটাইপ.টি.এলগুলি কেবলমাত্র টিএলএস 1.0, সমস্ত টিএলএস সংস্করণ নয়।

পাশ হিসাবে: আপনি যদি এটি পরীক্ষা করতে চান যে আপনার সাইটটি এসএসএল সংযোগের অনুমতি দেয় না, আপনি এখানে এটি করতে পারেন (আমি মনে করি না এটি উপরের সেটিং দ্বারা প্রভাবিত হবে), আইআইএসকে টিএলএস ব্যবহার করতে বাধ্য করার জন্য আমাদের রেজিস্ট্রি সম্পাদনা করতে হয়েছিল আগত সংযোগগুলির জন্য): https://www.ssllabs.com/ssltest/index.html

আইআইএসে এসএসএল 2.0 এবং 3.0 অক্ষম করতে, এই পৃষ্ঠাটি দেখুন: https://www.sslshopper.com/article-how-to-disable-ssl-2.0-in-iis-7.html

Comments

ঠিক। নতুন টিএলএস সংস্করণগুলিকেও সমর্থন করার জন্য ভাল ধারণা: ভবিষ্যত-প্রুফিং।

— জর্ডান রিজার 21

এবং অন্যের উপকারের জন্য, আপনি উল্লিখিত রেজিস্ট্রি সম্পাদনাগুলি এই পদক্ষেপগুলি দিয়েও করা যেতে পারে: serverfault.com/a/637263/98656 । উইন্ডোজ সার্ভার ২০০৩ থেকে ২০১২ আর -2 এ প্রোটোকলগুলি HKEY_LOCAL_MACHINE Y SYSTEM \ কারেন্টকন্ট্রোলসেট \ নিয়ন্ত্রণ \ সিকিউরিটিপ্রাইডারস \ স্ক্যানেল \ প্রোটোকলগুলিতে পতাকা দ্বারা নিয়ন্ত্রিত হয়। SSLv3 অক্ষম করতে, উপরের অবস্থানে 'এসএসএল 3.0' নামের একটি সাবকি তৈরি করুন এবং তার অধীনে 'সার্ভার' নামে একটি সাবকি এবং তার অধীনে, 'এনএবলড' নামের একটি ডিডব্লর্ড মান, 0-এ সেট করা আছে আপনার এসএসএল ২.০ অক্ষম করা উচিত একই পথে.

— জর্ডান রিজার

@ স্কটটারমনকি আপনার কেবলমাত্র সিস্টেম.নেট.সেবার পয়েন্ট ম্যানেজ.সিকিউরিটি প্রোটোকল সেট করতে হবে যদি আপনি .NET কোড থেকে আউটবাউন্ড সংযোগ শুরু করেন, যেমন আপনার সার্ভারে চলমান কাস্টম কোড থেকে কোনও ওয়েব পরিষেবা বা এপিআইতে সংযোগ স্থাপন করা। আপনি যদি কেবল একটি সাধারণ ওয়েবসাইট চালাচ্ছেন এবং আপনি কেবল ব্রাউজারগুলি থেকে আগত সংযোগগুলি গ্রহণ করছেন , তবে রেজিস্ট্রি ঠিক করা যথেষ্ট।

— জর্দান রিজার 21

দ্রষ্টব্য: এটি উপস্থিত হয় SecurityProtocolType.Tls11এবং SecurityProtocolType.Tls12এনাম মানগুলি কেবলমাত্র ASP.net 4.5 এবং এর চেয়ে বেশি ক্ষেত্রে উপলভ্য। টিএলএস ১.০ পথ ধরে চললে আমাদের পুরানো কোড বেসগুলিতে ২.০-তে চলতে হবে তা নিশ্চিত নন।

— স্যাম

@ আনিশভি আপনি যে অ্যাপ্লিকেশনটি আউটসাউন্ড এসএসএল / টিএলএস সংযোগ শুরু করে তার আগে আপনার অ্যাপের প্রারম্ভিককরণের ক্ষেত্রে কোডটির লাইনটি রেখে দিয়েছেন।

— জর্দান রিগার

Answer 2

@ এডি লোফেনের উত্তরটি এই প্রশ্নের সর্বাধিক জনপ্রিয় উত্তর বলে মনে হচ্ছে তবে এর কিছু খারাপ দীর্ঘমেয়াদী প্রভাব রয়েছে। আপনি যদি সিস্টেম.নেট.সেবার পয়েন্ট ম্যানেজ.সিকিউরিটি প্রোটোকলের জন্য ডকুমেন্টেশন পৃষ্ঠাটি পর্যালোচনা করেন তবে এখানে মন্তব্যগুলির বিভাগটি বোঝায় যে আলোচনার পর্বটি কেবল এটির সমাধান করা উচিত (এবং প্রোটোকল জোর করা খারাপ অভ্যাস কারণ ভবিষ্যতে, টিএলএস ১.২ এছাড়াও আপস করা হবে)। যাইহোক, আমরা যদি উত্তরটি না দিয়ে তা খুঁজছি না।

গবেষণা করে দেখা যাচ্ছে যে আলোচনার পর্যায়ে টিএলএস ১.২ এ যাওয়ার জন্য ALPN আলোচনার প্রোটোকলটির প্রয়োজন। আমরা এটিকে আমাদের প্রারম্ভিক পয়েন্ট হিসাবে নিয়েছি এবং সমর্থনটি কোথায় শুরু হয় তা দেখার জন্য নেট ফ্রেমওয়ার্কের নতুন সংস্করণগুলি চেষ্টা করেছি। আমরা খুঁজে পেয়েছি যে নেট .৪.২.২ টিএলএস ১.২ এর সাথে আলোচনার সমর্থন করে না, তবে নেট 4.6 করে।

সুতরাং, যদিও টিএলএস 1.2 জোর করে এখনই কাজটি সম্পন্ন হবে, আমি আপনাকে সুপারিশ করছি আপনি পরিবর্তে। নেট 4.6 এ আপগ্রেড করুন। যেহেতু এটি জুন ২০১ for সালের জন্য একটি পিসিআই ডিএসএস ইস্যু, উইন্ডোটি সংক্ষিপ্ত, তবে নতুন কাঠামো আরও ভাল উত্তর।

আপডেট: মন্তব্যগুলি থেকে কাজ করে, আমি এটি তৈরি করেছি:

ServicePointManager.SecurityProtocol = 0;    
foreach (SecurityProtocolType protocol in SecurityProtocolType.GetValues(typeof(SecurityProtocolType)))
    {
        switch (protocol)
        {
            case SecurityProtocolType.Ssl3:
            case SecurityProtocolType.Tls:
            case SecurityProtocolType.Tls11:
                break;
            default:
                ServicePointManager.SecurityProtocol |= protocol;
            break;
        }
    }

ধারণাটি বৈধকরণের জন্য, আমি এসএসএল 3 এবং টিএলএস 1.2 একসাথে করেছি এবং একটি সার্ভারকে লক্ষ্য করে কোডটি চালিয়েছি যা কেবলমাত্র টিএলএস 1.0 এবং টিএলএস 1.2 সমর্থন করে (1.1 অক্ষম করা আছে)। Ordd প্রোটোকলগুলির সাথে, এটি সূক্ষ্মভাবে সংযুক্ত বলে মনে হচ্ছে। যদি আমি এসএসএল 3 এবং টিএলএস 1.1 এ পরিবর্তন করি তবে এটি সংযোগ করতে ব্যর্থ হয়েছে। আমার বৈধতাটি System.Net থেকে এইচটিপিওয়েবরেউকস্ট ব্যবহার করে এবং কেবলমাত্র গেটআরস্পোন () কল করে। উদাহরণস্বরূপ, আমি এটি চেষ্টা করেছিলাম এবং ব্যর্থ হয়েছি:

        HttpWebRequest request = WebRequest.Create("https://www.contoso.com/my/web/resource") as HttpWebRequest;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls11;
        request.GetResponse();

এটি কাজ করার সময়:

        HttpWebRequest request = WebRequest.Create("https://www.contoso.com/my/web/resource") as HttpWebRequest;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls12;
        request.GetResponse();

এটিতে টিএলএস 1.2 জোর করে দেওয়ার একটি সুবিধা রয়েছে, যদি নেট ফ্রেমওয়ার্কটি আপগ্রেড করা হয় যাতে এনামে আরও এন্ট্রি থাকে, তারা কোড অনুসারে সমর্থন করবে। কেবলমাত্র 4.6 নেট ব্যবহারের ক্ষেত্রে এটির অসুবিধা রয়েছে 4..6 এ নেট 4.6 এএলপিএন ব্যবহার করে এবং কোনও বিধিনিষেধ নির্দিষ্ট না করা থাকলে নতুন প্রোটোকল সমর্থন করা উচিত।

4/29/2019 সম্পাদনা করুন - মাইক্রোসফ্ট গত অক্টোবরে এই নিবন্ধটি প্রকাশ করেছে । এটি নেট। ফ্রেমওয়ার্কের বিভিন্ন সংস্করণে কীভাবে করা উচিত সে সম্পর্কে তাদের সুপারিশের একটি দুর্দান্ত উত্তম প্রতিভা আছে।

Comments

মজাদার. দেখে মনে হচ্ছে ডকুমেন্টেশন পৃষ্ঠাটি এমএসডিএন ".NET ফ্রেমওয়ার্ক (বর্তমান সংস্করণ) " এ সরানোর সাথে সাথে আপডেট হয়েছিল এবং এখন ব্যাখ্যা করে যে "উদ্দেশ্য হিসাবে এই সম্পত্তিটির জন্য কোনও ডিফল্ট মান তালিকাভুক্ত করা হয়নি।" সম্ভবত অনুমোদিত প্রোটোকলের তালিকাটি পুনরুদ্ধার করার জন্য প্রথমে সম্পত্তিটিকে জিজ্ঞাসা করা, এবং তারপরে আপনার অ্যাপ্লিকেশনটি সুরক্ষিতভাবে কেবল যুক্ত করার পরিবর্তে নিরাপদ (যেমন টিএলএস ১.২ এর চেয়ে কম কিছু) বিবেচনা করে সেগুলি সরিয়ে ফেলা হবে বলে গ্রহণযোগ্য উত্তরের আরও ভবিষ্যত-প্রমাণ সংস্করণ হবে Perhaps আপনি যেটিকে নিরাপদ বলে মনে করেন। এটি ভবিষ্যতে নতুন সংস্করণ বাদ দেবে না।

— জর্দান রিজার

প্রোগ্রামটি সিস্টেমটি যে তালিকা তৈরি করে তা থেকে প্রোটোকল সরিয়ে ফেলতে সক্ষম হওয়াই ভাল হবে তবে আমি বর্তমান এপিআইতে এটি করার কোনও উপায় দেখতে পাচ্ছি না। একমাত্র বিকল্পটি নির্দিষ্ট প্রোটোকলকে জোর করা বলে মনে হচ্ছে, যেটি কেন করতে চাইবে তা আমি দেখছি না। দুর্ভাগ্যক্রমে, ALPN সমর্থন ব্যতীত, এটি কাজ করার জন্য TLS1.2 সংযোগ পাওয়ার একমাত্র উপায় বলে মনে হয়।

— প্রফেসর ভন লেমনগার্গেল

সমস্ত সিকিউরিটিপ্রোটোকল টাইপ এনামগুলির মধ্য দিয়ে লুপ করা সম্ভব হবে, সার্ভিসপয়েন্ট ম্যানেজ.সিকিউরিটি প্রোটোকল ফ্ল্যাগ এনামে কোনটি উপস্থিত রয়েছে তা দেখুন (এটি সমস্ত সেট পতাকাগুলির একটি যৌক্তিক OR হয়, সুতরাং আপনি প্রতিটি এ্যান্ডের সাথে পরীক্ষা করতে পারেন) এবং তারপরে একটি নতুন বিল্ড তৈরি করুন আপনি মুছে ফেলতে চান না এমনগুলির সাথে তাদের তালিকা করুন। তারপরে এগুলিকে এক এনামের সাথে একত্রিত করুন এবং তার সাথে সম্পত্তি সেট করুন।

— জর্দান রিজার

আমি কেবল আপনার এনাম / লুপিং কোডটি পুনরায় পড়ছিলাম এবং আমি মনে করি এটি ভুল। | = লজিকাল অপারেটরের ফলে সম্পত্তিটিতে প্রথমে যে কোনও ডিফল্ট মান নির্ধারণ করা হয়েছিল, কেবলমাত্র Tls12 এবং তার চেয়ে বেশিকে অন্তর্ভুক্ত করার পরিবর্তে সম্পত্তি হিসাবে দেখাবে। এটি ঠিক করতে, আপনাকে 0 মান সহ একটি সিকিউরিটিপ্রোটোকল টাইপ এনাম ভেরিয়েবল শুরু করতে হবে, সেই ভেরিয়েবলের বিরুদ্ধে | = লুপটি করতে হবে এবং তারপরে সার্ভিসপয়েন্ট ম্যানেজার.সিকিউরিটিপ্রোটোকল সম্পত্তিটিতে এটি অর্পণ করতে হবে।

— জর্দান রিগার

অন্য যে কেউ এটি পাগল বলে মনে হয় যে .NET এটি সক্ষম এমন সর্বোচ্চ প্রোটোকল সংস্করণটি স্বয়ংক্রিয়ভাবে আলোচনা করে না?!

— রমন

Answer 3

@watson

উইন্ডোজ ফর্মগুলিতে এটি ক্লাসের শীর্ষে রাখে

  static void Main(string[] args)
    {
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
       //other stuff here
    }

উইন্ডোজগুলি যেহেতু একক থ্রেডড, আপনার যা দরকার তা এটির প্রয়োজনে ইভেন্টে পরিষেবাটি কলের ঠিক উপরে রাখতে হবে (যেহেতু আপনি কোন থ্রেডে থাকবেন তা কোনও বলার অপেক্ষা রাখে না)।

using System.Security.Principal 

এছাড়াও প্রয়োজন হয়।

Answer 4

আপনি যদি উত্সাহী হন তবে কোন প্রোটোকলগুলি নেট সমর্থন করে, আপনি https://www.howsmyssl.com/ এ এইচটিটিপি ক্লায়েন্ট চেষ্টা করে দেখতে পারেন

// set proxy if you need to
// WebRequest.DefaultWebProxy = new WebProxy("http://localhost:3128");

File.WriteAllText("howsmyssl-httpclient.html", new HttpClient().GetStringAsync("https://www.howsmyssl.com").Result);

// alternative using WebClient for older framework versions
// new WebClient().DownloadFile("https://www.howsmyssl.com/", "howsmyssl-webclient.html");

ফলাফল ক্ষয়ক্ষতি হয়:

আপনার ক্লায়েন্ট টিএলএস 1.0 ব্যবহার করছেন, যা খুব পুরানো, সম্ভবত বেস্ট আক্রমণে সংবেদনশীল এবং এতে সেরা সিফার স্যুট নেই। MD5-SHA-1 প্রতিস্থাপন করতে AES-GCM, এবং SHA256 এর মতো সংযোজনগুলি একটি টিএলএস 1.0 ক্লায়েন্টের পাশাপাশি আরও অনেক আধুনিক সাইফার স্যুইটের কাছে অনুপলব্ধ।

এডি উপরে বর্ণিত হিসাবে, আপনি ম্যানুয়ালি আরও ভাল প্রোটোকল সক্ষম করতে পারেন:

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

আমি জানি না যে এটি কেন বাইরে প্রোটোকল ব্যবহার করে। এটি একটি দুর্বল সেটআপ পছন্দ বলে মনে হচ্ছে, একটি প্রধান সুরক্ষা বাগের সমান (আমি প্রচুর অ্যাপ্লিকেশন ডিফল্টটি পরিবর্তন করে না) bet আমরা কীভাবে এটি রিপোর্ট করতে পারি?

Answer 5

আমি এখনও নেট নেট ব্যবহার করছি around

System.Net.ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;
/* Note the property type  
   [System.Flags]
   public enum SecurityProtocolType
   {
     Ssl3 = 48,
     Tls = 192,
     Tls11 = 768,
     Tls12 = 3072,
   } 
*/

Comments

এটি কাজ করে কিন্তু .NET 4.0 টিএলএস 1.2 সমর্থন করে না, তবে। নেট 4.5 এবং উচ্চতর টিএলএস 1.2 সমর্থন করে। সুতরাং আপনি আপনার .NET 4.0 অ্যাপ্লিকেশনটিতে এই কোডটি যুক্ত করতে পারেন (বা কিছুটা দিক বা টিএলএস 1.2 আলোচনার জন্য সমর্থন যোগ করতে) এবং এটি তৈরি করতে পারেন তবে আপনার কোডটি নেট 4.5 বা তার বেশি বা তার উপর স্থাপন করতে হবে। ব্লগস.পারফিশিয়েন্ট

— মাইক্রোসফট

এছাড়াও এই দেখুন, .NET 4.0 কোড উচ্চতর সংস্করণ জরিমানা কাজ করবে .NET .NET 4.5 এবং .NET 4.6 সহ stackoverflow.com/questions/33378902/...

— rboy

পূর্ণসংখ্যা কাস্ট টিএলএস 1.2 পাঠানোর জন্য কাজ করেছিল। Tls12 এনাম মানটি কেবলমাত্র বিদ্যমান নেই

— N

দুটি ভিন্ন পয়েন্ট। আমার মন্তব্য দেখুন। আপনি মানটি রাখতে পারেন তবে আপনার রানটাইম নেট সংস্করণটি যদি 4.0 হয় তবে এটি ব্যর্থ হবে। আপনি এই পতাকাটি দিয়ে সঙ্কলন করতে পারেন তবে আপনার রানটাইম .NET 4.0 এ বেস উপাদান হিসাবে 4.5 বা তত বেশি হওয়া দরকার TLS 1.2 এর জন্য প্রয়োজনীয়

— সিফারগুলিকে

টিএলএস 1.2 সমর্থন যুক্ত করার জন্য পুরানো .NET রানটাইম সংস্করণগুলির জন্য বেশ কয়েকটি হটফিক্স রয়েছে। উদাহরণস্বরূপ, support.microsoft.com/en-us/help/3154518/… , সি জহরবস্কি উইন 10 ফল ক্রিয়েটর আপডেটে এটি ব্যবহার করতে পারত যা হটফিক্সও অন্তর্ভুক্ত করেছিল।

— নিঃশব্দ সুর

Answer 6

আমি খুঁজে পেয়েছি সবচেয়ে সহজ সমাধানটি হ'ল নীচে দুটি রেজিস্ট্রি এন্ট্রি যুক্ত করা (অ্যাডমিন সুবিধার সাথে একটি কমান্ড প্রম্পটে এটি চালান):

reg add HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /v SchUseStrongCrypto /t REG_DWORD /d 1 /reg:32

reg add HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /v SchUseStrongCrypto /t REG_DWORD /d 1 /reg:64

এই এন্ট্রিগুলি ক্লায়েন্ট হিসাবে সুরক্ষিত সংযোগ তৈরি করার সময় কীভাবে নেট নেট সিএলআর একটি প্রোটোকল চয়ন করে তা প্রভাবিত করে।

এখানে এই রেজিস্ট্রি এন্ট্রি সম্পর্কে আরও তথ্য রয়েছে:

https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2015/2960358#suggested-actions

কেবল এটিই সহজ নয়, তবে এটি ধরে নেওয়া আপনার কোডের জন্য কার্যকর, কোড-ভিত্তিক সমাধানের চেয়ে অনেক বেশি শক্তিশালী, যার জন্য বিকাশকারীদের প্রোটোকল এবং বিকাশ এবং তাদের সমস্ত প্রাসঙ্গিক কোড আপডেট করতে হবে। আশা করি, TLS 1.3 এবং এর বাইরেও, একই রকম পরিবেশগত পরিবর্তনগুলি করা যেতে পারে, যতক্ষণ না .NET স্বয়ংক্রিয়ভাবে সর্বোচ্চ উপলব্ধ প্রোটোকলটি না বেছে নেওয়ার জন্য যথেষ্ট মূক থাকে।

দ্রষ্টব্য : যদিও উপরের নিবন্ধ অনুসারে, এটি কেবল আরসি 4 অক্ষম করার কথা, এবং কেউই ভাবেন না যে এটি নেট ক্লায়েন্টকে TLS1.2 + ব্যবহার করার অনুমতি দেয় কি না, কোনও কারণে এটির রয়েছে প্রভাব।

দ্রষ্টব্য : মন্তব্যগুলিতে @ জর্ডান রিজার দ্বারা উল্লিখিত হিসাবে, এটি পুডলের পক্ষে কোনও সমাধান নয়, যেহেতু এটি পুরানো প্রোটোকলগুলিকে অক্ষম করে না - এটি কেবল ক্লায়েন্টকে নতুন প্রোটোকল দিয়ে কাজ করার অনুমতি দেয় যেমন একটি প্যাচ সার্ভার যখন পুরানো অক্ষম করে দেয় প্রোটোকল। তবে, একটি এমআইটিএম আক্রমণ দ্বারা স্পষ্টতই একটি আপসযুক্ত সার্ভার ক্লায়েন্টকে একটি পুরানো প্রোটোকল সরবরাহ করবে, যা ক্লায়েন্টটি পরে খুশির সাথে ব্যবহার করবে।

করণীয় : তবে আমি .NET HTTP ক্লায়েন্ট লাইব্রেরী এই সেটিংস বা না সম্মান জানি না এই রেজিস্ট্রি এন্ট্রি সঙ্গে TLS1.0 এবং TLS1.1 নিষ্ক্রিয় ক্লায়েন্ট-সাইড ব্যবহার করার চেষ্টা করুন,:

https://docs.microsoft.com/en-us/windows-server/security/tls/tls-registry-settings#tls-10

https://docs.microsoft.com/en-us/windows-server/security/tls/tls-registry-settings#tls-11

Comments

একটি কোডের বিকল্প হিসাবে রেজিস্ট্রি সেটিংস দুর্দান্ত হবে, তবে এই সেটিংসটি কি কেবল টিএলএস 1.2 এবং এর উপরের ক্লায়েন্ট সংযোগের অনুমতি দেওয়ার পক্ষে টিএলএস 1.0 এবং 1.1 অক্ষম করে? লিঙ্ক অনুসারে, মনে হচ্ছে এটি কেবল টিএলএসে আরসি 4 অক্ষম করে। আমি মনে করি পোডল আক্রমণটি এর চেয়ে বিস্তৃত।

— জর্দান রিগার

@ জর্ডানরিগ্রার এই রেজিস্ট্রি এন্ট্রিগুলি একটি .NET ক্লায়েন্টকে এমন একটি সার্ভারের সাথে সংযোগ স্থাপনের অনুমতি দেয় যা পুডলকে প্রশমিত করতে পুরানো প্রোটোকলগুলি অক্ষম করে। এগুলি ব্যতীত, ক্লায়েন্টটি একটি নেট ত্রুটি নিক্ষেপ করবে কারণ .NET ক্লায়েন্ট বোকামির সাথে সার্ভার নতুনটির জন্য জিজ্ঞাসা করার সময়ও পুরানো প্রোটোকলটি ব্যবহার করার জন্য জোর করে। আপনার সার্ভারটি এখনও পুরানো প্রোটোকল ব্যবহার করে সংযোগের অনুমতি দিলে সমস্ত বেট বন্ধ রয়েছে। তাত্ত্বিকভাবে পুরানো প্রোটোকলগুলি অক্ষম করা উচিত । আমি ভাবছি যে একই রেজিস্ট্রি এন্ট্রিগুলি সার্ভারে এগুলি অক্ষম করার অনুমতি দেয় (যেমন nartac.com/Products/IISCrypto ) ক্লায়েন্টের জন্যও কাজ করবে?

— রমন

নর্তাক ম্যানিপুলেট করে যে রেজিস্ট্রি এন্ট্রিগুলিতে, ক্লায়েন্ট এবং (যখন অভিনয় করা হয়) সার্ভারের জন্য আলাদা সেটিংস রয়েছে। আমি মনে করি না তাদের ইন্টারফেসটি যদিও আলাদা করে। আপনি কি জানেন যে .net এর কোন সংস্করণগুলি এই রেজিস্ট্রি হ্যাকটিকে সমর্থন করে?

— অধ্যাপক ভন লেমনগারেলে

@ রমন আমার প্রশ্নের মূল বক্তব্যটি হ'ল, যখন আপনার ক্লায়েন্টটি আপনাকে নিয়ন্ত্রণ না করে এমন কোনও সার্ভারের সাথে সংযোগ স্থাপন করার সময় পুডেল দুর্বলতা প্রশমিত করবে। দুর্বলতা একটি এমআইটিএম আক্রমণকারীকে প্রোটোকলটিকে পুরানো টিএলএস বা এসএসএল সংস্করণে ডাউনগ্রেড করার অনুমতি দেবে যা হ্যাক হতে পারে। কেবল আরসি 4 অক্ষম করা যথেষ্ট নয়। এই রেজিস্ট্রি সেটিংসটি কিছু ক্ষেত্রে উপযুক্ত হতে পারে তবে আমার প্রশ্নের দৃশ্যে নয়।

— জর্ডান রিগার

পছন্দ করেছেন কিছু অতিরিক্ত পর্যবেক্ষণ এবং চিন্তাভাবনা নিয়ে আমি পাঠ্যটি আপডেট করেছি।

— রমন