OpenVPN بدون CA: چگونه peer-fingerprint همتایان را تأیید می‌کند
اثر انگشت یک گواهی را سنجاق می‌کند، نه یک راز مشترک. دنبال کنید که خلاصه چه چیزی را پوشش می‌دهد، هر طرف فهرست مجاز خود را چگونه می‌سازد و تمدید چقدر هزینه دارد.
یک استقرار کوچک به اثر انگشت رو می‌آورد چون مرجع گواهی مانند زیرساختی به نظر می‌رسد که هیچ‌کس وقت اداره‌اش را ندارد. غریزه معقول است، اما میانبری که مردم به جای آن می‌گیرند—کپی کردن یک راز کانال داده به دو سر—چنین نیست. پیکربندی peer-fingerprint ساختار TLS را دست‌نخورده نگه می‌دارد: هر طرف هنوز کلید خصوصی و گواهی خودش را دارد، و هر طرف هنوز طرف دیگر را تأیید می‌کند. چیزی که تغییر می‌کند این است که تأیید کجا لنگر می‌اندازد: از یک صادرکننده مورد اعتماد به فهرست کوتاهی از خلاصه‌های سنجاق‌شده. چون خلاصه کل گواهی را پوشش می‌دهد نه یک نام را، تمدید به عملیاتی تبدیل می‌شود که واقعاً وقت می‌گیرد.
اثر انگشت واقعاً به چه چیزی متعهد است
اثر انگشت گواهی، خلاصه کل گواهی کدگذاری‌شده با DER است، نه کلید عمومی آن و نه نام موضوع آن. بنابراین دو گواهی با نام‌های یکسان و کلید یکسان اما تاریخ‌های اعتبار متفاوت، اثر انگشت متفاوت دارند. همین سنجاق کردن را دقیق می‌کند، و همین نیز تمدید را آزاردهنده می‌کند. سنجاق نمی‌تواند به معنای اعتماد به یک کلید به طور کلی باشد، چون یک مصنوع را در یک لحظه از عمرش نام می‌برد. هر کسی می‌تواند خلاصه را بداند، و دانستن آن به خودی خود چیزی را ثابت نمی‌کند.
openssl x509 -in server.crt -noout -fingerprint -sha256
openssl x509 -in client-07.crt -noout -fingerprint -sha256داشتن کلید خصوصی متناظر چیزی است که ثابت می‌کند همتا آن گواهی را دارد، و خلاصه روشی است که طرف دیگر تصمیم می‌گیرد آیا اصلاً چنین گواهی را انتظار داشته است. همین جداسازی دلیل آن است که این طراحی ترتیب قدیمی راز مشترک نیست: کلید مشترک هر کسی را که همان بایت‌ها را بداند تأیید می‌کند، در حالی که سنجاق یک گواهی را تأیید می‌کند. دستگاه متفاوت ورودی خودش را می‌گیرد نه کپی همان راز، که تفاوتی کوچک در فایل‌ها و بزرگ در دامنه خسارت است.
نقشه دوطرفه است، نه متقارن
هر نقطه پایانی دو چیز لازم دارد: کلید خصوصی خودش همراه با گواهی، و بیانیه‌ای درباره اینکه کدام گواهی‌های همتا را می‌پذیرد. در سمت کلاینت آن بیانیه خلاصه گواهی سرور است؛ در سمت سرور فهرست خلاصه‌های کلاینت‌های ثبت‌شده است. یک نمونه رسمی برای پیکربندی کوچک برای Community 2.6 چیدمان را با peer-fingerprint نشان می‌دهد، و ارزش خواندن دارد پیش از آنکه این مدل اعتماد را برای یک استقرار واقعی انتخاب کنید. دو جهت یک فهرست برعکس نیستند، و در یک لحظه شکست نمی‌خورند.
| Verification direction | What is pinned | What never leaves that endpoint | How a wrong pin shows up |
|---|---|---|---|
| Client checks the server | One digest, for the server certificate | The server private key | The client aborts during the TLS handshake |
| Server checks the client | A digest per enrolled client | Each client private key | The server rejects the peer before a tunnel exists |
افزودن یک دستگاه فهرست مجاز روی سرور را ویرایش می‌کند، بدون کپی کردن مواد خصوصی یک کلاینت موجود و بدون جابه‌جا کردن کلید سرور به جایی. دو جهت همچنین مستقل از هم شکست می‌خورند، که در تشخیص مفید است: هر طرفی که دست‌دادن را می‌بندد، همان طرفی است که انتظارش برآورده نشده. اگر کلاینت سرور را رد کند، خلاصه با گواهی ارائه‌شده نمی‌خواند. اگر سرور کلاینت را رد کند، خلاصه آن کلاینت در فهرست نیست، یا کلاینت گواهی‌ای جز گواهی ثبت‌شده ارائه می‌کند.
ثبت: چگونه دستگاه جدید می‌پیوندد
کلید و گواهی دستگاه جدید را همان‌جا که کلید خصوصی زندگی خواهد کرد تولید کنید، سپس فقط مصنوع عمومی را به طرفی ببرید که باید آن را سنجاق کند. خلاصه مورد انتظار را از کانالی منتقل کنید که از قبل به آن اعتماد دارید، و گواهی کامل را مقایسه کنید نه نامی که آشنا به نظر می‌رسد. خلاصه‌ای که از همان دانلود تأییدنشده گواهی کپی شده باشد، فقط ثابت می‌کند دو فایل با هم سازگارند. این بررسی سازگاری است نه بررسی هویت، و آرام‌ترین راهی است که این طراحی ضعیف می‌شود.
روی سرور، افزودن خلاصه تغییری در پیکربندی است که از مدیر معمول عبور می‌کند و پس از آن اتصال دوباره انجام می‌شود. تأیید کنید که دستگاه جدید وصل می‌شود و دستگاهی که خلاصه‌اش حذف شده دیگر وصل نمی‌شود. آزمونی که فقط حالت مثبت را پوشش می‌دهد فهرست مجاز را تأییدنشده رها می‌کند، و دقیقاً همان حالتی است که شش ماه بعد در آن خواهید بود.
تمدید همان لحظه گران است
هر گواهی منقضی می‌شود، و گواهی جدید خلاصه جدیدی دارد حتی وقتی کلید و نام‌ها همان می‌مانند. زیر یک صادرکننده، تمدید برای همتایانی که به آن صادرکننده اعتماد دارند شفاف است؛ زیر سنجاق کردن، برای هر همتایی که گواهی را سنجاق می‌کند یک رویداد ثبت است.
ترتیب را پیش از تاریخ انقضا برنامه‌ریزی کنید نه پس از آن. خلاصه جدید را به طرف‌هایی که آن را تأیید می‌کنند توزیع کنید، تغییر را اعمال کنید، و تنها پس از آن گواهی را روی نقطه پایانی عوض کنید. این ترتیب هیچ پنجره‌ای باقی نمی‌گذارد که دو طرف درباره اینکه کدام گواهی جاری است اختلاف داشته باشند. خود فهرست را هم زیر بازبینی نگه دارید، چون فهرست سنجاق‌شده ورودی‌هایی برای دستگاه‌هایی جمع می‌کند که ماه‌ها پیش بازنشسته شده‌اند. هر ورودی کهنه هویتی است که اگر کلیدش بماند هنوز تأیید می‌شود، پس حذف یکی اقدام امنیتی است نه خانه‌تکانی.
آنچه نقشه اعتماد تعیین نمی‌کند
تأیید هویت یک لایه است، و نقشه سنجاق‌شده هیچ چیزی درباره استخر آدرس‌ها، مسیرهای هل داده‌شده، MTU مسیر یا سیاست دیوار آتش نمی‌گوید. این‌ها پیکربندی جداگانه با حالت‌های خرابی جداگانه باقی می‌مانند. تونلی که تأیید می‌شود و هیچ ترافیکی عبور نمی‌دهد، تحقیقی متفاوت از تونلی است که هرگز بالا نمی‌آید.
نقشه هم بی‌تناسب مقیاس نمی‌گیرد، و PKI مبتنی بر صادرکننده جایی است که استقرارهای بزرگ‌تر به آن می‌رسند. این ترجیح درباره عملیات است نه رمزنگاری، چون افزودن و بازنشسته کردن هویت‌ها از طریق یک مرجع ارزان‌تر از ویرایش فهرست روی هر همتاست وقتی ناوگان رشد می‌کند. جایی که پیاده‌سازی کلاینت این گزینه را پشتیبانی نمی‌کند، پاسخ یک مدل اعتماد سازگار است که آن کلاینت مستند می‌کند، یا یک جایگزین پشتیبانی‌شده. خاموش کردن هشدار تأیید آن پشتیبانی را اضافه نمی‌کند، و تمام ارزش این طراحی در این است که تأیید همچنان رخ می‌دهد.