HTTP-perusautentikointi HTTPS:n kautta vastaan IPsec: mitä kumpikin suojaa

Avaa kehittäjätyökalut, lataa sisäinen sovellus ja katso, miten yksi pyyntö kulkee neljän tarkistuspisteen läpi ennen kuin sivu piirretään. Ensin nimi selvitetään, sitten TCP-yhteys avautuu, sitten TLS-kättely vahvistaa, kuka palvelin on, ja vasta sen jälkeen sovellus kysyy, kuka sinä olet. Käsittele näitä erillisinä tapahtumina, koska jokainen epäonnistuu eri todisteilla ja jokaisella on eri omistajatiimi. Suurin osa häiriöiden sekaannuksesta syntyy siitä, että 401 luetaan tunneliongelmaksi tai tunneliongelma huonoksi salasanaksi.

Tarkistuspiste yksi: onko tämä se palvelin, jolle halusit puhua

TLS-kättely vastaa tähän kysymykseen ennen kuin yhtään tunnistetietoa lähetetään. Asiakkaasi validoi varmenneketjun luottamusvarastoa vastaan ja tarkistaa, että varmenteen nimi vastaa kirjoittamaasi isäntää. Jos tämä epäonnistuu, selain näyttää varmennevirheen eikä lähetä Authorization-otsaketta lainkaan. Salasanakehote ei siis ole todiste siitä, että palvelin on aito; se on todiste siitä, että sovellus vastasi.

Tässä ensimmäinen raja tulee näkyviin. TLS suojaa yhteyden sen päätepisteeseen asti. Jos kuormantasaaja päättää TLS:n ja välittää tavallisen HTTP:n sovellukselle, salattu jakso päättyy kuormantasaajaan ja tunnistetiedot ovat suojattuja vain sillä ensimmäisellä hypyllä.

Tarkistuspiste kaksi: mitä 401-vaihdossa todella kulkee

HTTP-perusautentikointi lähettää käyttäjätunnisteen ja salasanan otsakkeessa, Base64-koodattuna, kuten kuvataan dokumentissa RFC 7617. Authorization: Basic dXNlcjpwYXNz on muoto; kuka tahansa pyynnön lukeva voi purkaa koodauksen, joten kaikki salaisuus tulee sen alla olevasta siirtokerroksesta. curl -v näyttää sekä WWW-Authenticate: Basic-haasteen että otsakkeen, jonka lähetät takaisin.

Tämä otsake kertoo sovellukselle, kuka kysyy. Se ei kerro verkolle, kuka saa yhdistää, eikä se salaa mitään itsessään. Sovelluksen on yhä tarkistettava tunnistetieto varastoa vastaan ja päätettävä, mitä tili saa tehdä, mikä on valtuuttamista ja tapahtuu todennuksen jälkeen.

Missä IPsec-tunneli on tällä polulla

Kävele nyt ulospäin selaimesta. Yhdyskäytävien välinen IPsec-tunneli suojaa valittua liikennettä kahden turvayhdyskäytävän välillä, ei kannettavasi ja sovellusprosessin välillä. Tunnelitilan ESP käärii alkuperäisen paketin, yhdyskäytävät salaavat ja todentavat sen, ja sisäiset osoitteet säilyvät, jotta kaukopuoli voi reitittää pyynnön sovellukselle.

Valinta on se osa, johon ihmiset kompastuvat. Käytäntöpohjaiset tunnelit käyttävät liikenteen valitsimia, usein pääsynvalvontaluetteloina ilmaistuina, päättääkseen, mitkä paketit tulevat tunneliin. Reittipohjaiset tunnelit käyttävät sen sijaan virtuaaliliitäntää ja reititystaulua. Linuxissa ip xfrm policy näyttää valitsimet ja ip xfrm state näyttää muodostetut turvayhteydet; palomuurilaitteessa vastaava on tunnelin SA-taulukko sekä paketinseuranta.

Seuraus kannattaa sanoa suoraan. Paketti voi istua täysin terveessä tunnelissa ja silti kuljettaa HTTPS-pyyntöä, jonka sovellus hylkää, ja kelvolliset tunnistetiedot voivat saapua polkua, jolla ei ole tunnelia lainkaan, jos reititys sen sallii.

Lue vika siltä kerrokselta, joka sen raportoi

401 tarkoittaa, että sovellus ei hyväksynyt tunnistetietoa. 403 tarkoittaa, että se hyväksyi identiteetin ja hylkäsi toiminnon. TLS-virhe tarkoittaa, että asiakas ei hyväksynyt palvelinta. Reitin puuttuminen tai käytäntöjen yhteensopimattomuus tarkoittaa, että paketti ei koskaan saavuttanut kaukaista yhdyskäytävää. Neljä eri vikaa, neljä eri omistajaa, eikä yhtäkään niistä diagnosoida tuijottamalla kirjautumislomaketta.

Käytä todisteita, joita kukin kerros tuottaa: selaimen verkko-paneeli tiloja ja otsakkeita varten, openssl s_client -connect host:443 varmenneketjua varten, yhdyskäytävän SA-laskurit ja lokit tunneliliikennettä varten sekä sovelluksen loki tilipäätöstä varten. Kun kaksi kerrosta raportoi virheitä yhtä aikaa, korjaa ensin alempi, koska kuollut tunneli voi helposti peittää todennusvian ja päinvastoin.

Kartoita yksi palvelu päästä päähän

Kirjoita viisi riviä palvelulle, jota selvität: mitkä vastapuolet tunneli yhdistää, mitkä aliverkot ja portit valitsimet sallivat, missä TLS päättyy ja mitä identiteettiä varmenne väittää, mitä sovellustiliä ja roolia käytetään, ja mihin kukin kerros lokittaa. Pidä ne yhdellä sivulla, koska kartan tarkoitus on näyttää, mihin yhden kerroksen vastuu loppuu ja mistä seuraava alkaa.

Testaa sitten yksi negatiivinen tapaus kerrosta kohden. Käytä väärää salasanaa ja varmista, että saat 401:n, et aikakatkaisua. Yhdistä aliverkosta valitsimien ulkopuolelta ja varmista, että paketti ei kulje tunnelin läpi. Esitä varmenne väärälle nimelle ja varmista, että asiakas kieltäytyy ennen tunnistetietojen lähettämistä. Nuo kolme tulosta kertovat suunnittelusta enemmän kuin mikään laatikkokaavio.

Päätä lopuksi tietoisesti, millaista suojaa kukin suhde tarvitsee. Perusautentikointi TLS:n yli on järkevä valinta pienelle sisäiselle työkalulle yhdyskäytävän takana; se ei korvaa käyttäjäkohtaista valtuuttamista eikä liikenteen suojaamista TLS-päätepisteen ulkopuolella. Tunneli suojaa polun, varmenne suojaa hypyn ja 401 suojaa tilin, ja vain viimeinen tietää, kuka sinä olet.