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 слојот, така што современа верзија на протоколот не кажува ништо за тоа кој корисник бил овластен или до кои ресурси може да стигне сесијата. Тоа се одделни контроли со одделни докази.

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