openssl rand وہ چابی کیوں نہیں بنا سکتا جو tls-crypt چاہتا ہے

OpenSSL پہلے ہی نصب ہے، میزبان کے پاس اینٹروپی ہے، اور اس سے چابی بنانا واضح شارٹ کٹ لگتا ہے۔ آؤٹ پٹ بے ترتیب اور خفیہ اور بالکل ناقابلِ استعمال ہوگا، اور ناکامی چابی کی ساخت کا ذکر کرنے والی کسی چیز کے بجائے کنٹرول چینل کی خرابی کے طور پر آئے گی۔ یہی گمراہی مہنگا حصہ ہے، کیونکہ یہ لوگوں کو ان کے سائفرز جانچنے بھیجتی ہے۔ VPN جو پڑھتا ہے وہ ایک مخصوص فائل ساخت ہے، کوئی من مانی بائٹ بلاک نہیں، اور اس خصوصیت کی ایک قسم سرور سے باہر بالکل نہیں بنائی جا سکتی۔

ڈسک پر موجود فائل دراصل کیا ہونی چاہیے

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

یہی آبجیکٹ قسم کنٹرول چینل کی دونوں خصوصیات کی خدمت کرتی ہے۔ tls-auth کے ساتھ، ہر پیر کو سمت بھی درکار ہے تاکہ ایک فریق کے پیکٹ اس کی طرف واپس منعکس نہ ہو سکیں۔ tls-crypt کے ساتھ، ایک ہی مشترکہ راز دونوں سمتوں میں کنٹرول چینل کو انکرپٹ اور تصدیق کرتا ہے، جو ہینڈ شیک کو چھپاتا بھی ہے اور ساتھ ہی تحفظ دیتا ہے۔

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

ایک بنانے کا معاون طریقہ

سادہ اسٹیٹک چابی اس آلے سے بنائیں جو اسے استعمال کرے گا، پھر دونوں سروں سے اس کا حوالہ دیں:

openvpn --genkey secret /etc/openvpn/tc-shared.key
tls-crypt /etc/openvpn/tc-shared.key

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

دوسری نسل ایسی ساخت شامل کرتی ہے جو کوئی بیرونی جنریٹر ایجاد نہیں کر سکتا۔ سرور چابی ایک بار بنائی جاتی ہے، اور ہر کلائنٹ اس سے ماخوذ لپیٹی ہوئی چابی وصول کرتا ہے:

openvpn --genkey tls-crypt-v2-server /etc/openvpn/tc-v2-server.key
openvpn --genkey tls-crypt-v2-client /etc/openvpn/laptop1.key --tls-crypt-v2 /etc/openvpn/tc-v2-server.key

کلائنٹ جو وصول کرتا ہے وہ سرور کی اپنی چابی کی نقل نہیں ہے۔ یہ ایک لپیٹی ہوئی آبجیکٹ ہے جو ایسا میٹا ڈیٹا رکھتی ہے جسے صرف سرور کھول سکتا ہے، اور اسی لپیٹ کی وجہ سے ایک ڈیوائس کی فائل کسی دوسرے ڈیوائس کو چھوئے بغیر منسوخ کی جا سکتی ہے۔ سرور چابی سرور پر ہی رکھیں اور اسے اس ڈیوائس کی بنیاد پر اعتماد کی جڑ سمجھیں۔

ہاتھ سے بنائے گئے بائٹس کہاں ٹوٹتے ہیں

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

v2 قسم کے ساتھ ایسا مساوی کچھ ممکن نہیں ہے۔ لپیٹی ہوئی کلائنٹ چابی صرف سرور چابی کے عمل کے آؤٹ پٹ کے طور پر موجود ہے، اور سرور اسے کھولنے کے لیے درکار مواد رکھتا ہے۔ بے ترتیب بلاک مسترد ہو جائے گا یا سیدھا ڈکرپٹ نہیں ہو سکے گا، اور دونوں پیغامات میں سے کوئی بھی بے ترتیبی کا ذکر نہیں کرے گا۔

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

سب کو باہر مقفل کیے بغیر گھمانا

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

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

فائل کی اجازتیں اسی گفتگو کا حصہ ہیں۔ چابی صرف اس اکاؤنٹ کے لیے پڑھنے کے قابل ہونی چاہیے جو سروس چلاتا ہے، اور اسے ان پروفائلز کے ساتھ اسی ذخیرے میں نہیں رہنا چاہیے جنہیں یہ محفوظ رکھتی ہے۔ OpenVPN 2.6 حوالہ بنانے کی شکلوں اور چابی کے مواد کے حصوں کی دستاویز کرتا ہے، جو فورم پوسٹ سے نقل کی گئی کمانڈ سے بہتر ماخذ ہے۔