OpenVPN tls-crypt-v2: کلائنٹ کی چابی اور لپٹا ہوا blob کیا کرتے ہیں
tls-crypt-v2 پروفائل میں کلائنٹ کی کنٹرول چابی اور سرور ہی کھول سکنے والی لپٹی ہوئی نقل ہوتی ہے۔ ہر شے اور مواخذے کا ہر مرحلہ الگ رکھیں۔
tls-crypt-v2 پروفائل کو ٹکٹ میں چپکانا تب تک بے ضرر لگتا ہے جب تک آپ یہ شمار نہ کریں کہ فائل میں کیا ہے۔ کلائنٹ کی کنٹرول چینل چابی اسی چابی کی خفیہ کردہ نقل کے ساتھ بیٹھی ہے، اور تیسری شے، لپیٹنے والی چابی، کبھی قبول کرنے والے سرور سے باہر نہیں جاتی۔ یہ تینوں حراست، اشتراک اور مواخذے کے بارے میں مختلف سوالات کا جواب دیتے ہیں۔ انہیں الگ رکھنا زیادہ تر پالیسی بحثوں کو شروع ہونے سے پہلے ہی طے کر دیتا ہے۔
پروفائل میں درحقیقت کیا ہے
tls-crypt-v2 کا کلائنٹ آدھا حصہ ایک چابی اور اس کی لپٹی ہوئی نقل ہے۔ کلائنٹ کنٹرول چینل کے تحفظ کے لیے سادہ چابی استعمال کرتا ہے اور سیٹ اپ کے دوران لپٹی ہوئی نقل سرور کو دیتا ہے، تاکہ سرور ہر کلائنٹ کے لیے سادہ نقل محفوظ کیے بغیر وہی چابی دوبارہ حاصل کر لے۔ لپیٹنے والی چابی اس بازیابی کو ممکن بناتی ہے اور صرف قبول کرنے والے پہلو کی ہوتی ہے۔ نیچے سب کچھ اسی سے نکلتا ہے کہ وہ تینوں اشیاء کہاں رہتی ہیں۔
| Object | Where it lives | What can open it | What a leak costs |
|---|---|---|---|
| Server wrapping key | accepting servers only | the unwrap step inside the server | every wrapped copy issued to that group becomes readable |
| Wrapped client key | inside the client profile | the server wrapping key | it names a client and exposes its metadata, but not the key inside |
| Client control key | inside the client profile, usable as-is | the client that owns it | someone can open handshakes as that client until the server refuses the key |
جدول کو نام سے نہیں، حراست سے پڑھیں اور نتائج خود بخود واضح ہو جاتے ہیں۔ لپیٹنے والی چابی کھونا مہنگا واقعہ ہے، کیونکہ پروفائل میں کچھ بھی اسے دوبارہ نہیں بنا سکتا اور ایماندار بازیابی گروپ کو دوبارہ جاری کرنا ہے۔ لیک ہوا پروفائل سستا ہے مگر کہیں زیادہ عام ہے، کیونکہ لوگ ٹکٹوں میں پروفائل چپکاتے ہیں یہ مان کر کہ لپٹی ہوئی نقل فائل کو اشتراک کے لیے محفوظ بنا دیتی ہے۔ دونوں ناکامیوں کو الگ جواب چاہیے، اسی لیے اشیاء الگ رکھی جاتی ہیں۔
لپٹی ہوئی نقل پوری کہانی کیوں نہیں ہے
پروفائل قابل استعمال کلائنٹ مواد کو اپنی لپٹی ہوئی ہمزاد کے ساتھ لے کر چلتا ہے، اس لیے سرور کے لیے نقل کا تحفظ فائل کے تحفظ کے بارے میں کچھ نہیں کہتا۔ Blob بھیجنے کے لیے محفوظ ہے اور شائع کرنے کے لیے غیر محفوظ۔ اس کے اندر کا میٹا ڈیٹا blob وصول کرنے والے ہر شخص کو نظر آتا ہے، اس شخص کو بھی جو بعد میں وہ ٹکٹ پڑھے گا جس میں یہ چپکایا گیا تھا۔
پروفائل کو کنفیگریشن نمونہ نہیں، اسناد سمجھیں۔ لیک ہوئی فائل اپنے حامل کو کام کرتی کلائنٹ شناخت دیتی ہے جب تک سرور اس شناخت کو قبول کرنا بند نہ کرے، اور لپیٹنا اس دورانیے کے بارے میں کچھ نہیں کرتا۔ ہر کلائنٹ کے لیے ایک پروفائل جاری کریں تاکہ واپس لینا ایک فائل کا فیصلہ رہے، اور لپیٹنے والی چابی کا بیک اپ اس سرور کنفیگریشن سے الگ رکھیں جسے یہ ممکن بناتی ہے۔ دونوں عادتیں متاثرہ پروفائل کو ٹھیک نہیں کرتیں، لیکن دونوں طے کرتی ہیں کہ اگلا کتنی جلدی قابو میں آئے گا۔
ہینڈ شیک میں تصدیق کا ہک کہاں بیٹھتا ہے
تصدیق کا ہک TLS اسٹیک کھلنے سے پہلے چلتا ہے، اور اس کا کام لپٹے ہوئے blob میں لے جانے والے میٹا ڈیٹا کا معائنہ کرنا ہے۔ اسے وہ میٹا ڈیٹا اور ایک چھوٹا، دستاویزی ماحول ملتا ہے، اور تصدیق ہک کے مقابلے میں اس کے پاس کام کرنے کا کم مواد ہوتا ہے۔ یہ سمجھنا کہ وہ صارف نام، سیشن کی حالت یا پلگ ان متغیرات دیکھتا ہے، اس ہک کے بری طرح لکھے جانے کا عام طریقہ ہے۔ کسی دوسرے ہک سے توقعات ادھار لینے کی بجائے خود ہک کا دستی حصہ پڑھیں۔
اس کی اخراجی حالت فیصلہ ہے: غیر صفر نتیجہ کلائنٹ کو مسترد کرتا ہے اور صفر نتیجہ ہینڈ شیک کو جاری رکھنے دیتا ہے۔ اس لیے پالیسی کو بتانا ہوگا کہ میٹا ڈیٹا غائب، ناقابل تجزیہ یا غیر متوقع ہونے پر کیا ہوتا ہے۔ پہلے مسترد ہونے کا راستہ لکھیں، پھر طے کریں کہ کون سی اقدار قابل قبول ہیں۔
tls-crypt-v2 /etc/openvpn/server/tcv2-server.key
tls-crypt-v2-verify /etc/openvpn/server/verify-client-metadata.shوہ دو سطریں سرور پر پالیسی کی سطح ہیں: ایک لپیٹنے والی چابی کا نام لیتی ہے، دوسری ہر کلائنٹ کا فیصلہ کرنے والے پروگرام کا۔ دلچسپ سب کچھ اسکرپٹ میں رہتا ہے، جو ورژن کنٹرول اور کسی بھی دوسرے رسائی قاعدے جیسی جانچ کا حقدار ہے۔
اکاؤنٹ، سرٹیفکیٹ اور کنٹرول چابی الگ الگ ریٹائر ہوتے ہیں
کنٹرول چینل کی جلدی قبولیت تصدیق نہیں ہے، کیونکہ یہ TLS شناخت کی جانچ سے پہلے اور کسی بھی اکاؤنٹ اجازت سے پہلے ہوتی ہے۔ اکاؤنٹ بند کرنا، سرٹیفکیٹ منسوخ کرنا اور کلائنٹ کنٹرول چابی مسترد کرنا تین میکانزم والے تین افعال ہیں۔ جو تعیناتی ان میں سے صرف ایک کرتی ہے اس میں پالیسی کی بجائے خلا ہے۔ تینوں کو جان بوجھ کر ہم آہنگ کریں، اور درج کریں کہ کون سا مرحلہ کون سا اختیار استعمال کرتا ہے۔
وقت دوسرا فرق ہے۔ بدلی ہوئی قبولیت کی فہرست نئے ہینڈ شیک پر لاگو ہوتی ہے، جبکہ پہلے سے قائم سیشن اس وقت تک چلتے رہتے ہیں جب تک کوئی انہیں ختم نہ کرے۔ نئی فہرست کے اندراجات کو پرانے سیشن ختم ہونے کا ثبوت سمجھ کر گننا ہی وہ طریقہ ہے جس سے ہٹایا گیا کلائنٹ گھنٹوں جڑا رہتا ہے۔
غیر ہم آہنگ اختیارات دو سوراخ چھوڑتے ہیں جو عملاً آسانی سے مل جاتے ہیں۔ اکاؤنٹ بند ہو سکتا ہے جبکہ اس کی کنٹرول چابی اب بھی ہینڈ شیک کھولتی ہے، اور سرٹیفکیٹ منسوخ ہو سکتا ہے جبکہ میٹا ڈیٹا پالیسی اسی کلائنٹ کو اب بھی قبول کرتی ہے۔ دونوں مختلف جگہوں کی ایک ہی غلطی ہیں، کیونکہ آپریٹر نے ایک فہرست کو پورا اختیار سمجھا۔ ہٹانے کے وقت تینوں فہرستیں ساتھ رکھیں اور غلطی نظر آنے لگتی ہے۔
پروفائل جاری کرنا اور واپس لینا
جاری کرنا آسان آدھا ہے: قبول کرنے والے پہلو پر کلائنٹ چابی بنائیں، پروفائل بالکل ایک مالک کو دیں، لپیٹنے کا مواد محدود رکھیں، اور ہر قبول کرنے والے سرور پر وہی تصدیقی پروگرام چلائیں۔ سستا داخلہ پورے گروپ کی خصوصیت ہے، نئے ترین ہوسٹ کی نہیں۔ پرانی یا ڈھیلی اسکرپٹ والا دوسرا سرور خاموشی سے تعیناتی کا کمزور ترین راستہ بن جاتا ہے۔
واپس لینے کے لیے تینوں مراحل جان بوجھ کر ترتیب میں چاہئیں۔ نئے ہینڈ شیک ناکام ہوں اس لیے تصدیق ہک میں کلائنٹ کو مسترد کریں، اگر PKI استعمال ہو رہی ہے تو اس کا سرٹیفکیٹ منسوخ کریں، اور اکاؤنٹ بند کریں تاکہ بعد کی اجازت کے پاس اجازت دینے کو کچھ نہ رہے۔ پھر پرانی قبولیت نے جن سیشن کی اجازت دی تھی انہیں ختم کریں، کیونکہ وہ تینوں میں سے کسی کو محسوس نہیں کریں گے۔ ترتیب کی مشق ایسے کلائنٹ پر کریں جسے آپ توڑ سکتے ہوں۔
پروفائل میں میٹا ڈیٹا اس پالیسی کے لیے ان پٹ ہے، اس بات کا ثبوت نہیں کہ رسائی کنٹرول پہلے سے موجود ہے۔ OpenVPN 2.6 کا ڈیزائن دستاویز اشیاء اور ان کی کھینچی ہوئی حد بیان کرتا ہے، جبکہ ان کا نفاذ آپریٹر کے پاس رہتا ہے۔