Հիմնական նույնականացում HTTPS-ով ընդդեմ IPsec-ի՝ ինչ է պաշտպանում յուրաքանչյուրը

Բացեք մշակողի գործիքները, բեռնեք ներքին հավելվածը և դիտեք, թե ինչպես է մեկ հարցում անցնում չորս ստուգման կետերով մինչև էջի ցուցադրումը։ Սկզբում լուծվում է անունը, ապա բացվում է TCP կապ, ապա TLS ձեռքսեղմումը հաստատում է, թե ով է սերվերը, և միայն դրանից հետո հավելվածը հարցնում է՝ ով եք դուք։ Վերաբերվեք դրանց որպես առանձին իրադարձությունների, որովհետև յուրաքանչյուրը ձախողվում է տարբեր ապացույցով, և յուրաքանչյուրն ունի տարբեր թիմ։ Միջադեպերում ամենաշատ շփոթությունը գալիս է 401-ը թունելի խնդիր կարդալուց, կամ թունելի խնդիրը՝ վատ գաղտնաբառ կարդալուց։

Ստուգման կետ առաջին՝ սա՞ է այն սերվերը, որի հետ ուզում էիք խոսել

TLS ձեռքսեղմումը պատասխանում է այդ հարցին մինչև որևէ հավատարմագիր ուղարկելը։ Ձեր հաճախորդը վավերացնում է վկայագրերի շղթան վստահության պահոցի դեմ և ստուգում, որ վկայագրի անունը համապատասխանում է ձեր մուտքագրած հոսթին։ Եթե դա ձախողվի, բրաուզերը ցույց է տալիս վկայագրի սխալ և ընդհանրապես չի ուղարկում Authorization վերնագիրը։ Այսպիսով՝ գաղտնաբառի հարցումը սերվերի իսկության ապացույց չէ. դա ապացույց է, որ հավելվածը պատասխանել է։

Այստեղ հայտնվում է առաջին սահմանը։ TLS-ը պաշտպանում է կապը մինչև իր ավարտի կետը։ Եթե բեռնվածքի հավասարակշռիչը ավարտում է TLS-ը և հավելվածին փոխանցում պարզ HTTP, ապա գաղտնագրված հատվածն ավարտվում է հավասարակշռիչի մոտ, և հավատարմագրերը պաշտպանված են միայն այդ առաջին թռիչքի վրա։

Ստուգման կետ երկրորդ՝ ինչ է իրականում ճամփորդում 401 փոխանակման մեջ

HTTP հիմնական նույնականացումը օգտվողի նույնացուցիչը և գաղտնաբառը ուղարկում է վերնագրում՝ Base64-ով կոդավորված, ինչպես նկարագրված է RFC 7617-ում։ Authorization: Basic dXNlcjpwYXNz-ը ձևն է. կոդավորումը կարող է հակադարձել ցանկացած ոք, ով կարող է կարդալ հարցումը, ուստի ամբողջ գաղտնիությունը գալիս է ներքևի տրանսպորտից։ curl -v-ը ցույց է տալիս և՛ WWW-Authenticate: Basic մարտահրավերը, և՛ ձեր վերադարձրած վերնագիրը։

Այդ վերնագիրը հավելվածին ասում է, թե ով է հարցնում։ Այն ցանցին չի ասում, թե ով կարող է միանալ, և ինքնուրույն ոչինչ չի գաղտնագրում։ Հավելվածը դեռ պետք է ստուգի հավատարմագիրը պահոցի դեմ և որոշի, թե այդ հաշիվը ինչ կարող է անել, ինչը լիազորում է և տեղի է ունենում նույնականացումից հետո։

Որտեղ է IPsec թունելը այդ ուղու վրա

Այժմ քայլեք դեպի դուրս բրաուզերից։ Դարպասից դարպաս IPsec թունելը պաշտպանում է ընտրված երթևեկությունը երկու անվտանգության դարպասների միջև, ոչ թե ձեր նոթբուքի և հավելվածի գործընթացի միջև։ Թունելային ռեժիմի ESP-ը փաթաթում է սկզբնական փաթեթը, դարպասները գաղտնագրում և նույնականացնում են այն, և ներքին հասցեները պահպանվում են, որպեսզի հեռավոր կողմը կարողանա հարցումը ուղղորդել հավելվածին։

