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-ն TLS շերտից հետո կրում է PPP նույնականացում, այնպես որ ժամանակակից արձանագրության տարբերակը ոչինչ չի ասում, թե որ օգտվողն է լիազորվել կամ նստաշրջանը որ ռեսուրսներին կարող է հասնել։ Դրանք առանձին կառավարման միջոցներ են՝ առանձին ապացույցներով։

Գրանցեք արդյունքը որպես ծառայություն, բեքենդ, թույլատրված քաղաքականություն և դիտարկված տարբերակ։ Նման գրառումը ճշգրիտ պատասխանում է անվտանգության հարցին, ինչը ոչ պիտակի փաստարկը, ոչ էլ անհարմարության փաստարկը երբեք չի անում։