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

دو شیء که در یک ضبط شبیه هم به نظر می‌رسند

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

Object in playWhat it establishes
Key-exchange shareCryptographic state for this connection
Server certificateWhich server the client reached
Client certificateClient authentication, when requested
Application sessionAccount identity inside the application

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

تصمیم بگیرید یک دست‌دادن ضبط‌شده چه چیزی را می‌تواند اثبات کند

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

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

پیام‌ها را بخوانید، نه نام رمز را

از سرور بپرسید چه می‌خواهد، به‌جای اینکه از مجموعه رمزها استنتاج کنید. یک دست‌دادن TLS 1.3 که درخواست گواهی دارد در متن ضبط دیده می‌شود، و نبودنش نیز همان‌قدر دیدنی است.

openssl s_client -connect app.example.net:443 -tls1_3 -msg < /dev/null 2>&1 | grep -i -E 'key_share|CertificateRequest'

سپس با گواهی مشتری پیکربندی‌شده تکرار کنید و مقایسه کنید. اجرای دوم باید نشان دهد گواهی فرستاده و پذیرفته می‌شود؛ اجرای نخست باید هیچ نشان ندهد، و همین تفاوت محسوس موضوع بحث است.

openssl s_client -connect app.example.net:443 -tls1_3 -cert client.pem -key client.key -quiet

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

کجا ادامه دادن پاسخ را تغییر می‌دهد

ادامه در TLS 1.3 از بلیت‌های وابسته به وضعیت سرّی استفاده می‌کند، بنابراین اتصال بعدی می‌تواند بدون تبادل کامل گواهی کامل شود. این آنچه مشاهده‌گر می‌بیند را کاهش می‌دهد و آنچه متن ضبط اثبات می‌کند را تغییر می‌دهد. هویتی را در جایی که نبوده ایجاد نمی‌کند. نشست ادامه‌یافته هنوز به همان نشست برنامه تعلق دارد، و هر کوکی یا توکن در آن نشست همان شناسه مهم می‌ماند.

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

چهار ویژگی ثبت کنید، نه یک حکم

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

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

مقالات مرتبط