HTTPS Basic Auth vs IPsec: ce protejează fiecare

Deschide instrumentele pentru dezvoltatori, încarcă aplicația internă și urmărește cum o cerere trece prin patru puncte de control înainte ca pagina să fie afișată. Mai întâi numele este rezolvat, apoi se deschide o conexiune TCP, apoi un handshake TLS stabilește cine este serverul și abia apoi aplicația întreabă cine ești. Tratează-le ca evenimente separate, pentru că fiecare eșuează cu dovezi diferite și fiecare aparține unei echipe diferite. Cea mai mare parte a confuziei în incidente vine din a citi un 401 ca problemă de tunel sau o problemă de tunel ca parolă greșită.

Punctul de control unu: este acesta serverul cu care voiai să vorbești

Handshake-ul TLS răspunde la această întrebare înainte de a fi trimisă vreo acreditare. Clientul tău validează lanțul de certificate față de un depozit de încredere și verifică dacă numele din certificat corespunde gazdei pe care ai tastat-o. Dacă asta eșuează, browserul afișează o eroare de certificat și nu trimite deloc antetul Authorization. O cerere de parolă nu este deci dovada că serverul este autentic; este dovada că aplicația a răspuns.

Aici apare prima graniță. TLS protejează conexiunea până la punctul ei de terminare. Dacă un load balancer termină TLS și trimite HTTP simplu către aplicație, segmentul criptat se termină la balancer, iar acreditările sunt protejate doar pe acel prim salt.

Punctul de control doi: ce călătorește de fapt într-un schimb 401

Autentificarea HTTP Basic trimite identificatorul de utilizator și parola într-un antet, codificate cu Base64, așa cum este descris în RFC 7617. Authorization: Basic dXNlcjpwYXNz este forma; codificarea este reversibilă pentru oricine poate citi cererea, așa că toată taina vine din transportul de dedesubt. curl -v arată atât provocarea WWW-Authenticate: Basic, cât și antetul pe care îl trimiți înapoi.

Antetul acela îi spune aplicației cine întreabă. Nu îi spune rețelei cine se poate conecta și nu criptează nimic prin el însuși. Aplicația tot trebuie să verifice acreditarea într-un depozit și să decidă ce poate face acel cont, ceea ce este autorizare și se întâmplă după autentificare.

Unde se află tunelul IPsec în această cale

Acum mergi spre exterior de la browser. Un tunel IPsec între gateway-uri protejează traficul selectat dintre două gateway-uri de securitate, nu dintre laptopul tău și procesul aplicației. ESP în modul tunel împachetează pachetul original, gateway-urile îl criptează și îl autentifică, iar adresele interioare supraviețuiesc, astfel încât partea cealaltă să poată ruta cererea către aplicație.

Selecția este partea care îi pune pe oameni jos. Tunelurile bazate pe politică folosesc selectori de trafic, adesea exprimați ca liste de control al accesului, pentru a decide ce pachete intră în tunel. Tunelurile bazate pe rute folosesc în schimb o interfață virtuală și tabela de rutare. Pe Linux, ip xfrm policy arată selectorii, iar ip xfrm state arată asocierile de securitate stabilite; pe un aparat firewall echivalentul este tabela SA a tunelului plus un trasator de pachete.

Consecința merită spusă direct. Un pachet poate sta într-un tunel perfect sănătos și totuși poartă o cerere HTTPS pe care aplicația o respinge, iar acreditări valide pot ajunge pe o cale fără niciun tunel dacă rutarea permite.

Citește eșecul la stratul care l-a raportat

Un 401 înseamnă că aplicația nu a acceptat acreditarea. Un 403 înseamnă că a acceptat identitatea și a refuzat operația. O eroare TLS înseamnă că clientul nu a acceptat serverul. Nicio rută sau o nepotrivire de politică înseamnă că pachetul nu a ajuns niciodată la gateway-ul îndepărtat. Patru eșecuri diferite, patru responsabili diferiți, și niciunul nu este diagnosticat privind lung la formularul de autentificare.

Folosește dovezile pe care le produce fiecare strat: panoul de rețea al browserului pentru stare și antete, openssl s_client -connect host:443 pentru lanțul de certificate, contoarele SA și jurnalele gateway-ului pentru traficul de tunel, și jurnalul aplicației pentru decizia privind contul. Când două straturi raportează erori simultan, repară-l mai întâi pe cel de jos, pentru că un tunel mort poate masca ușor o eroare de autentificare și invers.

Cartografiază un serviciu de la un capăt la altul

Scrie cinci linii pentru serviciul pe care îl diagnostichezi: ce perechi conectează tunelul, ce subrețele și porturi permit selectorii, unde se termină TLS și ce identitate afirmă certificatul, ce cont și rol de aplicație sunt folosite, și unde jurnalizează fiecare strat. Ține-le pe o singură pagină, pentru că scopul hărții este să arate unde se termină responsabilitatea unui strat și începe următorul.

Apoi testează un caz negativ pe strat. Folosește o parolă greșită și confirmă că primești un 401, nu un timeout. Conectează-te dintr-o subrețea din afara selectorilor și confirmă că pachetul nu este tunelat. Prezintă un certificat pentru numele greșit și confirmă că clientul refuză înainte de a trimite acreditări. Acele trei rezultate îți spun mai multe despre design decât orice diagramă cu cutii.

În final, decide deliberat ce protecție are nevoie fiecare relație. Autentificarea Basic peste TLS se potrivește rezonabil pentru un instrument intern mic în spatele unui gateway; nu este un substitut pentru autorizarea pe utilizator sau pentru protejarea traficului dincolo de punctul de terminare TLS. Tunelul protejează calea, certificatul protejează saltul, iar 401 protejează contul, și doar ultimul știe cine ești.