SSTP و SSL 3.0: برچسب در برابر نسخهٔ مذاکرهشده
برچسب SSL یک نشست SSL 3.0 را اثبات نمیکند. پروتکل اعلامشده را با پروتکلی که سرویس واقعاً مذاکره میکند مقایسه کنید و سپس نسخهٔ قدیمی را کنار بگذارید.
دو نفر میتوانند به همان استقرار SSTP نگاه کنند و به نتیجههای متضاد برسند. یکی مستندات محصول را میخواند، حروف SSL را میبیند و گمان میکند تونل پروتکلی را اجرا میکند که سالها پیش بازنشسته شده است. دیگری به یک دستدادن مدرن اشاره میکند و نتیجه میگیرد که پرسش بسته است. هر دو از برچسبها بحث میکنند نه از نسخهٔ مذاکرهشده، و تنها یکی از این دو مدرک است. مقایسهای که ارزش انجام دادن دارد میان چیزی است که نام وعده میدهد و چیزی که سرویس واقعاً برمیگزیند.
دو پاسخ به یک پرسش
استدلال برچسب آسان بیان میشود: SSTP بهعنوان پروتکل تونلسازی امن روی سوکت توصیف میشود، نام تاریخی SSL میگوید، پس اتصال باید SSL 3.0 باشد. دوام میآورد چون نام واقعاً از همان تبار میآید و چون بیشتر کسانی که آن را تکرار میکنند هرگز به یک دستدادن نگاه نکردهاند. همچنین دوام میآورد چون نتیجه محافظهکارانه به نظر میرسد، چنانکه گمان کردن بدترین حالت انتخاب ایمن باشد. گمان کردن بدترین حالت و اندازهگیری نسخهٔ واقعی دو فعالیت متفاوتاند و تنها یکی از آنها چیزی را تغییر میدهد.
استدلال مدرک پرسشی تنگتر میپرسد. این کارخواه و این کارساز بر سر کدام نسخهٔ پروتکل توافق کردند، در این نقطهٔ پایانی، در این زمان؟ پاسخ از سرویسی میآید که TLS را پایان میدهد، نه از یک صفحهٔ بازاریابی یا مرورگری که به سایتی با نام مشابه رسیده است.
این دو استدلال در آنچه میتوانند اثبات کنند تفاوت دارند. برچسب نمیتواند استقرار قدیمی را از استقرار وصلهشده تشخیص دهد، و دستدادن نمیتواند بگوید یک سرویس بیربط روی همان میزبان چه میکند. از دومی استفاده کنید و استفاده از اولی را کنار بگذارید.
نسخهای را بخوانید که سرویس واقعاً برمیگزیند
با نام بردن اجزا شروع کنید: پیادهسازی کارخواه، پیادهسازی کارساز، نقطهٔ پایانی TLS و هر چیزی در میان که TLS را پایان میدهد و دوباره برقرار میکند. متعادلکنندهٔ باری که TLS را پایان میدهد و با پشتیبان با HTTP ساده سخن میگوید، تغییر میدهد که سیاست کدام دستگاه را باید بخوانید.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null> | grep -E 'Protocol|Cipher' Get-WinEvent -LogName System -ProviderName Schannel -MaxEvents 20
نقطهٔ پایانی و زمان را در کنار نتیجه ثبت کنید، چون تغییر بعدی سیاست یک مشاهدهٔ بیتاریخ را بیفایده میکند. کاوش را از کارخواهی روی همان مسیر شبکهای که کاربران مورد نظر شما هستند تکرار کنید، زیرا یک دستگاه رهگیری میتواند TLS را با تنظیمات خودش پایان دهد. اگر دو موضع ناهمخوان باشند، جزئی را یافتهاید که اهمیت دارد. اگر همخوان باشند، بهجای شعار مدرک دارید.
فیلد ثبت را از مذاکره جدا کنید
شمارهٔ نسخهای که کهنه به نظر میرسد در یک فیلد، همان واقعیت یک نشست SSL 3.0 نیست. RFC 7568 نسخهٔ لایهٔ ثبت و پروتکل مذاکرهشده را دو مسئلهٔ جدا میداند، و دقیقاً از همین تمایز است که پاسخهای نادرست و مطمئن بیرون میآید. پروتکل مذاکرهشده را بخوانید، سپس رمزنگاری را، و تنها پس از آن دربارهٔ نشست نتیجه بگیرید.
همان سند دربارهٔ خود پروتکل صریح است: نباید از SSL 3.0 استفاده شود، و مذاکره یا عقبنشینی به آن ممنوع است. دلیل، ساختار شکستهٔ CBC است که حملهٔ POODLE از آن بهره برد، و این ویژگی پروتکل است نه پیکربندی یک برنامه.
به همین دلیل «این بار کاری احتمالاً سخت بهرهبرداری میشود» دلیلی برای فعال نگه داشتن SSL 3.0 نیست. الزام، حذف پروتکل است، نه بردن بحثی دربارهٔ یک نمایش.
SSL 3.0 را با سیاستی که میتوانید از آن دفاع کنید بازنشسته کنید
در Windows تنظیمات پروتکل Schannel زیر کلید Protocols قرار دارد و برای نقش کارخواه و نقش کارساز جداگانه خوانده میشود، و به همین دلیل تغییری که یک جهت را درست میکند میتواند جهت دیگر را دستنخورده بگذارد. تنظیمات کنونی و الزامات راهاندازی مجدد آنها را Microsoft مستند کرده است، و یک کتابخانهٔ TLS سومشخص روی همان میزبان کاملاً آنها را نادیده میگیرد.
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server' Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols'
سیاست را از مسیر مدیریتی پشتیبانیشده تغییر دهید، تأیید کنید که سرویس مالک پیکربندی خود را دوباره میگیرد، و راه بازگشتی تأییدشده نگه دارید. چسباندن یک اسکریپت رجیستری گسترده از محیطی دیگر همان راهی است که اصلاح یک سرویس به قطعی برای هر کارخواه TLS روی دستگاه تبدیل میشود. دامنهٔ راهاندازی مجدد اینجا مهم است: تنظیمی که اعمالشده به نظر میرسد ممکن است هنوز در حافظهٔ سرویسی بماند که آن را دوباره بارگذاری نکرده است.
همتایی که هنوز نسخهٔ منسوخی را میطلبد به بهروزرسانی یا برنامهٔ مهاجرت نیاز دارد. استثنای مستندنشدهای که بیصدا پروتکل قدیمی را بازمیگرداند استراتژی سازگاری نیست و از بازرسی بعدی جان سالم به در نمیبرد.
تغییر را با اتصالهای تازه بپذیرید
پس از تغییر سیاست با نشستهای تازه بیازمایید، چون اتصالی که پیش از تغییر برقرار شده چیزی دربارهٔ پیکربندی اکنون معتبر اثبات نمیکند. تأیید کنید که پروتکل مجاز موفق میشود و پروتکل ممنوع در فرایند اعتبارسنجی مجاز شکست میخورد، سپس هویت گواهی و بررسیهای اعتماد را دقیقاً همانگونه که بودند بگذارید.
به یاد داشته باشید دستدادن چه چیزی را پوشش نمیدهد. SSTP پس از لایهٔ TLS احراز هویت PPP را حمل میکند، پس یک نسخهٔ پروتکل مدرن هیچ نمیگوید که کدام کاربر مجاز شده یا نشست به کدام منابع میتواند برسد. اینها کنترلهای جدا با مدرکهای جدا هستند.
نتیجه را بهصورت سرویس، پشتیبان، سیاست مجاز و نسخهٔ مشاهدهشده بنویسید. چنین سندی به پرسش امنیتی دقیق پاسخ میدهد، کاری که نه استدلال برچسب و نه استدلال از روی ناراحتی هرگز انجام نمیدهند.