OpenVPN EC د ED پر وړاندې: ولې دا نومونه د ځواک زینه نه ده
EC، ED، ECDHE او auth بېلو پوښتنو ته ځواب وایي. د هر څه د پرتله کولو یا سمولو دمخه OpenVPN پروفایل د هر نوم د کار له مخې ترتیب کړئ.
په یوه پروفایل کې ec، ed، ecdh، ecdsa، auth او د TLS د کوډونو یوه لیست یو تر بغل کېږدئ، نو فایل د شپږو حالتونو لرونکي د ځواک د ډيال په څېر ښکاره کېږي۔ خو داسې نه ده۔ هر نوم بېلې پوښتنې ته ځواب وایي، او هغه دوه پروفایلونه چې په یوه کې توپیر لري، اړینه نه ده چې یو د بل څخه پیاوړی یا کمزوری وي۔ نومونه د هغوی د کار له مخې ترتیبول نږدې پنځه دقیقې وخت نیسي او د هغو بدلونونو ډېره برخه مخه نیسي چې خلک په یوه کار کوونکي ترتیب کې کوي۔
لاندې ترتیب له هماغې مغشوشیت څخه پیل کېږي، بیا بهر ته د پروفایل هغو برخو ته ځي چې واقعاً ټاکي څه ستاسو ترافیک ساتي۔ هر برخه په خپل وار یوه ناسمه لوستنه اخلي او ښیي چې نوم واقعاً له کوم شي سره تړلی دی۔
دوه توري، دوه بېلې پوښتنې
هغه جوړه چې ډېره جنجال جوړوي EC او ED ده، او جنجال معمولاً فرض کوي چې دواړه د یوې پوښتنې سیال ځوابونه دي۔ دواړه په یوه محور کې هم نه دي۔ EC د ریاضیاتو یوه کورنۍ بیانوي: د بیضوي منحني کریپټوګرافي، چېرې چې امنیت په یوه لویه محدوده ساحه کې نه، بلکې په منحني کې د جلا لوګاریتم له سختۍ څخه راځي۔
ED د هماغې کورنۍ په داخل کې د منحني شکل بیانوي۔ Twisted Edwards منحني هغه استازیتوب دی چې د چټکتیا او د څو پلي کولو تېروتنو پر وړاندې د مقاومت لپاره غوره شوی، او 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 په کلکه د لاسلیک سکیم معنا لري، که څه هم نوم د تبادلې لپاره هم په اسانه کارول کېږي ځکه دواړه منحني تړاو لري: هغه Edwards بڼه چې د لاسلیک لپاره کارول کېږي او هغه Montgomery بڼه چې 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 نسخه او هغه سیټ چې پرې ودرېد شامل دي۔ که د پروفایل بدلون د دې دوو پایلو له یوې سره هم توجیه نه شي، نو دا احتمالاً د نوم بدلون دی، نه د ځانګړنې۔