سطر گزارشی که DHE-RSA-AES256-SHA را نام می‌برد، خلاصه کل اتصال نیست. به دست‌دادن TLS تعلق دارد که از کانال کنترل محافظت می‌کند، و ترافیک داخل تونل می‌تواند کاملاً به شکل دیگری رمزنگاری شده باشد. ارائه آن به‌عنوان رمزنگاری داده VPN همان اشتباهی است که باید از آن پرهیز کرد.

دو نتیجه اهمیت دارند و به دو پرسش متفاوت پاسخ می‌دهند. یکی مجموعه TLS مذاکره‌شده برای کانال کنترل است؛ دیگری رمزنگاری داده بسته‌هایی است که تونل حمل می‌کند.

دو نتیجه، دو پرسش

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

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

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

نام مجموعه TLS را در بافت خودش رمزگشایی کنید

در یک نام تاریخی به سبک OpenSSL مانند DHE-RSA-AES256-SHA، هر مؤلفه تصمیم متفاوتی را توصیف می‌کند. DHE توافق کلید موقت Diffie-Hellman است، RSA روش احراز هویت است، AES256 رمز AES-256 در حالت CBC برای رکوردهای TLS است، و SHA کد اصالت رکورد مبتنی بر SHA-1 است.

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

مرجع مجموعه‌های OpenSSL این نام‌ها را در صورت ناآشنا بودن هر مؤلفه به تعریف‌هایشان پیوند می‌دهد.

نتیجه کانال داده را برای ترافیک حمل‌شده بخوانید

برای ترافیک حمل‌شده، سطر کانال داده را از همان نشست بخوانید. فهرست data-ciphers در پیکربندی مجموعه مجاز است، نه شواهدی بر مذاکره یک الگوریتم خاص. گزارش انتخاب را ثبت می‌کند؛ پیکربندی فهرست گزینه‌ها را ثبت می‌کند.

رمزنگاری AEAD مانند AES-GCM بررسی یکپارچگی خود را همراه دارد، بنابراین کد اصالت جداگانه کانال داده بخشی از آن مسیر نیست.

دستور auth نه TLS را ارتقا می‌دهد، نه گواهی‌ها و نه رمزنگاری داده را. برای بخش‌هایی از پروتکل که هنوز از درهم‌ساز استفاده می‌کنند یکی را انتخاب می‌کند، و با رمزنگاری داده AEAD کد اصالت داده جدایی برای پیکربندی وجود ندارد.

بررسی‌های هویت را بیرون از نتیجه رمزنگاری نگه دارید

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

این بررسی‌ها را در یادداشت‌های بازبینی کنار نتیجه رمزنگاری نگه دارید، نه ادغام‌شده با آن.

نتایج مذاکره‌شده نشست جاری را ثبت کنید

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

برای بازبینی سیاست، نسخه و مجموعه TLS مذاکره‌شده، رمزنگاری داده انتخاب‌شده و تنظیمات اعتبارسنجی گواهی را یکجا به مالک پیکربندی بدهید. آن لایه را تغییر دهید و سپس گزارش تازه‌ای بخوانید تا مقادیر مذاکره‌شده جدید را تأیید کنید.

مقالات مرتبط