8192 বিটের কী হ্যান্ডশেক আটকে দেয়; 1024 বিটের DH প্রত্যাখ্যাত হয়

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

কিছু পুনরুৎপাদন করার আগে ব্যর্থতাটা পড়ুন

সময়জ্ঞান এর বেশিরভাগই বলে দেয়। কয়েক সেকেন্ড নিয়ে তারপর মরে যাওয়া একটি হ্যান্ডশেক সাধারণত বোঝায় হিসাবটি প্রতিপক্ষের ধৈর্য ছাড়িয়ে গেছে, যা এমন প্যারামিটারের দিকে ইঙ্গিত করে যা হার্ডওয়্যার বা সময়সীমার জন্য খুব বড়। কী বা গ্রুপের আকার উল্লেখ করা তাৎক্ষণিক প্রত্যাখ্যান বিপরীত দিকে ইঙ্গিত করে, এমন উপাদানের দিকে যা লাইব্রেরি আদৌ গ্রহণ করবে না।

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

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

ধীর কেস: এমন উপাদান যা হার্ডওয়্যার বহন করতে পারে না

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

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

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

দ্রুত কেস: লাইব্রেরি যে গ্রুপ প্রত্যাখ্যান করে

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

চেক এড়াতে কনফিগারেশন সম্পাদনা করার বদলে ফাইলটি বদলে দিন। সাম্প্রতিক একটি গ্রুপ তৈরি করুন, যাচাই করুন, তারপর ডেমন আসলে যেখানে পড়ে সেখানেই এটি বসান। ক্লায়েন্ট নতুনটি দিয়ে সফলভাবে সংযোগ না করা পর্যন্ত পুরনো ফাইলটি রাখুন:

openssl dhparam -out /etc/openvpn/ffdhe2048.pem 2048
openssl dhparam -in /etc/openvpn/ffdhe2048.pem -check -noout
ls -l /etc/openvpn/ffdhe2048.pem

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

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

প্রতিপক্ষ ও হার্ডওয়্যারের জন্য আকার বাছুন

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

যেখানে সার্ভারের CPU-ই সীমা, সেখানে নীতির নিচে নামার বদলে অ্যালগরিদম বদলান। X25519-এর মতো উপবৃত্তাকার বক্ররেখার কী বিনিময় বড় সসীম-ক্ষেত্র গ্রুপের চেয়ে নাটকীয়ভাবে সস্তা এবং ব্যাপকভাবে সমর্থিত, যা এটিকে কর্মক্ষমতার অভিযোগের উত্তর হিসেবে ছোট RSA মডুলাসের চেয়ে ভালো করে তোলে।

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

পছন্দটি লিখে রাখুন যাতে পুনর্নির্মাণ তা বাতিল করতে না পারে

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

একই তথ্য এন্ডপয়েন্ট ও প্রোফাইলের পাশে লিখুন, যাতে পর্যালোচনায় ফাইলের আকার থেকে তা উল্টো করে বের করতে না হয়। পরের সংযোগটি আটকে গেলে সেই টীকাই পাঁচ মিনিটের চেক আর নতুন তদন্তের মধ্যে পার্থক্য। এটি পরের ইঞ্জিনিয়ারকে দ্রুত কেসের জন্য বানানো সমাধান দিয়ে ধীর কেসটি সমাধান করা থেকেও বিরত রাখে।