چرا AES-256 یک مجموعه رمزنگاری VPN را توصیف نمی‌کند
یک مجموعه چهار نقش را پر می‌کند: رمزنگاری انبوه، یکپارچگی، برقراری کلید و احراز هویت طرف مقابل. نام یک رمز فقط یکی از آن‌ها را در یک لایه پوشش می‌دهد.
بپرسید یک VPN از چه رمزنگاری استفاده می‌کند و پاسخ معمولاً با یک واژه می‌آید: AES-256، یا ChaCha20، یا شاید WireGuard. آن پاسخ نام یک جزء از یک لایه را می‌برد، در حالی که چیزی که واقعاً اتصال را محافظت می‌کند مجموعه‌ای از الگوریتم‌هاست که چهار نقش متفاوت را پر می‌کنند. اشتباه گرفتن جزء با چیدمان رایج‌ترین خطا در این گفتگوهاست و مقایسه‌هایی می‌سازد که قابل حل نیستند.
چهار کار درون یک اتصال
رمزنگاری انبوه متن روشن را برای کانال داده به متن رمزشده تبدیل می‌کند و کلید آن مشتق می‌شود نه منتقل. محافظت یکپارچگی تغییر را تشخیص می‌دهد، که کاری جداست حتی وقتی یک ساختار هر دو را انجام می‌دهد. برقراری کلید ماده مشترک ترافیک را تولید می‌کند و احراز هویت طرف مقابل تعیین می‌کند چه کسی در آن سر است. اگر یکی از آن‌ها نباشد، اتصال امن نیست، هرقدر هم قطعه باقی‌مانده قوی باشد.
برخی طرح‌ها دو نقش را در یکی ادغام می‌کنند. AES-GCM و ChaCha20-Poly1305 ساختارهای رمزنگاری احرازشده هستند، پس محرمانگی و یکپارچگی با هم می‌آیند؛ AES-CBC چنین نیست و به کد احراز هویت پیام جداگانه با کلید خودش نیاز دارد. بنابراین خواندن یک پیشنهاد به‌عنوان کیسه‌ای از اعداد مستقل، آن‌هایی را که به‌صورت جفت طراحی شده‌اند بد می‌خواند.
نقش‌ها در لایه‌های متفاوت هم قرار دارند، و به همین دلیل یک واژه در دو محصول می‌تواند معنای متفاوتی داشته باشد. یک رمز بلوکی در ESP و یک رمز بلوکی در TLS همان ابتدایی در مذاکره‌های متفاوت با الزامات متفاوت هستند. بنابراین نقل یک ابتدایی بدون حالت و لایه‌اش می‌تواند بدتر از نقل نکردن هیچ چیز باشد.
چرا نام یک رمز تقریباً هیچ نمی‌گوید
عبارت AES-256 را لحظه‌ای جدی بگیرید: یک رمز بلوکی و یک اندازه کلید را مشخص می‌کند. درباره حالت کار، اینکه یکپارچگی فراهم می‌شود یا نه، یا اینکه کلیدها چگونه برقرار و طرف مقابل چگونه احراز شد هیچ نمی‌گوید. دو محصول می‌توانند هر دو AES-256 را تبلیغ کنند و در هر چیز دیگری متفاوت باشند، از جمله یکی با حالت غیراحرازشده و دیگری با حالت AEAD و تبادل کلید مدرن.
TLS 1.3 این جداسازی را به استاندارد آورد، که اصلاحی سودمند برای هر کسی است که واژگان قدیمی‌تر را آموخته. مجموعه‌های رمز آن تنها AEAD و هش را نام می‌برند، در حالی که گروه‌های تبادل کلید و الگوریتم‌های امضا به‌عنوان پارامترهای جداگانه مذاکره می‌شوند. بنابراین نام مجموعه TLS 1.3 با نام مجموعه TLS 1.2 در شرایط برابر قابل مقایسه نیست، هرچند هر دو در همان فیلد یک فایل پیکربندی ظاهر می‌شوند. بازرسی که دو رشته را مستقیم مقایسه کند به نتیجه‌ای می‌رسد که پروتکل از آن پشتیبانی نمی‌کند. گروه مذاکره‌شده و پارامترهای امضا را هم بخوانید، وگرنه مقایسه ناقص است.
WireGuard راه مخالف را انتخاب می‌کند و مذاکره را تقریباً کاملاً حذف می‌کند: پروتکل مجموعه الگوریتم ثابتی را تعیین می‌کند، پس دو پیاده‌سازی یا با هم کار می‌کنند یا نه. این یک انتخاب طراحی مشروع است و همچنین یعنی پرسش اینکه WireGuard چه مجموعه‌ای را مذاکره می‌کند پاسخ قابل مقایسه‌ای ندارد. اگر آن را بازرسی می‌کنید، مشخصات را یک بار بخوانید و سپس مدیریت کلید پیرامون آن را بازرسی کنید نه مذاکره را.
لایه واژگان را تعیین می‌کند
استقرار IPsec دو بار مذاکره می‌کند: پیشنهاد IKE برای کانال کنترل و تبدیل ESP برای داده، و این دو می‌توانند به‌طور مشروع متفاوت باشند. خواندن اولی و فرض اینکه دومی را توصیف می‌کند منبع رایج سردرگمی در بازرسی است، چون فایل پیکربندی هر دو را ذکر می‌کند و جالب دومی است.
| Layer | What is negotiated there | What it does not cover |
|---|---|---|
| IKE proposal | Algorithms and groups for the control channel that builds the tunnel | The algorithms protecting the data itself |
| ESP transform | Encryption and integrity for tunneled packets | Peer identity, which authentication already settled |
| TLS handshake | AEAD and hash, plus separately negotiated groups and signatures | Routing, authorization or retention policy |
| WireGuard | Nothing; the algorithm set is fixed by the protocol | Everything above the cryptographic arrangement |
نامی که در یک کتابخانه موجود است به‌طور خودکار برای مسیر داده دیگری پیاده‌سازی نمی‌شود. بنابراین این ادعا که محصول ما از AES-256 پشتیبانی می‌کند ضعیف‌تر از آن است که به نظر می‌رسد، و به همین دلیل مشکل هم‌کنش‌پذیری معمولاً با یافتن اشتراک نگه‌داری‌شده حل می‌شود نه با فعال کردن هر الگوریتم قدیمی در دو طرف.
مشخصات TLS 1.3 روشن‌ترین نمونه منتشرشده این جداسازی است، چون مجموعه را به‌صورت جفت تعریف می‌کند و بقیه را به مذاکره خودشان می‌برد. وقتی این شکل آشنا شد، پیشنهاد IPsec و تنها مجموعه ثابت WireGuard به‌عنوان گونه‌هایی از همان ایده خوانده می‌شوند.
نتیجه مذاکره‌شده را بخوانید و سپس متوقف شوید
پیشنهاد پیکربندی‌شده مدرکی بر آنچه دو طرف انتخاب کرده‌اند نیست. نشست زنده پاسخ را دارد و هر پیاده‌سازی رایج می‌تواند آن را بدون ضبط بسته گزارش کند.
openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg showدر خروجی الگوریتم‌های انتخاب‌شده را بخوانید نه فهرست پیشنهادی را. اگر پاسخ ضعیف‌تر از آن باشد که سیاست در نظر داشت، اصلاح در پیکربندی پیشنهاد یک طرف است، و ناسازگاری در پیاده‌سازی‌های مدرن معمولاً به‌صورت مذاکره ناموفق دیده می‌شود نه کاهش بی‌صدا.
سپس به یاد داشته باشید مجموعه چه چیزی را پوشش نمی‌دهد. مسیرها، مجوزهای برنامه، ثبت رویداد و نگهداری تصمیم‌های جداگانه با بازبینی خودشان هستند و چیدمان رمزنگاری سازگار درباره آن‌ها چیزی نمی‌گوید. بحث درباره رمز ارزشش را دارد، اما به پرسشی محدودتر از آنچه بیشتر مردم واقعاً می‌پرسند پاسخ می‌دهد.
واژگان را دقیق نگه دارید و استدلال کوتاه‌تر می‌شود. مجموعه مجموعه‌ای از نقش‌ها در یک لایه است، رمز یک جزء است، و نتیجه مذاکره‌شده تنها چیزی است که اتصالی را که واقعاً دارید توصیف می‌کند. هر چیز دیگری در مقایسه تزیین است.