Basisautentikaasje oer HTTPS tsjin IPsec: wat elk beskermet

Iepenje de ûntwikkelersark, laad de ynterne applikaasje en sjoch hoe’t ien fersyk fjouwer kontrôlepunten passearret foardat de side tekenet. Earst wurdt de namme oplost, dan iepenet in TCP-ferbining, dan fêstiget in TLS-hânskodding wa’t de tsjinner is, en pas dan freget de applikaasje wa’t jo binne. Behannelje dizze as aparte barren, want elk falt mei oar bewiis en elk heart by in oar team. It measte betizing by ynsidinten komt fan it lêzen fan in 401 as tunnelprobleem, of in tunnelprobleem as in min wachtwurd.

Kontrôlepunt ien: is dit de tsjinner dêr’t jo mei prate woene

De TLS-hânskodding beantwurdet dy fraach foardat der ea in oanmeldgegevens stjoerd wurde. Jo klant falidearret de sertifikaatkeatling tsjin in fertrouwensopslach en kontrolearret dat de namme yn it sertifikaat oerienkomt mei de host dy’t jo typt hawwe. As dat mislearret, toant de browser in sertifikaatflater en stjoert de Authorization-kop hielendal net. In wachtwurdfraach is dus gjin bewiis dat de tsjinner echt is; it is bewiis dat de applikaasje antwurde hat.

Hjir ferskynt de earste grins. TLS beskermet de ferbining oant har einpunt. As in loadbalancer TLS beëiniget en gewoane HTTP nei de applikaasje trochstjoert, einiget it fersifere segmint by de loadbalancer, en de oanmeldgegevens binne allinnich op dy earste sprong beskerme.

Kontrôlepunt twa: wat der echt reizget yn in 401-útwikseling

HTTP Basis-autentikaasje stjoert de brûkersidentifikaasje en it wachtwurd yn in kop, kodearre mei Base64 lykas beskreaun yn RFC 7617. Authorization: Basic dXNlcjpwYXNz is de foarm; de kodearring kin troch elkenien dy’t it fersyk lêze kin weromdraaid wurde, dus alle geheimhâlding komt fan it ferfier derûnder. curl -v toant sawol de WWW-Authenticate: Basic-útdaging as de kop dy’t jo weromstjoere.

Dy kop fertelt de applikaasje wa’t freget. Hy fertelt it netwurk net wa’t ferbine mei, en hy fersifereet sels neat. De applikaasje moat noch altyd de oanmeldgegevens tsjin in opslach kontrolearje en beslute wat dat akkount meie, wat autorisaasje is en nei autentikaasje bart.

Wêr’t de IPsec-tunnel yn dat paad sit

Gean no nei bûten fan de browser. In IPsec-tunnel fan gateway nei gateway beskermet selektearre ferkear tusken twa befeiligingsgateways, net tusken jo laptop en it applikaasjeproses. ESP yn tunnermodus ferpakt it oarspronklike pakket, de gateways fersiferje en autentisearje it, en de ynderlike adressen oerlibje sadat de fiere kant it fersyk nei de applikaasje routearje kin.

De seleksje is it diel dêr’t minsken oer stroffelje. Beliedsbasearre tunnels brûke ferkearsselektearders, faak útdrukt as tagongskontrôl listen, om te besluten hokker pakketten de tunnel yngeane. Rûtebasearre tunnels brûke ynstee in firtuele ynterface en de rûtingstabel. Op Linux toant ip xfrm policy de selektearders en ip xfrm state de oprjochte befeiligingsassosjaasjes; op in firewallapparaat is it ekwivalint de SA-tabel fan de tunnel plus in pakketspeurder.

It gefolch is de muoite wurdich om dúdlik te sizzen. In pakket kin yn in folslein sûne tunnel sitte en dochs in HTTPS-fersyk drage dat de applikaasje wegert, en jildige oanmeldgegevens kinne oer in paad sûnder hokker tunnel dan ek oankomme as de rûting it tastiet.

Lês de flater op ’e laach dy’t him rapporteare hat

In 401 betsjut dat de applikaasje de oanmeldgegevens net akseptearre hat. In 403 betsjut dat er de identiteit akseptearre hat en de operaasje wegere. In TLS-flater betsjut dat de klant de tsjinner net akseptearre hat. Gjin rûte of in beliedsmisferhâlding betsjut dat it pakket de fiere gateway nea berikt hat. Fjouwer ferskillende flaters, fjouwer ferskillende eigners, en gjinien dêrfan wurdt diagnostisearre troch nei it oanmeldformulier te stoarjen.

Brûk it bewiis dat elke laach produsearret: it netwurkpaniel fan de browser foar status en koppen, openssl s_client -connect host:443 foar de sertifikaatkeatling, de SA-tellers en logboeken fan de gateway foar tunnelferkear, en it logboek fan de applikaasje foar it akkountbeslút. As twa lagen tagelyk flaters rapportearje, reparearje dan earst de legere, want in deade tunnel kin maklik in autentikaasjeflater ferbergje en oarsom.

Karteer ien tsjinst fan begjin oant ein

Skriuw fiif rigels foar de tsjinst dy’t jo ûndersykje: hokker pearen de tunnel ferbynt, hokker subnetten en poarten de selektearders tastean, wêr’t TLS einiget en hokker identiteit it sertifikaat beweart, hokker applikaasje-akkount en rol brûkt wurde, en wêr’t elke laach logt. Hâld se op ien side, want it punt fan de kaart is sjen litte wêr’t de ferantwurdlikheid fan ien laach einiget en de folgjende begjint.

Test dan ien negatyf gefal per laach. Brûk in ferkeard wachtwurd en befêstigje dat jo in 401 krije, net in time-out. Ferbynje út in subnet bûten de selektearders en befêstigje dat it pakket net troch de tunnel giet. Lit in sertifikaat sjen foar de ferkearde namme en befêstigje dat de klant wegeret foardat er oanmeldgegevens stjoert. Dy trije resultaten fertelle jo mear oer it ûntwerp as hokker diagram fan fakjes dan ek.

Beslút úteinlik bewust hokker beskerming elke relaasje nedich hat. Basisautentikaasje oer TLS is in ridlike kar foar in lyts yntern ark efter in gateway; it ferfangt gjin autorisaasje per brûker of de beskerming fan ferkear foarby it TLS-einpunt. De tunnel beskermet it paad, it sertifikaat beskermet de sprong, en de 401 beskermet it akkount, en allinnich de lêste wit wa’t jo binne.