OpenVPN: EC اور ED — یہ نام طاقت کی سیڑھی کیوں نہیں ہیں
EC، ED، ECDHE اور auth مختلف سوالات کے جواب دیتے ہیں۔ کچھ بھی موازنہ کرنے یا تبدیل کرنے سے پہلے OpenVPN پروفائل کو ہر نام کے کام کے مطابق ترتیب دیں۔
ec، ed، ecdh، ecdsa، auth اور TLS سائفر کی ایک فہرست کو ایک ہی پروفائل میں ساتھ ساتھ رکھیں تو فائل چھ پوزیشنوں والا طاقت کا ڈائل لگنے لگتی ہے۔ ایسا نہیں ہے۔ ہر نام ایک الگ سوال کا جواب دیتا ہے، اور ایسی دو پروفائلیں جو ان میں سے صرف ایک میں مختلف ہوں، ضروری نہیں کہ ایک دوسرے سے زیادہ مضبوط یا کمزور ہوں۔ ناموں کو ان کے کام کے مطابق ترتیب دینے میں تقریباً پانچ منٹ لگتے ہیں اور یہ کسی کام کرنے والی کنفیگریشن میں لوگوں کی زیادہ تر خراب تبدیلیوں کو روک دیتا ہے۔
نیچے دی گئی ترتیب خود ابہام سے شروع ہوتی ہے، پھر پروفائل کے ان حصوں کی طرف باہر کی جانب بڑھتی ہے جو واقعی فیصلہ کرتے ہیں کہ آپ کی ٹریفک کو کیا محفوظ رکھتا ہے۔ ہر حصہ ایک ایک غلط فہمی لیتا ہے اور دکھاتا ہے کہ نام دراصل کس چیز سے جڑا ہوا ہے۔
دو حروف، دو الگ سوالات
سب سے زیادہ بحث کا سبب EC اور ED کا جوڑا ہے، اور بحث عموماً یہ فرض کرتی ہے کہ یہ ایک ہی سوال کے حریف جوابات ہیں۔ یہ ایک محور پر بھی نہیں ہیں۔ EC ریاضی کے ایک خاندان کو بیان کرتا ہے: بیضوی منحنی خفیہ نگاری، جس میں سلامتی کسی بڑے محدود میدان کی بجائے منحنی پر مجرد لاگرتھم کی دشواری سے آتی ہے۔
ED اسی خاندان کے اندر منحنی کی ایک شکل بیان کرتا ہے۔ بٹی ہوئی ایڈورڈز منحنیں رفتار اور کئی نفاذی غلطیوں کے خلاف مزاحمت کے لیے چنی گئی ایک نمائندگی ہیں، اور Ed25519 وہ نام ہے جو لوگ عموماً مراد لیتے ہیں۔ یہ منحنی بیضوی منحنی خفیہ نگاری کی حریف نہیں؛ یہ بیضوی منحنی لکھنے کا ایک طریقہ ہے۔ ED کو “نیا اور زیادہ مضبوط EC” پڑھنا پہلا غلط موڑ ہے، اور اس کے بعد سب کچھ عموماً اسی سمت میں غلط ہوتا ہے۔
دستخط کرنا اور کلید کا تبادلہ الگ الگ کام ہیں
خاندان کا سوال طے ہو جانے کے بعد، باقی نام دو کالموں میں بٹ جاتے ہیں جو کبھی ایک دوسرے کا متبادل نہیں بنتے۔ ایک کالم دستخط کرتا ہے، دوسرا مشترکہ راز پر اتفاق کرتا ہے۔
| Name in the profile | Job it does | What it is not |
|---|---|---|
ecdsa | Signature scheme using elliptic-curve keys | Not a key-exchange method |
eddsa, Ed25519 | Signature scheme for twisted Edwards curves | Not interchangeable with ECDSA |
ecdh, X25519 | Ephemeral key agreement | Not a signature and not a cipher |
auth | HMAC digest for packet authentication | Not the data cipher |
EdDSA اور ECDSA دونوں دستخط کرتے ہیں، لیکن یہ مختلف کلید فارمیٹوں والے مختلف اسکیمیں ہیں، اس لیے ایک کے لیے جاری کردہ سرٹیفکیٹ دوسرے کے طور پر استعمال نہیں ہو سکتا۔ EdDSA منحنیوں کے ایک چھوٹے مجموعے کے لیے متعین ہے؛ P-256 ان میں سے ایک نہیں، اسی لیے P-256 سرٹیفکیٹ ECDSA سے تصدیق ہوتا ہے اور کبھی Ed25519 سے نہیں۔
تبادلے کے کالم میں EdDH نام کا کوئی ہم منصب نہیں۔ Curve25519 کلید پر عارضی اتفاق X25519 ہے، اور یہ کسی مخصوص منحنی کے ساتھ ECDH ہے، بالکل ویسے ہی جیسے P-256 کے ساتھ۔ Ed25519 سختی سے دستخط کے اسکیم کو ظاہر کرتا ہے، تاہم یہ نام تبادلے کے لیے بھی ڈھیلے طور پر استعمال ہوتا ہے کیونکہ دونوں منحنیں آپس میں متعلق ہیں: دستخط کے لیے استعمال ہونے والی ایڈورڈز شکل اور X25519 کے لیے استعمال ہونے والی مونٹگمری شکل ایک ہی بنیادی گروہ کو بیان کرتی ہیں۔
EC پروفائل میں dh فائل کیوں نہیں ہوتی
dh فائل محدود میدان Diffie-Hellman کے لیے پہلے سے تیار کردہ پیرامیٹرز رکھتی ہے، اور یہ پیرامیٹرز اس لیے موجود ہیں کہ ایک بڑا مفرد عدد اور ایک مولّد کہیں سے آنا ضروری ہے۔ بیضوی منحنی تبادلے کو ان کی ضرورت نہیں: نامزد منحنی ہی پیرامیٹر سیٹ ہے، اور دونوں فریق اسے پہلے ہی جانتے ہیں۔ یہی وہ پوری وجہ ہے کہ EC پروفائل اس ہدایت کو چھوڑ سکتا ہے۔
دو صورتیں ایسی ہیں جو بظاہر جدید پروفائل میں بھی dh کی سطر پیدا کرتی ہیں۔ پہلی یہ کہ دوسرا سننے والا یا کوئی پرانا ساتھی واقعی محدود میدان کے گروہوں پر بات چیت کرتا ہو۔ دوسری یہ کہ RSA دور کے ٹیمپلیٹ سے نقل شدہ اور کبھی نہ ہٹایا گیا بچا ہوا متن ہو۔ ایسی پروفائل جو تبادلے کے لیے منحنی کا نام دیتی ہے اور پھر بھی 2048 بٹ کی dh فائل لوڈ کرتی ہے، ایسا کرنے سے زیادہ محفوظ نہیں ہوتی؛ وہ ایک غیر استعمال شدہ چیز اٹھائے پھر رہی ہے۔
TLS 1.3 نے کلید کا تبادلہ نام سے ہٹا دیا
TLS_AES_256_GCM_SHA384 کا TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 سے موازنہ کریں تو چھوٹا نام کمی لگتا ہے۔ یہ محض نام کی تبدیلی ہے، اور وجہ ساختی ہے: TLS 1.3 نے جامد RSA اور محدود میدان Diffie-Hellman کلید کا تبادلہ ہٹا دیا، اس لیے عارضی بیضوی منحنی تبادلہ PSK کے علاوہ واحد باقی ماندہ آپشن ہے۔ ہر سوٹ میں اس کا نام لینا ایک ہی حقیقت کو درجنوں بار دہرانا ہوگا۔
سرٹیفکیٹ کی قسم نام سے متعلقہ وجہ کی بنا پر غائب ہو گئی۔ 1.3 میں سرٹیفکیٹ کلید کے اتفاق کی نہیں بلکہ ہینڈ شیک کے دستخط کی تصدیق کرتا ہے، اس لیے اب یہ سوٹ کا انتخاب نہیں کرتا۔ یہی وجہ ہے کہ کنفیگریشن میں 1.3 کے لیے ایک الگ سائفر فہرست موجود ہے: سوٹس کے نام بدلے گئے اور انہیں دوبارہ ترتیب دیا گیا، کمزور نہیں کیا گیا۔
ایک نتیجہ کھلم کھلا بیان کرنا چاہیے۔ ECDHE کلید کے تبادلے کا الگورتھم ہے اور کبھی سائفر نہیں۔ “بیضوی” کہلانے والا سوٹ اس بات کا بتاتا ہے کہ دونوں فریق کسی مشترکہ کلید تک کیسے پہنچے، اور اس بات کا بالکل نہیں کہ اس کے بعد پے لوڈ کو کیا خفیہ کرتا ہے۔
auth پیکیٹوں کی تصدیق کرتا ہے، پے لوڈ کی نہیں
auth ہدایت وہ HMAC ڈائجسٹ چنتی ہے جو پیکیٹوں کی تصدیق کرتا ہے، اور اس کی تاریخی طے شدہ قدر SHA1 ہے۔ غیر AEAD ڈیٹا سائفر کے ساتھ OpenVPN سائفرٹیکسٹ پر ڈائجسٹ شمار کر کے اسے آخر میں جوڑ دیتا ہے؛ یہی پہلے خفیہ کریں پھر MAC کا انتظام ہے جو پیڈنگ کے ساتھ چھیڑ چھاڑ کو عملاً ناقابل عمل بناتا ہے۔
یہاں یہ افسانہ ہے کہ auth کو SHA512 تک بڑھانے سے سرنگ مضبوط ہو جاتی ہے۔ اس سے خفیہ کاری کی طاقت نہیں بڑھتی، اور اگر طے شدہ ڈیٹا سائفر AES-256-GCM جیسا AEAD موڈ ہو تو ڈائجسٹ ڈیٹا پیکیٹوں پر بالکل لاگو نہیں ہوتا۔ GCM ٹیگ پہلے ہی ان کی تصدیق کرتا ہے، اور auth کی قدر کنٹرول چینل کے HMAC اور کسی بھی ایسے غیر AEAD سائفر کے لیے چھوڑ دی جاتی ہے جو اب بھی زیر استعمال ہو۔
تو یہ ہدایت اہم ہے، لیکن یہ فائل میں اپنی جگہ کے اشارے سے کہیں زیادہ تنگ جگہ پر اہم ہے۔ یہ جانچنا کہ اصل میں کون سا سائفر طے ہوا، آپ کو بتاتا ہے کہ یہ لاگو ہوتا ہے یا نہیں۔
پروفائل کو درجہ کے بجائے کالم کے مطابق پڑھیں
تین سوالات ان تہوں کو صاف طور پر الگ کرتے ہیں، اور ہر ایک کا جواب طے شدہ سیشن کا ایک مختلف حصہ دیتا ہے۔ کون سا سائفر پے لوڈ کی حفاظت کرتا ہے؟ ہر پیکیٹ کی ضمانت کون سا ٹیگ یا ڈائجسٹ دیتا ہے، اور کیا زیر استعمال سائفر کو اس کی ضرورت بھی ہے؟ کس کا سرٹیفکیٹ ہینڈ شیک بند کرتا ہے، اور کیا کنٹرول چینل اضافی طور پر tls-auth یا tls-crypt سے محفوظ ہے؟
EC یا ED کے لیبل میں کچھ بھی ان تینوں میں سے کسی کا فیصلہ نہیں کرتا، اور صرف سوٹ کا نام بھی کسی کا فیصلہ نہیں کرتا۔ طے شدہ نتیجہ ہی واحد ثبوت ہے، اس لیے الفاظ سے طاقت کا اندازہ لگانے کے بجائے اسے پڑھیں:
openssl x509 -in client.crt -noout -text | grep -E 'Signature Algorithm|Public Key Algorithm'
grep -i 'control channel' /var/log/openvpn.logپہلی کمانڈ آپ کو بتاتی ہے کہ آپ کا سرٹیفکیٹ دراصل کون سا دستخطی اسکیم استعمال کرتا ہے، اور یہ جاننے کا یہی واحد قابلِ اعتماد طریقہ ہے کہ آپ ECDSA چلا رہے ہیں یا Ed25519۔ دوسری وہ کنٹرول چینل کی سطر دکھاتی ہے جو کلائنٹ نے سیشن کے لیے لاگ میں درج کی، بشمول TLS ورژن اور وہ سوٹ جس پر اتفاق ہوا۔ اگر کسی پروفائل کی تبدیلی ان دو نتائج میں سے کسی ایک سے جائز نہ ٹھہرے، تو یہ غالباً کسی خصوصیت کے بجائے کسی نام کی تبدیلی ہے۔