শেয়ার করা DH গ্রুপ, নতুন গোপনীয়তা: আক্রমণ কেন সস্তা হয়

গ্রুপ প্যারামিটার ডিজাইন অনুযায়ীই প্রকাশ্য, এবং সেই প্রকাশ্যতাই সেগুলোকে উপেক্ষা করা সহজ করে তোলে। সসীম-ক্ষেত্র Diffie-Hellman-এ মডুলাস ও জেনারেটর শেয়ার করা হয়, কিন্তু ব্যক্তিগত সূচক ও উৎপন্ন সেশন-কী শেয়ার করা হয় না। সংখ্যা-ক্ষেত্র চালনির আক্রমণের ব্যয়বহুল পর্যায়টি একটি বিনিময়ের বদলে গ্রুপের উপর নির্ভর করে, তাই সর্বত্র ব্যবহৃত একটি দুর্বল গ্রুপ একটি যৌথ দায় হয়ে দাঁড়ায়। প্যারামিটারগুলোকে প্রকাশ্য বলা যথার্থ, কিন্তু মূল বিষয়ের বাইরে, কারণ যে ব্যয় পুনরায় ব্যবহৃত হয় তা ওই গ্রুপে আক্রমণের ব্যয়।

প্রকাশ্য অর্ধেকটাই দুর্বল অর্ধেক নয়, আর এখানেই ফাঁদ

চেনা অর্ধ-যুক্তি বলে, প্যারামিটার একটি মানদণ্ডে প্রকাশিত, তাই আক্রমণকারী সেগুলো আগেই জানে এবং লুকালে কিছুই বদলাত না। দুটি দাবিই সত্য, এবং একটি থেকে অন্যটি অনুসৃত হয় না। সরবরাহকৃত ডিফল্ট গ্রুপ প্রকাশ্য, আর গত সপ্তাহে আপনি যে ব্যক্তিগত গ্রুপ তৈরি করেছেন সেটিও হ্যান্ডশেক সম্পূর্ণ করা যে কেউ দেখতে পায়। গোপনীয়তা কখনোই নিয়ন্ত্রণ ছিল না; শক্তি ও যাচাই ছিল।

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

আকারের মতোই যাচাই গুরুত্বপূর্ণ। যে পিয়ার ছোট গুণনীয়কযুক্ত মডুলাস পাঠায়, বা প্রোটোকল যে আকার আশা করে তা নয় এমন মডুলাস পাঠায়, সে বিট-দৈর্ঘ্য সম্মানজনক দেখালেও ব্যক্তিগত সূচক সম্পর্কে তথ্য ফাঁস করতে পারে। যে লাইব্রেরি প্রবেশপথেই বিকৃত প্যারামিটার প্রত্যাখ্যান করে তারা প্রকৃত কাজ করছে, তাই হাতে লেখা প্যারামিটার পার্সিং পরিশ্রম বাঁচানোর খারাপ জায়গা।

পূর্ব-গণনা আক্রমণকারীকে আসলে কী দেয়

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

2015 সালের Logjam গবেষণাপত্রটি 512-বিট রপ্তানি-মানের Diffie-Hellman-এ অবনমন প্রদর্শন করেছিল এবং বড়, ব্যাপকভাবে পুনর্ব্যবহৃত গ্রুপে উল্লেখযোগ্য সম্পদ দিয়ে আক্রমণের খরচ কত হবে তা অনুমান করেছিল। প্রদর্শনটি ছিল সুনির্দিষ্ট, অনুমানগুলো ছিল অনুমান, এবং কোনোটিই কোনো নির্দিষ্ট VPN সেশন ডিক্রিপ্ট হয়েছে তার প্রমাণ নয়।

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

মানসম্মত হওয়া দুর্বল হওয়ার সমান নয়

RFC 7919 নামকৃত সসীম-ক্ষেত্র গ্রুপ সংজ্ঞায়িত করে যাতে দুই প্রান্ত শনাক্তকারী দিয়ে একটি গ্রুপে একমত হয় এবং সামঞ্জস্যপূর্ণ নীতি প্রয়োগ করে। মানসম্মত হওয়া একটি সুবিধা, কারণ এটি দরকষাকষির অস্পষ্টতা দূর করে এবং বাস্তবায়নকে অসমর্থিত আকার প্রত্যাখ্যান করতে দেয়। নামকৃত গ্রুপ কেবল তখনই দুর্বল যখন এর আকার আপনি যে নীতি অনুসরণ করার দাবি করেন তার নিচে, কোনো নথিতে থাকার কারণে নয়। একই যুক্তি উপবৃত্তাকার-বক্ররেখার গ্রুপের ক্ষেত্রেও প্রযোজ্য, যাদের গঠন ও ব্যর্থতার ধরন আলাদা।

