موضوع مقاله: نشان نام سرور | مخاطب: عمومی | لحن: دانشنامه‌ای | ساختار: عنوان، مقدمه، 3 بخش، جمع‌بندی | مقاله: | # نشان نام سرور | مقدمه: نشانگر نام سرور یک افزونه به پروتکل شبکهٔ کامپیوتری امنیت لایه انتقال (TLS) است که توسط آن یک کلاینت نشان می‌دهد در آغاز فرایند دست‌دهی به کدام نام میزبان می‌خواهد متصل شود. | ## بخش 1: نشان نام سرور | این افزونه به سرور اجازه می‌دهد چندین گواهی کلید عمومی را بر روی یک نشانی آی‌پی و شماره درگاه (پورت) TCP ارائه کند. در نتیجه چندین وب سایت امن (HTTPS) (یا هر سرویس دیگری از طریق TLS) می‌توانند بدون استفاده از یک گواهی واحد از همان نشانی آی‌پی ارائه شوند. پیش‌زمینۀ مشکل پیش از SNI، هنگام برقراری یک اتصال TLS، کلاینت هیچ راهی برای مشخص‌کردن این‌که می‌خواهد به کدام وبگاه متصل شود نداشت. بنابراین، اگر یک سرور چندین وبگاه را روی یک شنوندهٔ واحد میزبانی می‌کرد، سرور راهی نداشت که بداند در پروتکل TLS باید از کدام گواهی استفاده کند. با جزئیات بیشتر، هنگام برقراری اتصال TLS، کلاینت از وب سرور یک گواهی دیجیتال درخواست می‌کند. پس از آن‌که سرور گواهی را فرستاد، کلاینت آن را بررسی می‌کند و نامی را که تلاش داشته به آن متصل شود با نام یا نام‌های موجود در گواهی مقایسه می‌کند. اگر تطابقی یافت نشود، ممکن است به کاربر دربارهٔ این ناسازگاری هشدار داده شود و اتصال قطع شود؛ زیرا این عدم تطابق ممکن است نشان‌دهندۀ تلاش برای یک حمله مرد میانی باشد. با این حال، برخی برنامه‌ها به کاربر اجازه می‌دهند هشدار را نادیده بگیرد و ارتباط را ادامه دهد؛ در این صورت، مسئولیت اعتماد به گواهی و در نتیجه خودِ اتصال بر عهدۀ کاربر خواهد بود. با این حال، دریافت یک گواهی واحد که همۀ نام‌هایی را که یک سرور باید پاسخ‌گوی آن‌ها باشد پوشش دهد، ممکن است دشوار یا حتی ناممکن باشد؛ به‌ویژه چون ممکن است فهرست کامل این نام‌ها از پیش در دسترس نباشد. سروری که مسئول چندین نام میزبان است، به احتمال زیاد باید برای هر نام (یا گروه کوچکی از نام‌ها) گواهی متفاوتی ارائه کند. چنین «گواهی‌های ارتباطات یکپارچه» هر بار که فهرست دامنه‌ها تغییر کند باید دوباره صادر شوند. میزبانی مجازی مبتنی بر نام این امکان را می‌دهد که چندین نام میزبان DNS روی یک سرور واحد (معمولاً یک وب سرور) و روی یک نشانی آی‌پی یکسان میزبانی شوند. برای تحقق این کار، سرور از نام میزبانی که کلاینت به‌عنوان بخشی از پروتکل ارائه می‌کند استفاده می‌کند (در HTTP این نام در سرآیند میزبان ارائه می‌شود). بنابراین، سرور نمی‌توانست از اطلاعات موجود در سرآیند میزبان HTTP برای تصمیم‌گیری دربارۀ این‌که کدام گواهی را ارائه دهد استفاده کند؛ و در نتیجه فقط نام‌هایی که در یک گواهی مشترک پوشش داده شده بودند می‌توانستند از یک نشانی آی‌پی واحد ارائه شوند. | ## بخش 2: نشان نام سرور | در عمل، این بدان معنا بود که یک سرور HTTPS فقط می‌توانست برای مرور امن و کارآمد، یک دامنه (یا گروه کوچکی از دامنه‌ها) را به ازای هر نشانی آی‌پی ارائه کند. اختصاص یک نشانی آی‌پی جداگانه برای هر وبگاه، هزینهٔ میزبانی را افزایش می‌دهد؛ زیرا درخواست برای نشانی‌های آی‌پی باید نزد دفتر ثبت منطقه‌ای اینترنت توجیه شود و نشانی‌های پروتکل اینترنت نسخه ۴ اکنون به پایان رسیده‌اند. در مورد IPv6 نیز، هرچند فضای آدرس‌دهی تمام نشده است، داشتن چند آی‌پی روی یک ماشین، سربار مدیریتی را افزایش می‌دهد. نتیجۀ این وضعیت آن بود که بسیاری از وبگاه‌ها عملاً از استفاده از ارتباطات امن بازمی‌ماندند. پیامدهای امنیتی بارِ دادهٔ SNI رمزنگاری نمی‌شود؛ بنابراین نام میزبان سروری که کلاینت تلاش می‌کند به آن متصل شود برای یک شنودگر منفعل قابل مشاهده است. این ضعف پروتکلی توسط نرم‌افزارهای امنیتی برای پالایش و پایش شبکه و نیز توسط دولت‌ها برای اعمال سانسور به کار گرفته شده است. هنگامی که کلاینت از دامنه صوری استفاده می‌کند، دامنهٔ سرور را در SNI (که رمزنگاری نشده) جایگزین می‌کند، اما آن را در سرآیند میزبان HTTP (که به‌وسیلهٔ TLS رمزنگاری می‌شود) دست‌نخورده می‌گذارد تا سرور بتواند محتوای درست را ارائه کند. دامنه صوری با استاندارد تعریف‌کنندۀ خودِ SNI ناسازگار است، بنابراین سازگاری آن محدود است (بسیاری از سرویس‌ها بررسی می‌کنند که نام میزبان SNI با نام میزبان در سرآیند HTTP یکسان باشد و اگر SNI با دامنه صوری را نامعتبر بدانند، اتصال را رد می‌کنند). هرچند دامنه صوری در گذشته برای دور زدن سانسور دولتی استفاده می‌شد، محبوبیت آن کاهش یافت؛ زیرا ارائه‌دهندگان بزرگ ابری (سکوی ابری گوگل، AWS آمازون و CloudFront) آن را صراحتاً در شرایط خدمات خود ممنوع کرده‌اند و محدودیت‌های فنی علیه آن اعمال کرده‌اند. ECH بارِ داده را با یک کلید عمومی رمزنگاری می‌کند که طرف اتکاپذیر (برای نمونه یک مرورگر وب) باید آن را از پیش بداند؛ ازاین‌رو ECH برای CDNهای بزرگ بیشترین کارایی را دارد. همچنین، رمزنگاری افزونه‌ها به‌صورت تک‌به‌تک مستلزم نوعی رمزنگاری‌شده برای هر افزونه بود که هر یک می‌توانست پیامدهای حریم خصوصی خاص خود را داشته باشد، و حتی در آن حالت نیز مجموعۀ افزونه‌های اعلام‌شده آشکار می‌مانْد. افزون بر این، استقرار واقعی ESNI محدودیت‌های ناسازگاری میان پیاده‌سازی‌ها را آشکار کرد. در ژوئیهٔ ۲۰۲۳، در نشست IETF117، اعضای درگیر در کار روی ECH اعلام کردند که کروم و فایرفاکس در حال انجام آزمایش نمونه‌گیری ۱ درصدی هستند و انتظار می‌رود پیش‌نویس نهایی تا ژانویهٔ ۲۰۲۴ برای ارزیابی به IESG ارسال شود. در سپتامبر ۲۰۲۳، کلادفلر پشتیبانی از ECH را برای دامنه‌های میزبانی‌شده آغاز کرد. | ## بخش 3: نشان نام سرور | در سپتامبر ۲۰۲۳، کرومیوم نسخهٔ ۱۱۷ (که در گوگل کروم، مایکروسافت اج، سامسونگ اینترنت و اپرا به کار می‌رود) به‌طور پیش‌فرض ECH را فعال کرد؛ البته با این شرط که کلیدها در رکوردهای منبع HTTPS در DNS مستقر شده باشند. ECH از نسخهٔ ۱۱۹ فایرفاکس که در اکتبر ۲۰۲۳ منتشر شد نیز به‌طور پیش‌فرض فعال است و موزیلا توصیه می‌کند همراه با دی‌ان‌اس بر روی پروتکل انتقال ابرمتن استفاده شود. ESNI (۲۰۱۸–۲۰۲۰) نسخۀ آغازین این افزونه در سال ۲۰۱۸ «SNI رمزنگاری‌شده» یا ESNI نام داشت و پیاده‌سازی‌های آن به‌شکل «آزمایشی» برای مقابله با خطر شنود دامنه عرضه شدند. در اوت ۲۰۲۰، دیوار آتش بزرگ چین شروع به مسدودکردن ترافیک ESNI کرد، در حالی که همچنان ترافیک ECH را مجاز می‌گذاشت. در اکتبر ۲۰۲۰، شرکت روسی روس‌تلکام و اپراتور همراه آن تله۲ روسیه نیز شروع به مسدودکردن ترافیک ESNI کردند. در سپتامبر همان سال، نهاد سانسور روسیه یعنی خدمت فدرال نظارت بر ارتباطات، فناوری اطلاعات و رسانه‌های جمعی قصد داشت دامنه‌ای از پروتکل‌های رمزنگاری، از جمله TLS 1.3 و ESNI، را ممنوع کند؛ زیرا این پروتکل‌ها سانسور دسترسی به وبگاه‌ها را دشوار می‌کردند. برای آن‌که یک نرم‌افزار کاربردی بتواند SNI را پیاده‌سازی کند، کتابخانۀ TLS مورد استفادهٔ آن باید از SNI پشتیبانی کند و برنامه نیز باید نام میزبان را به آن کتابخانه تحویل دهد. موضوع وقتی پیچیده‌تر می‌شود که کتابخانۀ TLS ممکن است یا در خودِ برنامه گنجانده شده باشد یا جزئی از سیستم‌عامل زیرساختی باشد. به همین دلیل، برخی مرورگرها هنگام اجرا روی هر سیستم‌عاملی SNI را پیاده‌سازی می‌کنند، در حالی که برخی دیگر فقط هنگام اجرا روی بعضی سیستم‌عامل‌های خاص از آن پشتیبانی می‌کنند. پشتیبانی + پشتیبانی پشتیبانی از SNI پشتیبانی از ECH نرم‌افزار نوع پشتیبانی‌شده توضیحات از نسخه پشتیبانی‌شده توضیحات Alpine IMAP کلاینت رایانامه از نسخهٔ ۲٫۲۲ ۲۰۱۹-۰۲-۱۸ اینترنت اکسپلورر مرورگر وب از نسخهٔ ۷ در ویستا (در اکس‌پی پشتیبانی نمی‌شود) ۲۰۰۶ مایکروسافت اج مرورگر وب همهٔ نسخه‌ها از نسخهٔ ۱۰۵ پشت پرچم آزمایشی فایرفاکس مرورگر وب از نسخهٔ ۲٫۰ ۲۰۰۶ در نسخهٔ ۸۵ پشت پرچم آزمایشی معرفی شد. cURL ابزار خط فرمان و کتابخانه از نسخهٔ ۷٫۱۸٫۱ ۲۰۰۸ سافاری مرورگر وب در ویندوز اکس‌پی پشتیبانی نمی‌شود گوگل کروم مرورگر وب ۲۰۱۰ از نسخهٔ ۱۰۵ پشت پرچم آزمایشی. کاربرد در فیلترشکن‌ها در نرم‌افزارهای فیلترشکنی که در کشورهای سرکوبگر و سانسورکننده کار می‌کنند، نشان نام سرور را نام دامنه‌ای که در وایت لیست دولت کشور سانسورکننده است می‌گذارند در حالی که آی‌پی همان آی‌پی سرور بیرون از کشور است. | ## جمع‌بندی | از این رو، بستهٔ فرستاده شده از کلاینت، کمتر مشکوک خواهد بود، چون دستگاه فیلترینگ کشور سانسورکننده نمی‌داند آیا آی‌پی واقعاً آی‌پی همان وبسایت درون لیست سفید است یا نه؛ بنابراین، از دیدگاه دولت سانسورچی، فیلتر کردن بستهٔ فرستاده شده تلفات جانبی خواهد داشت و احتمال فیلتر شدن آن کمتر می‌شود.