چرا openssl rand نمی‌تواند کلیدی را بسازد که tls-crypt می‌خواهد

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

فایلی که روی دیسک است واقعاً باید چه باشد

فایل کلید ایستای OpenVPN متن است. با یک خط توضیح شروع می‌شود که اعلام می‌کند چیست، داده‌های هگز را در ردیف‌هایی با عرض ثابت حمل می‌کند و در مجموع 256 بایت مواد کلید دارد. OpenVPN آن را به‌عنوان راز مشترک کانال کنترل می‌خواند، نه به‌عنوان گواهی، نه به‌عنوان عبارت عبور و نه چیزی که یک کتابخانه TLS تشخیص دهد.

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

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

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

کلید ایستای ساده را با ابزاری که آن را مصرف می‌کند تولید کنید و سپس از هر دو سر به آن ارجاع دهید:

openvpn --genkey secret /etc/openvpn/tc-shared.key
tls-crypt /etc/openvpn/tc-shared.key

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

نسل دوم ساختاری اضافه می‌کند که هیچ تولیدکننده بیرونی نمی‌تواند آن را از خود درآورد. کلید سرور یک بار ساخته می‌شود و هر کلاینت یک کلید پیچیده‌شده برگرفته از آن دریافت می‌کند:

openvpn --genkey tls-crypt-v2-server /etc/openvpn/tc-v2-server.key
openvpn --genkey tls-crypt-v2-client /etc/openvpn/laptop1.key --tls-crypt-v2 /etc/openvpn/tc-v2-server.key

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

جایی که بایت‌های دست‌ساز از کار می‌افتند

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

با گونه v2 هیچ چیز معادلی ممکن نیست. کلید کلاینت پیچیده‌شده فقط به‌عنوان خروجی فرایند کلید سرور وجود دارد و سرور موادی را که برای باز کردن آن لازم است نگه می‌دارد. یک توده تصادفی رد می‌شود یا صرفاً در رمزگشایی شکست می‌خورد و هیچ‌یک از این دو پیام به تصادفی‌بودن اشاره نمی‌کند.

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

چرخش بدون قفل‌کردن همه بیرون

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

با چیدمان v2، چرخش به‌ازای هر دستگاه است: یک کلید پیچیده‌شده جدید برای یک ماشین صادر کنید و قدیمی را فقط برای همان ماشین بازنشسته کنید. این استدلال اصلی برای مهاجرت است، وقتی هر کلاینت روی نسخه‌ای است که آن را پشتیبانی می‌کند.

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