তাদের বিষয়ে যুক্তি করার সময় নির্মাণগুলো আলাদা রাখুন। সসীম-ক্ষেত্র Diffie-Hellman সম্পর্কে সিদ্ধান্ত X25519 সম্পর্কে কিছুই বলে না, আর 1024-বিট MODP গ্রুপ সম্পর্কে সিদ্ধান্ত 3072-বিট গ্রুপ সম্পর্কে কিছুই বলে না। শক্তির নীতি প্রতিটি কৌশল, প্রতিটি আকার ও প্রতিটি প্রোটোকল সংস্করণের জন্য আলাদা, তাই শক্তিশালী ক্রিপ্টো বাক্যটি পর্যালোচনাযোগ্য বিবৃতি নয়।

প্রমাণীকরণ হলো অন্য অর্ধেক, এবং এটি বিকল্প নয়। পিয়ার যাচাই ছাড়া শক্তিশালী গ্রুপ আক্রমণকারীকে মাঝখানে রেখে যায়, আর বৈধ সার্টিফিকেট 768-বিট বিনিময়কে বাঁচাতে পারে না। এগুলোকে দুটি স্বাধীন লাইন হিসেবে পর্যালোচনা করুন, তারপর নিশ্চিত করুন দুটিই সত্যিই দরকষাকষি হয়েছে।

বাস্তব সংযোগে দরকষাকষি করা গ্রুপ পড়ুন

কনফিগারেশন টেমপ্লেট থেকে নয়, ডিভাইস থেকেই দরকষাকষি করা গ্রুপ পড়ুন। টেমপ্লেট অভিপ্রায় বর্ণনা করে, আর আকর্ষণীয় মান হলো শেষ হ্যান্ডশেকে দুই পক্ষ যে মানে সম্মত হয়েছে। IPsec প্রান্তে স্টেটাস আউটপুট সাধারণত নির্বাচিত প্রস্তাব ছাপে, MODP গ্রুপসহ।

নীতি পরিবর্তনের আগে ও পরে ওই লাইনটি ধরে রাখুন, এবং দুটিই পরিবর্তন-রেকর্ডে রাখুন। তুলনাই প্রমাণ।

ipsec statusall | grep -Ei "proposal|ESP|IKE"
openssl dhparam -in /etc/vpn/dh3072.pem -check -noout

পরিবর্তনের পরেও স্টেটাস যদি পুরোনো গ্রুপ দেখায়, সংযোগটি পুনরায় দরকষাকষি করেনি এবং কনফিগারেশন সম্পাদনা কিছুই প্রমাণ করেনি। পিয়ার পুনরায় চালু করুন বা সিকিউরিটি অ্যাসোসিয়েশন মুছে দিন, তারপর আবার স্টেটাস পড়ুন। কেবল নতুন সংযোগে প্রয়োগ করা নীতি দীর্ঘস্থায়ী টানেলগুলোকে যতদিন চালু থাকে ততদিন পুরোনো প্যারামিটারে রাখবে।

গ্রুপ ও পিয়ার পরিচয় আলাদাভাবে যাচাই করুন

গ্রুপ কী রক্ষা করে তা অন্যপ্রান্তে কে আছে তা থেকে আলাদা করুন। কী-বিনিময় পদ্ধতি, গ্রুপের আকার এবং প্রমাণীকরণ পদ্ধতি তিনটি ক্ষেত্র হিসেবে লিখুন, কারণ তারা স্বাধীনভাবে ব্যর্থ হয়। যে টানেল 3072-বিট গ্রুপে দরকষাকষি করেছে কিন্তু যেকোনো সার্টিফিকেট গ্রহণ করে, তা পিয়ার পিন করে 2048-বিট গ্রুপ ব্যবহার করা টানেলের মতো একই ঝুঁকি নয়।

পর্যালোচনা শুরুর আগেই গ্রহণযোগ্যতার মানদণ্ড লিখে রাখুন, যাতে ফলাফল মতামতের বদলে তুলনা হয়। প্রতিটি প্রোটোকল সংস্করণের জন্য সর্বনিম্ন গ্রুপ আকার, নামকৃত গ্রুপের অনুমোদন-তালিকা এবং বাধ্যতামূলক পিয়ার যাচাই সিদ্ধান্তকে যান্ত্রিক করতে যথেষ্ট। সেই তালিকার অস্পষ্টতাই পর্যালোচনাকে বিতর্কে পরিণত করে, আর বিতর্কের প্রতিকার হয় না। তখন ফলাফল হলো ঘোষিত নিয়ম ব্যর্থ করা প্রান্তবিন্দুর তালিকা।

ipsec statusall | grep -Ei "peer|auth|cert"
openssl s_client -connect vpn.acme.example:443 -brief -cipher 'DHE-RSA-AES256-GCM-SHA384'

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