HTTPS-basiese verifikasie teenoor IPsec: wat elkeen beskerm

Maak die ontwikkelaarnutsmiddels oop, laai die interne toepassing en kyk hoe een versoek vier kontrolepunte deurloop voordat die bladsy vertoon. Eers los die naam op, dan open ’n TCP-verbinding, dan stel ’n TLS-handdruk vas wie die bediener is, en eers daarna vra die toepassing wie jy is. Behandel dit as afsonderlike gebeurtenisse, want elkeen faal met ander bewyse en elkeen word deur ’n ander span bestuur. Die meeste verwarring by voorvalle kom daarvan dat ’n 401 as ’n tonnelprobleem gelees word, of ’n tonnelprobleem as ’n slegte wagwoord.

Kontrolepunt een: is dit die bediener waarmee jy wou praat

Die TLS-handdruk beantwoord daardie vraag voordat enige geloofsbrief gestuur word. Jou kliënt valideer die sertifikaatketting teen ’n vertrouensbergplek en kontroleer dat die naam in die sertifikaat by die gasheer pas wat jy getik het. As dit misluk, wys die blaaier ’n sertifikaatfout en stuur nooit die Authorization-opskrif nie. ’n Wagwoordprompt is dus nie bewys dat die bediener eg is nie; dit is bewys dat die toepassing geantwoord het.

Hier verskyn die eerste grens. TLS beskerm die verbinding tot by sy beëindigingspunt. As ’n lasbalanseerder TLS beëindig en gewone HTTP na die toepassing aanstuur, eindig die versleutelde segment by die balanseerder, en die geloofsbriewe word net op daardie eerste sprong beskerm.

Kontrolepunt twee: wat werklik in ’n 401-uitruiling reis

HTTP Basic-verifikasie stuur die gebruikersidentifiseerder en wagwoord in ’n opskrif, geënkodeer met Base64 soos beskryf in RFC 7617. Authorization: Basic dXNlcjpwYXNz is die vorm; die enkodering is omkeerbaar deur enigiemand wat die versoek kan lees, so al die geheimhouding kom van die vervoer daaronder. curl -v wys beide die WWW-Authenticate: Basic-uitdaging en die opskrif wat jy terugstuur.

Daardie opskrif vertel die toepassing wie vra. Dit vertel nie die netwerk wie mag koppel nie, en dit versleutel niks op sigself nie. Die toepassing moet steeds die geloofsbrief teen ’n stoor kontroleer en besluit wat daardie rekening mag doen, wat magtiging is en ná verifikasie gebeur.

Waar die IPsec-tonnel in daardie pad sit

Stap nou uitwaarts van die blaaier af. ’n Poort-tot-poort IPsec-tonnel beskerm geselekteerde verkeer tussen twee sekuriteitspoorte, nie tussen jou skootrekenaar en die toepassingsproses nie. Tonnelmodus-ESP omhul die oorspronklike pakket, die poorte versleutel en verifieer dit, en die binnerste adresse oorleef sodat die ander kant die versoek na die toepassing kan roeteer.

Die seleksie is die deel wat mense laat struikel. Beleidgebaseerde tonnels gebruik verkeerskeurders, dikwels as toegangsbeheelyste uitgedruk, om te besluit watter pakkette die tonnel binnegaan. Roetebaseerde tonnels gebruik eerder ’n virtuele koppelvlak en die roetertabel. Op Linux wys ip xfrm policy die keurders en ip xfrm state die gevestigde sekuriteitsassosiasies; op ’n vuurmuurtoestel is die ekwivalent die tonnel se SA-tabel plus ’n pakketspoorder.

Die gevolg is die moeite werd om duidelik te stel. ’n Pakket kan binne ’n heeltemal gesonde tonnel sit en steeds ’n HTTPS-versoek dra wat die toepassing verwerp, en geldige geloofsbriewe kan oor ’n pad sonder enige tonnel aankom as die roetering dit toelaat.

Lees die fout by die laag wat dit gerapporteer het

’n 401 beteken die toepassing het die geloofsbrief nie aanvaar nie. ’n 403 beteken dit het die identiteit aanvaar en die bewerking geweier. ’n TLS-fout beteken die kliënt het die bediener nie aanvaar nie. Geen roete of ’n beleidswanpassing beteken die pakket het nooit die verre poort bereik nie. Vier verskillende foute, vier verskillende eienaars, en nie een daarvan word gediagnoseer deur na die aanmeldvorm te staar nie.

Gebruik die bewyse wat elke laag lewer: die blaaier se netwerkpaneel vir status en opskrifte, openssl s_client -connect host:443 vir die sertifikaatketting, die poort se SA-tellers en logs vir tonnelverkeer, en die toepassingslog vir die rekeningbesluit. Wanneer twee lae gelyktydig foute rapporteer, maak die laer een eerste reg, want ’n dooie tonnel kan maklik ’n verifikasiefout verberg en omgekeerd.

Karteer een diens van begin tot einde

Skryf vyf reëls vir die diens wat jy ontfout: watter eweknieë die tonnel verbind, watter subnetwerke en poorte die keurders toelaat, waar TLS eindig en watter identiteit die sertifikaat beweer, watter toepassingsrekening en rol gebruik word, en waar elke laag log. Hou dit op een bladsy, want die punt van die kaart is om te wys waar een laag se verantwoordelikheid eindig en die volgende begin.

Toets dan een negatiewe geval per laag. Gebruik ’n verkeerde wagwoord en bevestig dat jy ’n 401 kry, nie ’n tydsverloop nie. Koppel van ’n subnet buite die keurders en bevestig dat die pakket nie deur ’n tonnel gestuur word nie. Wys ’n sertifikaat vir die verkeerde naam en bevestig dat die kliënt weier voordat dit geloofsbriewe stuur. Daardie drie resultate vertel jou meer oor die ontwerp as enige diagram van blokkies.

Besluit laastens doelbewus watter beskerming elke verhouding nodig het. Basic-verifikasie oor TLS pas redelik vir ’n klein interne gereedskap agter ’n poort; dit is nie ’n plaasvervanger vir per-gebruiker magtiging of vir die beskerming van verkeer anderkant die TLS-eindpunt nie. Die tonnel beskerm die pad, die sertifikaat beskerm die sprong, en die 401 beskerm die rekening, en net die laaste een weet wie jy is.