Linux پر AnyConnect کا غلط TLS ورژن: پہلے اصلاح کا دائرہ متعین کریں

یہ خرابی پاس ورڈ کی درخواست سے پہلے آتی ہے، اور یہی مفید حصہ ہے: ابھی کچھ بھی تصدیق شدہ نہیں، اس لیے اسناد مسئلہ نہیں ہیں۔ Linux پر وہی AnyConnect مکالمہ پرانے پروٹوکول ورژن، 1024 بٹ کلید کے تبادلے کے گروپ، یا ایسے سائفر سیٹ سے آ سکتا ہے جسے نظام کی کرپٹو پالیسی مسترد کرتی ہے۔ میں نے اسے تین مشینوں پر تین مختلف طریقوں سے دور کیا، اور ان حلوں میں فرق کرنے والی چیز چالاکی نہیں، اثر کا دائرہ ہے۔ ہر ایک صحیح جگہ پر جائز اور باقی ہر جگہ برا ڈیفالٹ ہے۔

پالیسی کو چھونے سے پہلے پیغام پڑھیں

مکالمے سے عین مطابق متن محفوظ رکھیں۔ ورژن کی شکایت پروٹوکول پرت کی طرف، سرٹیفکیٹ کی شکایت اعتماد یا نام کی طرف، اور ناکام لاگ ان اسناد کی طرف اشارہ کرتا ہے۔ TLS 1.0، 1024 بٹ DHE گروپ، AES-256-CBC اور SHA-1 دستخط پیش کرنے والا گیٹ وے مکمل طور پر درست سرٹیفکیٹ رکھ سکتا ہے اور پھر بھی آپ کی اسناد بھیجے جانے سے پہلے جدید پالیسی کی طرف سے مسترد ہو سکتا ہے۔

نظام کے OpenSSL سے اینڈپوائنٹ جانچیں، اصل ہوسٹ نام اور وہ پورٹ استعمال کرتے ہوئے جو کلائنٹ استعمال کرتا ہے۔

اگر openssl s_client -connect vpn.example.com:443 -servername vpn.example.com ناکام ہو اور -tls1 -cipher DEFAULT@SECLEVEL=0 کامیاب ہو تو حد ورژن اور کلید کا حجم دونوں ہے۔ اگر پہلا حکم پروٹوکول انتباہ کی بجائے چھوٹی DH کلید بتائے تو ورژن درست ہے اور صرف گروپ پر توجہ درکار ہے۔ جانچ میں کبھی نجی کلید یا پاس ورڈ نہ رکھیں۔

اختیار 1: کرپٹو پالیسی سے پورا ہوسٹ ڈھیلا کریں

Fedora اور RHEL 8 اور 9 پر، update-crypto-policies --set LEGACY OpenSSL کی نظامی پالیسی کم کرتا ہے، اور update-crypto-policies --show تصدیق کرتا ہے کہ کیا فعال ہے۔ یہ عام طور پر سرنگ بحال کرتا ہے، لیکن پالیسی عمل کے آغاز پر پڑھی جاتی ہے، اس لیے دوبارہ جانچ سے پہلے کلائنٹ اور اس کے بنائے ہوئے کسی بھی معاون عمل کو دوبارہ شروع کریں۔ یہ مشین پر ہر TLS کلائنٹ کے لیے پرانے پروٹوکول اور کمزور گروپ بھی اجازت دیتا ہے، ساتھ والی کھڑکی کے براؤزر سے لے کر کرنل اپ ڈیٹ کرنے والے پیکج مینیجر تک۔

یہی وسعت پورا مقصد اور پوری مشکل ہے۔ LEGACY پورے ہوسٹ پر لاگو ہوتا ہے، دیرپا ہے اور بھولنا آسان ہے، اس لیے اسے تشخیصی قدم یا زیرِ انتظام بلڈ پر دستاویزی استثنا ہونا چاہیے، کبھی بھی ورک سٹیشن کی آرام کی حالت نہیں۔ میں نے ایک دیکھا جو دو سال LEGACY پر رہا کیونکہ ایک داخلی پورٹل کو اس کی ضرورت تھی، اور کوئی نہیں بتا سکا کہ یہ کب شروع ہوا۔

Debian اور Ubuntu کے پاس اس کے لیے ایک ہی سوئچ نہیں۔ متبادل /etc/ssl/openssl.cnf میں ترمیم ہے جو نظام کے ڈیفالٹ حصے میں کم MinProtocol اور CipherString = DEFAULT@SECLEVEL=0 مقرر کرتی ہے۔ وہی دائرہ، مختلف فائل، ریلیز اپ گریڈ کے دوران نظر سے اوجھل ہونا قدرے آسان۔

اختیار 2: ایک کلائنٹ کے لیے ایک کنفگ فائل