Ընտրությունը այն մասն է, որտեղ մարդիկ սայթաքում են։ Քաղաքականության վրա հիմնված թունելները օգտագործում են երթևեկության ընտրիչներ, հաճախ արտահայտված որպես մուտքի վերահսկման ցանկեր, որպեսզի որոշեն, թե որ փաթեթներն են մտնում թունել։ Երթուղու վրա հիմնված թունելները փոխարենը օգտագործում են վիրտուալ ինտերֆեյս և երթուղային աղյուսակ։ Linux-ում ip xfrm policy-ը ցույց է տալիս ընտրիչները, իսկ ip xfrm state-ը՝ հաստատված անվտանգության ասոցիացիաները. հրային պատի սարքում համարժեքը թունելի SA աղյուսակն է՝ գումարած փաթեթների հետագծիչ։

Հետևանքը արժե ուղղակի ասել։ Փաթեթը կարող է նստել լիովին առողջ թունելի մեջ և այնուամենայնիվ կրել HTTPS հարցում, որը հավելվածը մերժում է, և վավեր հավատարմագրերը կարող են հասնել առանց թունելի ուղով, եթե երթուղավորումը թույլ է տալիս։

Կարդացեք ձախողումը այն շերտում, որը հաղորդել է դրա մասին

401-ը նշանակում է, որ հավելվածը չի ընդունել հավատարմագիրը։ 403-ը նշանակում է, որ այն ընդունել է ինքնությունը և մերժել գործողությունը։ TLS սխալը նշանակում է, որ հաճախորդը չի ընդունել սերվերը։ Երթուղու բացակայությունը կամ քաղաքականության անհամապատասխանությունը նշանակում է, որ փաթեթը երբեք չի հասել հեռավոր դարպասին։ Չորս տարբեր ձախողումներ, չորս տարբեր սեփականատերեր, և դրանցից ոչ մեկը չի ախտորոշվում մուտքի ձևին նայելով։

Օգտագործեք այն ապացույցները, որ արտադրում է յուրաքանչյուր շերտ՝ բրաուզերի ցանցային վահանակը կարգավիճակների և վերնագրերի համար, openssl s_client -connect host:443-ը՝ վկայագրերի շղթայի համար, դարպասի SA հաշվիչները և մատյանները՝ թունելի երթևեկության համար, և հավելվածի մատյանը՝ հաշվի որոշման համար։ Երբ երկու շերտ միաժամանակ սխալներ են հաղորդում, նախ ուղղեք ստորինը, որովհետև մեռած թունելը հեշտությամբ կարող է քողարկել նույնականացման ձախողումը և հակառակը։

Քարտեզագրեք մեկ ծառայություն ծայրից ծայր

Գրեք հինգ տող այն ծառայության համար, որը հետաքննում եք՝ թունելը որ հասակակիցներին է միացնում, ընտրիչները որ ենթացանցերն ու պորտերն են թույլատրում, որտեղ է ավարտվում TLS-ը և ինչ ինքնություն է հաստատում վկայագիրը, որ հավելվածի հաշիվն ու դերն են օգտագործվում, և որտեղ է մատյան վարում յուրաքանչյուր շերտը։ Պահեք դրանք մեկ էջում, որովհետև քարտեզի նպատակն է ցույց տալ, թե որտեղ է ավարտվում մի շերտի պատասխանատվությունը և սկսվում հաջորդը։

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

Վերջապես, գիտակցաբար որոշեք, թե յուրաքանչյուր հարաբերություն ինչ պաշտպանության կարիք ունի։ TLS-ի վրայի հիմնական նույնականացումը խելամիտ ընտրություն է դարպասի հետևում գտնվող փոքր ներքին գործիքի համար. այն չի փոխարինում օգտվողական լիազորումը կամ TLS վերջնակետից այն կողմ երթևեկության պաշտպանությունը։ Թունելը պաշտպանում է ուղին, վկայագիրը՝ թռիչքը, իսկ 401-ը՝ հաշիվը, և միայն վերջինն է իմանում, թե ով եք դուք։