SSTP и SSL 3.0: етикетът срещу договорената версия

Двама души могат да гледат едно и също внедряване на SSTP и да стигнат до противоположни изводи. Единият чете документацията на продукта, вижда буквите SSL и предполага, че тунелът работи с протокол, оттеглен преди години. Другият сочи към модерен handshake и заключава, че въпросът е затворен. И двамата спорят от позицията на етикети, а не на договорената версия, и само едно от тези двете е доказателство. Сравнението, което си заслужава, е между това, което името обещава, и това, което услугата действително избира.

Два отговора на един и същ въпрос

Аргументът за етикета е лесен за формулиране: SSTP е описан като защитен протокол за тунелиране през сокети, историческото име казва SSL, следователно връзката трябва да е SSL 3.0. Той се задържа, защото името наистина идва от тази линия и защото повечето хора, които го повтарят, никога не са гледали handshake. Задържа се и защото изводът звучи предпазливо, сякаш да предполагаш най-лошото е безопасният избор. Да предполагаш най-лошото и да измерваш действителната версия са различни дейности и само една от тях променя нещо.

Аргументът за доказателството задава по-тесен въпрос. За коя версия на протокола са се съгласили този клиент и този сървър, на тази крайна точка, в този момент? Отговорът идва от услугата, която терминира TLS, а не от маркетингова страница или браузър, който е достигнал сайт с подобно име.

Двата аргумента се различават по това какво могат да докажат. Етикетът не може да различи старо внедряване от поправено, а handshake-ът не може да ви каже какво прави несвързана услуга на същия хост. Използвайте втория и спрете да използвате първия.

Прочетете версията, която услугата действително избира

Започнете с назоваването на компонентите: клиентската реализация, сървърната реализация, крайната точка на 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 клиент на машината. Обхватът на рестартирането има значение тук: настройка, която изглежда приложена, може все още да се държи в паметта на услуга, която не я е презаредила.

Партньор, който все още изисква остаряла версия, се нуждае от актуализация или план за миграция. Недокументирано изключение, което тихо връща стария протокол, не е стратегия за съвместимост и няма да преживее следващия одит.

Приемете промяната с нови връзки

Тествайте с нови сесии след промяната на политиката, защото връзка, установена преди промяната, не доказва нищо за конфигурацията, която сега е в сила. Потвърдете, че одобреният протокол успява и че забраненият се проваля чрез оторизирания процес за валидиране, след което оставете идентичността на сертификата и проверките за доверие точно както са били.

Помнете какво handshake-ът не покрива. SSTP пренася PPP удостоверяване след TLS слоя, така че модерна версия на протокола не казва нищо за това кой потребител е оторизиран или до какви ресурси може да достигне сесията. Това са отделни контроли с отделни доказателства.

Запишете резултата като услуга, бекенд, разрешена политика и наблюдавана версия. Този запис отговаря точно на въпроса за сигурността, което не прави нито аргументът за етикета, нито аргументът от неудобство.