ردیابی بسته‌های کنترل OpenVPN: tls-auth پیش از TLS

خطای tls-auth معمولاً به‌عنوان مشکل دست‌دادن گزارش می‌شود، در حالی که هرگز چنین نبوده است. HMAC روی بسته کنترل و پیش از هر پردازش TLS بررسی می‌شود، بنابراین کلید یا جهت ناهماهنگ خطایی تولید می‌کند که شبیه مشکل گواهی است و دو لایه زودتر تصمیم گرفته می‌شود. برخورد با پاکت به‌عنوان یک شیء مستقل تشخیص را کوتاه می‌کند: فیلدها را بخوانید، تأیید کنید که بررسی زودتر فعال می‌شود، سپس سه چیزی را که دو طرف باید بر آن توافق کنند مقایسه کنید.

پاکت را به همان ترتیبی که ساخته می‌شود بخوانید

یک بسته کنترل شناسه نشست، HMAC اختیاری tls-auth، اطلاعات تکرار و تأیید، و شناسه پیام قابل‌اعتماد را حمل می‌کند و بار نوع پیام پس از آن می‌آید. وقتی پیام یک پیام دست‌دادن باشد، بار آن به‌طور اتفاقی متن رمزشده TLS است. کل رابطه همین است: مواد TLS درون پیامی سفر می‌کند که پاکت از قبل از آن محافظت می‌کند. مرجع پروتکل شبکه OpenVPN فیلدهای کانال کنترل را به همین ترتیب فهرست می‌کند.

لایه اطمینان را به‌راحتی با رمزنگاری اشتباه می‌گیرند. تأییدها، ارسال دوباره و شناسه پیام وجود دارند تا پیام‌های کنترل یک‌بار و به‌ترتیب روی یک انتقال غیرقابل‌اعتماد برسند. آن‌ها احراز هویت نیستند و شناسه پیام درست هیچ چیزی درباره این‌که چه کسی بسته را فرستاده ثابت نمی‌کند.

این گروه‌بندی را مفهومی نگه دارید. این یک نمودار ترتیب بایت نیست و برای محاسبه یک برچسب کافی نیست، زیرا فیلدهایی که وارد HMAC می‌شوند به پیاده‌سازی، نسخه و حالت بستگی دارند.

نشان دهید که بررسی پیش از دست‌دادن فعال می‌شود

گیرنده‌ای که کلید مشترک را دارد می‌تواند HMAC را بررسی کند و بسته جعلی را بی‌درنگ دور بیندازد، بدون تخصیص وضعیت دست‌دادن یا انجام کار کلید عمومی. محافظت شامل بسته‌های اولیه دست‌دادن هم می‌شود، و دقیقاً به همین دلیل کلید اشتباه به‌صورت اتصال ناموفق ظاهر می‌شود و نه خطای احراز هویت دیرهنگام.

سطح توضیح daemon را بالا ببرید و به‌جای دستگاه tun کانال کنترل را زیر نظر بگیرید:

openvpn --config /etc/openvpn/server.conf --verb 6

چیزی که به دنبال آن هستید خطای بررسی HMAC کانال کنترل است که در سطح بسته گزارش می‌شود، پیش از هر هشدار TLS. هشدار TLS در گزارش یعنی پاکت پذیرفته شده و خطا به داخل منتقل شده است، که تحقیقی دیگر با اصلاحی دیگر است.

مدیریت جهت هم اینجاست. وقتی فایل کلید ایستا با tls-auth استفاده می‌شود، دو طرف جهت‌های کلید متضاد می‌گیرند و پروتکل از این تقسیم استفاده می‌کند تا بسته‌ای که گرفته شده نتواند به فرستنده‌اش بازتاب داده شود. برعکس کردن جهت کلید را یکسان نگه می‌دارد و با این حال هر بسته را ناموفق می‌کند. هر بار یک طرف را تغییر دهید و سپس هر دو daemon را راه‌اندازی مجدد کنید تا جفت با هم بارگذاری شوند.

کلید، جهت و digest را در دو طرف هماهنگ کنید

