tls-auth در برابر tls-crypt: هر کدام در OpenVPN از چه چیزی محافظت می‌کند
tls-auth بسته‌های کنترل را امضا می‌کند و tls-crypt آن‌ها را نیز پنهان می‌کند. هیچ‌کدام جایگزین بررسی گواهی یا رمزنگاری داده نیست، و ناسازگاری شبیه سکوت است.
هر دو گزینه از یک فایل کلید مشترک استفاده می‌کنند و هر دو جعل ترافیک دست‌دهی را سخت‌تر می‌کنند، به همین دلیل آن‌ها را دو نام برای یک ویژگی می‌پندارند. این‌گونه نیست. یکی بسته‌های کنترل را امضا می‌کند، دیگری آن‌ها را رمزنگاری هم می‌کند، و هیچ‌یک ربطی به رمزی که داده‌های شما را محافظت می‌کند ندارد.
این تفاوت زمانی مهم می‌شود که یک پروفایل نمی‌تواند متصل شود، زمانی که بازبینی امنیتی می‌پرسد کلید از چه چیزی محافظت می‌کند، و زمانی که کسی گمان می‌کند فایل اضافی تونل را به شکلی نامشخص رمزنگاری‌شده می‌کند.
کلید مشترک در واقع از چه چیزی محافظت می‌کند
کلیدی که این گزینه‌ها به کار می‌برند به کانال کنترل تعلق دارد: همان تبادلی که پارامترها را مذاکره می‌کند، هویت‌ها را اثبات می‌کند و کلیدهای داده را استخراج می‌کند. این یک راز از پیش به اشتراک گذاشته‌شده است که هر دو سر باید پیش از ادامه دست‌دهی آن را داشته باشند. چون پیش از بررسی هویت قرار دارد، کلید نادرست گفت‌وگو را زودتر از رمز عبور نادرست متوقف می‌کند. همین ترتیب توضیح می‌دهد که چرا حالت خرابی این‌قدر بی‌صدا است.
tls-auth از این راز برای محاسبه یک HMAC روی بسته‌های کنترل استفاده می‌کند. بسته‌ای که امضای معتبر ندارد پیش از رسیدن به پردازش گران‌تر TLS دور انداخته می‌شود، و به همین دلیل این گزینه را غالباً فیلتر اول می‌نامند، نه جایگزین TLS.
tls-crypt جلوتر می‌رود و ترافیک کنترل محافظت‌شده را علاوه بر احراز هویت، رمزنگاری هم می‌کند. محتوای گواهی‌ها، نام رمزهای مذاکره‌شده و دیگر جزئیات دست‌دهی دیگر روی شبکه دیده نمی‌شوند، و ناظری که کلید را ندارد حتی نمی‌تواند ببیند کدام نسخه TLS آزموده می‌شود. برای استقراری که از آشکار شدن اثر انگشت VPN خود می‌ترسد، همین ویژگی دلیل اصلی انتخاب آن است. با این حال یک راز گروهی است، نه یک اعتبارنامه برای هر کاربر.
هیچ‌یک از این دو سازوکار هویت صادر نمی‌کند. کلید مشترک یک راز گروهی است و هرکس آن را داشته باشد می‌تواند آن لایه از بررسی را برآورده کند.
دو گزینه کجا تفاوت دارند
تفاوت قابل مشاهده همان چیزی است که ناظر می‌بیند. با tls-auth دست‌دهی دیده می‌شود اما بدون کلید قابل بررسی نیست. با tls-crypt دست‌دهی برای هرکس کلید را ندارد مبهم است.
پیکربندی هم متفاوت است. tls-auth با یک مقدار جهت به کار می‌رود، پس یک طرف نیمی از مواد کلید را استفاده می‌کند و طرف دیگر نیم دیگر را. tls-crypt در هر دو جهت یک کلید واحد به کار می‌برد، بنابراین دستور جهت بخشی از چیدمان آن نیست.
در نسخه‌های امروزی این دو گزینه یکدیگر را نفی می‌کنند. پروفایل باید یکی از آن‌ها را داشته باشد، نه هر دو را، و سرور و کارخواه باید بر سر اینکه کدام باشد توافق کنند، با مواد کلید یکسان. نگه داشتن یک دستور قدیمی در کنار دستور جدید از بازمانده‌های رایج مهاجرت است. دستور غیرفعال را بردارید تا خواننده بعدی بداند کدام لایه واقعاً برقرار است.
گونه‌ای تازه‌تر، tls-crypt-v2، هر کارخواه را به کلید پیچیده‌شده خودش گره می‌زند تا لغو یک کارخواه نیازمند صدور دوباره کلید گروه نباشد. دانستن آن ارزشمند است، اما گزینه‌ای متفاوت است و مترادف هیچ‌یک از این دو نیست.
چرا ناسازگاری طوری است که گویی هیچ چیز رخ نمی‌دهد
وقتی مواد مشترک همخوانی ندارد، طرف مقابل بسته‌ها را دور می‌ریزد بی‌آنکه به فرستنده بگوید چرا. هیچ خطای احراز هویتی برای خواندن نیست، چون بسته هرگز به لایه‌ای که آن را تولید می‌کرد نرسید.
کارخواه دوباره تلاش می‌کند، سرور چیزی نمی‌گوید و نشانه شبیه مشکل شبکه به نظر می‌رسد. سپس افراد سرویس را دوباره راه‌اندازی می‌کنند، رمز حساب را دوباره وارد می‌کنند یا دستور محافظت را برای «آزمایش» برمی‌دارند، که استقرار را تغییر می‌دهد نه اینکه آن را تشخیص دهد.
در گزارش سرور اولین شکایت در سطح بسته را بخوانید، نه آخرین خط تلاش دوباره. تأیید کنید که دو طرف همان گزینه را با مواد کلید یکسان دارند و فایل کلید فقط در یک طرف بازتولید نشده است.
برداشتن دستور یک تعمیر امن نیست. یک لایه محافظت را برای همه کارخواهان غیرفعال می‌کند، و تونلی که بعد از آن کار کند فقط ثابت می‌کند که همان لایه ناسازگاری بود.
هنوز چه چیزی باید جداگانه پیکربندی شود
این گزینه‌ها بررسی نمی‌کنند که طرف مقابل کیست. اعتبارسنجی گواهی، لنگر اعتماد و نام سرور مورد انتظار همچنان الزامات جداگانه‌اند، و هیچ‌یک به دلیل وجود کلید مشترک اختیاری نمی‌شود.
آن‌ها رمز داده را هم انتخاب نمی‌کنند. این مذاکره‌ای جداگانه است که تنظیمات کانال داده در دو طرف آن را کنترل می‌کند، و تونلی که با tls-crypt محافظت می‌شود باز هم می‌تواند رمزی را به کار ببرد که قصدش را نداشتید.
در پایان، خود کلید مشترک نیاز به رسیدگی دارد. آن را راز بدانید، از کانالی تأییدشده توزیع کنید و وقتی هرکس آن را داشت رفت، جایگزینش کنید. چون مشترک است، افشای آن افشای هر نقطه پایانی است که از آن استفاده می‌کند.