OAuth VPN-i sees: millised lõigud nõuavad endiselt TLS-i

Privaatne marsruutimine otsustab, kes jõuab serverini; OAuthi transportreeglid otsustavad, kuidas iga sõnum liigub. Brauser, autoriseerimisserver, tokeni lõpp-punkt ja ressursiserver võivad kõik asuda sama VPN-i taga ja siiski vahetada sõnumeid erinevate lõikude kaudu. Igal lõigul on oma transordinõue ja VPN ei leevenda neist ühtegi. VPN-i piir ja protokolli piir on kaks erinevat joont.

Otsus on lihtsam, kui lõpetate küsimise, kas võrk on usaldusväärne, ja hakkate küsima, milline vahetus ületab millist piiri.

Otsustage lõigu, mitte võrgu järgi

Kirjutage lõpp-punktid eraldi üles: autoriseerimise lõpp-punkt, tokeni lõpp-punkt, ümbersuunamise URI, ressursiserveri URL, TLS-i lõpp-punkt ja VPN-i lüüs. Seejärel märkige, milline pool algatab iga päringu ja kuhu vastus läheb.

Lüüsil lõppev VPN krüpteerib lõigu kuni selle lüüsini. Päring võib selle taga jätkuda tavalise HTTP-na ja see ülejäänud lõik ei ole muutunud HTTPS-iks seetõttu, et varasem lõik krüpteeriti. Just see jätkumine on lõik, millest protokoll hoolib. Esimese hüppe krüpteerimine ei tee teist hüpet turvaliseks.

Transport kannab ka teenuse identiteedi kontrolli. Brauser valideerib rakenduse URL-i sertifikaadi; VPN ei tee seda valideerimist brauseri eest ega muuda valideerimata lõpp-punkti vastuvõetavaks. Sertifikaat nimetab lõpp-punkti, mida klient arvab end kutsuvat. Lüüsini viiv tunnel ei nimeta seda lõpp-punkti ümber ega valideeri seda.

Autoriseerimisvastus ja ümbersuunamise URI

OAuthi kehtiv parim turbetava keelab autoriseerimisvastuste edastamise krüpteerimata ühenduste kaudu. See hõlmab ümbersuunamist, mis viib autoriseerimiskoodi või tokenid kliendile tagasi, mitte ainult algset päringut.

Sama juhis keelab HTTP ümbersuunamise URI-d, välja arvatud määratud native-kliendi loopback-i juhtum. Sisemine hostinimi ei loo uut erandit ja DNS-i nimi, mis laheneb ainult VPN-i sees, on endiselt HTTP URL, kui skeem seda ütleb. Kontrollige skeemi registreeritud URI-s, mitte ainult hostinime.

Registreerige täpne HTTPS ümbersuunamise URI autoriseerimisserveris ja hoidke sertifikaadi valideerimine kliendis sees. Arenduslik otsetee, mis summutab HTTPS-i nõude, loob voo, mis käitub teisiti kui tootmiskonfiguratsioon, mida see peaks modelleerima.

Tokeni lõpp-punkt ja bearer-tokeniga päringud

Tokeni päring kannab volitusi või koodi, mille saab juurdepääsu vastu vahetada. Selle saatmine kaitsmata lõigul paljastab materjali, mida ressursiserver hiljem usaldab, isegi kui ümbritsev võrk on privaatne. Puhverserver, mis suudab päringut lugeda, suudab lugeda ka selle kantavat volitust.

Bearer-tokeniga ressursipäringute puhul käsitleb RFC 6750 TLS-i selle spetsifikatsiooni jaoks kohustuslikuna rakendada ja kasutada. Kontori alavõrgu usaldusväärseks nimetamine ei ole üldine protokollierand, mida avatekstiline bearer-paigaldus vajab.

Kasutage mõlema lõigu jaoks dokumenteeritud turvalisi lõpp-punkti URL-e. Kui teek keeldub HTTP tokeni lõpp-punkti kutsumast, on see keeldumine spetsifikatsioon, mis töötab, mitte möödaminekut nõudev konfiguratsiooniviga. Kirjutage see URL kliendi konfiguratsiooni, selle asemel et seda käitusajal tuletada.

Kus TLS lõpeb ja mida see järele jätab

Kui TLS lõpeb volitatud frontendis, nimetage see frontend ja vaadake üle tee sellest rakenduseni. Frontend vastutab edasisaatmise, usalduse ja konfidentsiaalsuse eest ülejäänud lõigul ning teenuse toetatud arhitektuur peaks seda korraldust kirjeldama.

VPN mujal teel ei lahenda neid vastutusi. See ei ütle teile ka seda, kas brauseri nähtav rakenduse URL vastab sertifikaadile, mille frontend esitab.

Sisemise paigalduse jaoks registreerige lõpp-punkt ja identiteet, mida see esitab. Frontend, mis lõpetab TLS-i teise nime sertifikaadiga, loob brauseri hoiatuse, mille operaatorid sageli summutavad, selle asemel et see parandada.

Native loopback-i erand on kitsas

Loopback-ümbersuunamise erand puudutab tagasikutset kasutaja enda seadmes, kus klient ja brauser jagavad seda seadet. See korraldus kuulub ühe seadme tagasikutsele ega anna õigust teenindada tavalist autoriseerimisserverit või tokenit kandvat API-t HTTP kaudu kontori alavõrgule.

Hoidke erand piiratud kliendi tüübi ja tagasikutsega, mida see kirjeldab. Selle rakendamine veebirakendusele, jagatud sisemisele teenusele või teise hosti ümbersuunamise URI-le muudab paigaldust, mitte erandit.

Testige tegelikku voogu igal piiril ja võrrelge seda kliendi tüübiga. Töötav ümbersuunamine ei ütle midagi selle kohta, kas iga tokenit kandnud lõik kasutas nõutud kaitset, ja roheline VPN-i ikoon ei ütle midagi järgmise päringu skeemi kohta.