سه مقدار باید توافق داشته باشند و تنها یکی از آن‌ها فایل است. محتوای کلید ایستا باید در هر دو طرف یکسان باشد، جهت باید متضاد باشد و digestی که برای HMAC استفاده می‌شود باید مطابق باشد. پیش از دست زدن به مواد کلید، پیکربندی را بررسی کنید، زیرا یک جهت برعکس بیشتر از یک فایل خراب توضیح می‌دهد:

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

راز مشترک را با ابزار تولید کنید نه با ویرایشگر، و مجوزها را محدود نگه دارید:

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

نسخه‌های قدیمی‌تر ترتیب گزینه‌های کمی متفاوتی را برای تولید کلید می‌پذیرفتند و پروفایل‌هایی که برای آن نسخه‌ها نوشته شده‌اند هنوز در گردش‌اند. فایل تولیدشده در هر دو حالت همان نوع شیء است، بنابراین بررسی این است که آیا دو طرف بایت‌های یکسان دارند، نه این‌که کدام املاء آن‌ها را ساخته است.

tls-auth را با tls-crypt اشتباه نگیرید. هر دو از کانال کنترل محافظت می‌کنند، اما tls-crypt آن را رمزنگاری هم می‌کند و دست‌دادن را از دید ناظران پنهان می‌کند، و تقسیم جهت را با مدیریت کلید خودش جایگزین می‌کند. پروفایلی که یکی را استفاده می‌کند با همتایی که برای دیگری پیکربندی شده کار نمی‌کند و هیچ تنظیمی روی digest آن شکاف را پر نمی‌کند.

برچسب را فقط از قالب واقعی بازتولید کنید

بازتولید دقیق در سطح بایت کاری جدا از اجرای VPN است و فقط با ورودی‌های واقعی کار می‌کند: پیاده‌سازی و نسخه‌ای که بسته را ساخته‌اند، digest انتخاب‌شده، جهت، و بایت‌های واقعی شامل شناسه نشست و آرایه تأیید. نمایش متنی فهرست فیلدها آن بایت‌ها نیست.

طول برچسب از digest ناشی می‌شود، بنابراین فرض طول ثابت همان لحظه‌ای که کسی آن را تغییر دهد می‌شکند. بسته را همان‌طور که پیاده‌سازی هش می‌کند هش کنید، نه آن‌طور که جدولی در یک نوشته وبلاگ ارائه می‌دهد، و با ضبطی که از همان همتا گرفته شده مقایسه کنید نه با انتظاری که دستی استخراج کرده‌اید.

این تمرین را از پروفایل‌های تولیدی دور نگه دارید. هیچ چیز در بازتولید یک برچسب به شما نمی‌گوید که آیا یک استقرار باید محافظت را فعال کند.

ناهماهنگی را بدون حذف محافظت عقب بزنید

آزمون وسوسه‌انگیز پاک کردن tls-auth، دیدن موفقیت اتصال و نتیجه‌گیری این است که کلید اشتباه بوده. آن پاسخ محافظت را از شما می‌گیرد و چیزی درباره این‌که کدام یک از سه مقدار ناهماهنگ بود نمی‌آموزد. در عوض پیکربندی مطابق تأییدشده را از سمت سرور بگیرید و آن را مقایسه کنید.

تغییر را طوری آماده کنید که برگشت‌پذیر باشد. پیکربندی و فایل کلید قبلی سرور را نگه دارید، جفت اصلاح‌شده را اعمال کنید، بررسی کنید که یک کلاینت دست‌دادن را کامل می‌کند و تنها پس از آن نسخه پشتیبان را بردارید. اگر کلاینت‌ها پس از تغییر ناموفق بودند، فایل‌های قبلی را بازگردانید نه این‌که در زمان قطعی یک گونه سوم را بداهه بسازید. بازگردانی باید فرمانی باشد که پیش از شروع از قبل می‌دانید.

در پایان به یاد داشته باشید بررسی موفق چه معنایی دارد. ثابت می‌کند که همتا کلید مشترک را دارد، نه این‌که گواهی یا حساب او مجاز است، و هیچ چیزی درباره رمز کانال داده مذاکره‌شده نمی‌گوید. مجوز و محافظت داده بعداً برقرار می‌شوند، بنابراین بررسی پاک پاکت یک نقطه شروع است نه حکم.