فی عمل OpenSSL ترتیب تبدیلی کو ایک ہی عمل کے درخت میں رکھتی ہے، لیکن صرف اس صورت میں جب فائل اس طرح جڑی ہو جیسے لائبریری توقع کرتی ہے۔ ssl_conf حصے کا نام دینا کافی نہیں: OpenSSL اعلیٰ سطح کی openssl_conf کلید پڑھتا ہے، اسے ابتدائی حصے تک Follow کرتا ہے، اور تب ہی SSL ڈیفالٹ تک پہنچتا ہے۔

openssl_conf = openssl_init

[openssl_init]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
MinProtocol = TLSv1.0
CipherString = DEFAULT@SECLEVEL=0

OPENSSL_CONF کو اس فائل کی طرف اشارہ کریں اور VPN کلائنٹ کو ایسے ریپر کے ذریعے شروع کریں جو اسے ایکسپورٹ کرے۔ ہوسٹ پر باقی سب ڈیفالٹ پالیسی رکھتا ہے، اور تعمیل کا سوال آنے پر یہی خصوصیت اہم ہوتی ہے۔ گیٹ وے کو قصوروار ٹھہرانے سے پہلے یقینی بنائیں کہ فائل واقعی نافذ ہے: OPENSSL_CONF=/path/to/file openssl ciphers -s -tls1 کو TLS 1.0 سائفرز کی فہرست دینی چاہیے، اور خالی نتیجہ کا مطلب ہے کہ زنجیر ٹوٹ گئی ہے اور کلائنٹ نے خاموشی سے نظام کے ڈیفالٹ رکھے ہیں۔

فائل ورژن کے لیے حساس ہے۔ OpenSSL 1.1.1 اور 3.x وہی حصہ نام قبول کرتے ہیں، لیکن فراہم کنندگان کے گرد ہدایات کی کارروائی 3.x میں بدل گئی، اس لیے فائل پڑھی گئی ماننے کی بجائے کلائنٹ کے اپنے لاگ اور آزمائشی ہینڈ شیک سے تصدیق کریں۔ حصہ نام میں ٹائپو کھلے طور پر ناکام ہوتا ہے، اور کلائنٹ خاموشی سے نظام کے ڈیفالٹ استعمال کرتا ہے۔

حد کوریج ہے۔ GnuTLS یا NSS سے منسلک ہر چیز OPENSSL_CONF کو نظر انداز کرتی ہے، اور کلائنٹ کی جانب سے ماحول وراثت میں لیے بغیر شروع کیا گیا کوئی بھی معاون عمل بھی۔ ریپر بنانے سے پہلے ldd سے جانچیں کہ بائنری واقعی کس TLS لائبریری سے منسلک ہے، کیونکہ جواب ہی طے کرتا ہے کہ یہ اختیار ہے بھی یا نہیں۔

اختیار 3: ایک بار استعمال ہونے والا VM یا کنٹینر

ایسے ٹھیکیدار کے لیے جو دو ہفتے ایک پرانے گیٹ وے پر حملہ کرتا ہے، ڈھیلی پالیسی والا مخصوص VM ورک سٹیشن سے صاف سرحد ہے۔ پرانی سطح اور روزمرہ براؤزر پروفائل اب کرنل پالیسی شریک نہیں کرتے، اور نمٹانا آڈٹ کی دریافت نہیں، مٹانا ہے۔

یہ اب بھی نیٹ ورک والی مشین ہے، اس لیے اس کی رسائی محدود کریں اور عام براؤزنگ سے دور رکھیں۔ دیکھ بھال کی لاگت ایک اور امیج ہے جسے پیچ کرنا ہے، جو حقیقی مگر محدود اور نظر آنے والی ہے، لیپ ٹاپ پر بھولے ہوئے LEGACY پرچم کے برعکس۔

موازنہ آپ کو کیا چھوڑتا ہے

تین سوالوں پر انتخاب کریں: پرانا پروٹوکول کسے چاہیے، کتنے عرصے، اور اگر استثنا اپنی وجہ سے زیادہ جیے تو کون نوٹس لے گا۔ ایک ایپ، ایک شخص، چند دن فی عمل ترتیب کی طرف اشارہ کرتے ہیں۔ ایک ڈیوائس کے پیچھے پورا بیڑا خود گیٹ وے کی طرف اشارہ کرتا ہے۔ ہوسٹ پر مستقل LEGACY پالیسی چاہنے والی کوئی بھی چیز تکنیکی لباس میں خریداری کا فیصلہ ہے۔

پائیدار اصلاح ڈیوائس کی ہے: TLS 1.2 یا اس سے نیا، کم از کم 2048 بٹ گروپ، AEAD سائفر، اور جدید دستخط والا سرٹیفکیٹ۔ وہ تبدیلی ڈیوائس کے مالک سے طلب کریں، پھر کلائنٹ لاگ میں طے شدہ ورژن اور سائفر کی تصدیق کریں۔ استثنا کو ہوسٹ، گیٹ وے، طے شدہ پروٹوکول، منظوری دینے والے اور میعاد ختم ہونے کی تاریخ کے ساتھ لکھیں، کیونکہ یہی نوٹ عارضی حل کو ڈیفالٹ بننے سے روکتا ہے۔