TLS 1.3 همچنان نام سرور را در متن روشن میفرستد
TLS 1.3 دستدادن را رمز میکند اما SNI را نه. ClientHello را بخوانید، پذیرش واقعی ECH را بررسی کنید و ثبت کنید ناظر هنوز چه چیزی میتواند ببیند.
ارتقای یک شنونده به TLS 1.3 تغییر میدهد که ناظر چه چیزی میتواند بخواند، اما نه به اندازهای که شماره نسخه القا میکند. ClientHello هنوز پیش از هرگونه مذاکره بر سر رمزنگاری سفر میکند و در یک اتصال معمولی نام سرور درخواستی همانجا در متن روشن قرار دارد. Encrypted Client Hello سازوکاری است که آن را پنهان میکند و استقراری جداگانه با پیشنیازهای خودش است. این چهار گام را پیش از نوشتن سیاستی که یکی از این دو رفتار را فرض میکند اجرا کنید.
دستدادن واقعاً چه چیزی را آشکار میکند
TLS 1.3 گواهی سرور و بیشتر دستدادنی را که پس از ServerHello میآید رمز میکند. هر چیزی که کارخواه نخست میفرستد بیرون از آن حفاظت است، چون کلیدها هنوز وجود ندارند. نشانگر نام سرور بخشی از همان نخستین پرواز است، از این رو ناظر غیرفعال هنوز میتواند آن را بدون شکستن چیزی بخواند.
مشخصه ECH، RFC 9849, این را با رمزکردن یک ClientHello درونی برای سروری که همکاری میکند تغییر میدهد. دستدادن بیرونی باقی میماند و نامی عمومی را حمل میکند که شبکه میتواند ببیند، پس استقرار هنوز به هویتی بیرونی نیاز دارد که برای واسطهها معنا داشته باشد. آن نام بیرونی همان بخشی است که مردم وقتی انتظار دارند اتصال ناشناس شود از دست میدهند. این یک نام پوششی است، نه نامی پنهان، و باید مانند هر نام دیگری تفکیک و احراز هویت شود.
هیچکدام از اینها مسیر تحویل را پنهان نمیکند. نشانیهای مبدأ و مقصد، درگاهها، اندازه بستهها و زمانبندی همچنان قابل مشاهدهاند و آنها اغلب بیش از نام درباره اینکه چه کسی صحبت میکند میگویند. تفکیک نام و روابط سطح برنامه لایه دیگری است، هر یک با دیدپذیری خودش.
بهجای فرض، یک ClientHello بخوانید
نسخه در ServerHello به شما نمیگوید کارخواه چه فرستاده است. نخستین پرواز را مستقیم ببینید، از موقعیتی که نماینده ناظری باشد که برایتان مهم است.
openssl s_client -connect app.plant.example:443 -servername app.plant.example -tls1_3 </dev/null> 2>/dev/null | head -20 sudo tcpdump -ni eth0 -c 40 'tcp port 443' -w /tmp/tls.pcap tshark -r /tmp/tls.pcap -Y 'tls.handshake.extensions_server_name' -T fields -e tls.handshake.extensions_server_name
فرمان نخست یک دستدادن انجام میدهد و پارامترهای مذاکرهشده را نشان میدهد، از جمله نسخه پروتکل و نامی که خواستهاید. فرمان دوم نخستین بستههای یک اتصال واقعی را ضبط میکند و سومین فرمان میدان SNI را از آن ضبط بیرون میکشد. اگر میدان پر باشد، ناظری که شبیهسازی کردید میتواند آن را بخواند.
در سمت کارخواه و روی مسیر جداگانه ضبط کنید وقتی این دو همخوان نیستند، چون ضبط محلی ممکن است نامی را نشان دهد که یک middlebox بعداً بازنویسی یا دور میاندازد. از میزبانی هم ضبط کنید که خودش TLS را پایان نمیدهد، زیرا پروکسی پایانی بهحکم طراحی متن روشن را میبیند و چیزی درباره آنچه شبکه میبیند اثبات نمیکند.
با افزونه ECH مانند یک ادعا رفتار کنید، نه یک مدرک
دیدن افزونه ECH در ClientHello به معنای آن نیست که اتصال از ECH استفاده کرده است. کارخواهان وقتی پیکربندی قابل استفاده ندارند GREASE ECH میفرستند، دقیقاً تا دستدادنهایشان یکسان به نظر برسد. افزونه حاضر است، hello درونی طعمه است و نام واقعی همچنان خوانا است.
dig +short HTTPS app.plant.example openssl s_client -connect app.plant.example:443 -tls1_3 -status </dev/null> 2>/dev/null | grep -i -E 'ech|status_request'
فرمان نخست نشان میدهد آیا مبدأ یک رکورد منبع HTTPS با پارامتر پیکربندی ECH منتشر میکند، و کارخواهان کلید را اینگونه میآموزند. فرمان دوم اطلاعات وضعیت دستدادن را جستوجو میکند، هرچند پیام موفقیت کارخواه مدرک قویتری است. پذیرش چیزی است که اهمیت دارد: سروری که کلید منطبق را ندارد نمیتواند hello درونی را رمزگشایی کند و اتصال عقب مینشیند.
کارخواه را هم بررسی کنید، چون پشتیبانی مرورگرها و پیکربندی بر اساس نسخه و سکو متفاوت است. سیاستی که بر „مرورگرهای مدرن از ECH استفاده میکنند“ بنا شده، حدسی درباره یک ناوگان است، نه واقعیتی درباره ناوگان شما. نسخههایی را که واقعاً وصل میشوند فهرست کنید و سپس از هر کدام یکی را آزمایش کنید. همان صفحهای که از یک مرورگر رومیزی روزآمد کار میکند ممکن است هیچ چیز را از کارخواه قدیمیتر در همان شبکه پنهان نکند.
دامنه ناظر را در سیاست بنویسید
مشخص کنید ناظر کجا مینشیند و در آن نقطه چه چیزی دیده میشود، پیش از آنکه تصمیم بگیرید یک کنترل میتواند بر چه چیزی تکیه کند. اتصال مرورگر به یک وبگاه، انتقال VPN بیرونی و پروکسی پایانی TLS هر یک مجموعه متفاوتی از واقعیتها را آشکار میکنند و قاعدهای که برای یک موقعیت نوشته شده بهندرت پاک به موقعیتی دیگر منتقل میشود.
اگر کنترلی به خواندن SNI وابسته است، بیازمایید که کارخواهان مستقر وقتی ECH در دسترس است و وقتی نیست چگونه رفتار میکنند. سپس پیامد سازگاری را ثبت کنید، چون صافیای که بیصدا از تطبیق باز میماند بدتر از صافیای است که هرگز مستقر نشده.
سرانجام، عدمقطعیت را در سابقه نگه دارید. جایگزینی یک ادعای جهانشمول قدیمی با ادعایی تازهتر همان شکاف را زیر نام پروتکل دیگری باقی میگذارد و بازبین بعدی همانقدر محکم آن را باور میکند.