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 کپی شده و هرگز حذف نشده. پروفایلی که برای تبادل یک خم نام می‌برد و هنوز یک فایل dh با 2048 بیت بار می‌کند، به خاطر این کار امن‌تر نیست؛ دارد یک مصنوع بی‌استفاده را حمل می‌کند.
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 تونل را سخت‌تر می‌کند. این کار قدرت رمزنگاری را بالا نمی‌برد، و اگر رمزنگاری داده مذاکره‌شده یک حالت AEAD مانند AES-256-GCM باشد، خلاصه به‌کلی روی بسته‌های داده اعمال نمی‌شود. برچسب 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 و مجموعه‌ای که روی آن ماند. اگر ویرایش یک پروفایل با یکی از این دو خروجی توجیه‌پذیر نباشد، احتمالاً تغییری در یک نام است و نه در یک ویژگی.