SSTP і 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 перадае аўтэнтыфікацыю PPP пасля ўзроўню TLS, таму сучасная версія пратакола нічога не кажа пра тое, які карыстальнік быў аўтарызаваны або да якіх рэсурсаў можа дабрацца сеанс. Гэта асобныя механізмы кантролю з асобнымі доказамі.

Запішыце вынік як служба, бэкенд, дазволеная палітыка і назіраная версія. Такі запіс дакладна адказвае на пытанне бяспекі, чаго не робіць ні аргумент ад ярлыка, ні аргумент ад нязручнасці.