Autenticazione di base su HTTPS rispetto a IPsec: cosa protegge ciascuna

Aprite gli strumenti per sviluppatori, caricate l’applicazione interna e osservate una richiesta attraversare quattro punti di controllo prima che la pagina venga renderizzata. Prima si risolve il nome, poi si apre una connessione TCP, poi l’handshake TLS stabilisce chi è il server e solo dopo l’applicazione chiede chi siete. Trattateli come eventi separati, perché ciascuno fallisce con prove diverse e ciascuno appartiene a un team diverso. La maggior parte della confusione negli incidenti nasce dal leggere un 401 come problema di tunnel, o un problema di tunnel come password sbagliata.

Punto di controllo uno: è questo il server con cui volevate parlare

L’handshake TLS risponde a questa domanda prima che venga inviata qualsiasi credenziale. Il vostro client convalida la catena di certificati rispetto a un archivio di fiducia e controlla che il nome nel certificato corrisponda all’host digitato. Se questo fallisce, il browser mostra un errore di certificato e non invia affatto l’intestazione Authorization. Quindi la richiesta di password non è prova che il server sia autentico; è prova che l’applicazione ha risposto.

Qui compare il primo confine. TLS protegge la connessione fino al suo punto di terminazione. Se un bilanciatore di carico termina TLS e inoltra HTTP semplice all’applicazione, il segmento cifrato finisce al bilanciatore e le credenziali sono protette solo su quel primo salto.

Punto di controllo due: cosa viaggia davvero in uno scambio 401

L’autenticazione di base HTTP invia l’identificatore utente e la password in un’intestazione, codificati con Base64 come descritto nella RFC 7617. Authorization: Basic dXNlcjpwYXNz è la forma; chiunque possa leggere la richiesta può invertire la codifica, quindi tutta la segretezza viene dal trasporto sottostante. curl -v mostra sia la sfida WWW-Authenticate: Basic sia l’intestazione che restituite.

Quell’intestazione dice all’applicazione chi sta chiedendo. Non dice alla rete chi può connettersi e non cifra nulla da sola. L’applicazione deve ancora verificare la credenziale rispetto a un archivio e decidere cosa può fare quell’account, il che è autorizzazione e avviene dopo l’autenticazione.

Dove si colloca il tunnel IPsec in quel percorso

Ora camminate verso l’esterno dal browser. Un tunnel IPsec da gateway a gateway protegge il traffico selezionato tra due gateway di sicurezza, non tra il vostro portatile e il processo dell’applicazione. ESP in modalità tunnel incapsula il pacchetto originale, i gateway lo cifrano e lo autenticano, e gli indirizzi interni sopravvivono così che il lato remoto possa instradare la richiesta all’applicazione.

La selezione è la parte su cui le persone inciampano. I tunnel basati su policy usano selettori di traffico, spesso espressi come liste di controllo degli accessi, per decidere quali pacchetti entrano nel tunnel. I tunnel basati su rotte usano invece un’interfaccia virtuale e la tabella di routing. Su Linux ip xfrm policy mostra i selettori e ip xfrm state le associazioni di sicurezza stabilite; su un dispositivo firewall l’equivalente è la tabella SA del tunnel più un tracer di pacchetti.

La conseguenza merita di essere detta chiaramente. Un pacchetto può stare dentro un tunnel perfettamente sano e comunque trasportare una richiesta HTTPS che l’applicazione rifiuta, e credenziali valide possono arrivare lungo un percorso senza alcun tunnel se il routing lo consente.

Leggete il guasto al livello che lo ha segnalato

Un 401 significa che l’applicazione non ha accettato la credenziale. Un 403 significa che ha accettato l’identità e rifiutato l’operazione. Un errore TLS significa che il client non ha accettato il server. Nessuna rotta o una discrepanza di policy significa che il pacchetto non ha mai raggiunto il gateway remoto. Quattro guasti diversi, quattro proprietari diversi, e nessuno di essi si diagnostica fissando il modulo di accesso.

Usate le prove che ogni livello produce: il pannello di rete del browser per stati e intestazioni, openssl s_client -connect host:443 per la catena di certificati, i contatori SA e i log del gateway per il traffico del tunnel, e il log dell’applicazione per la decisione sull’account. Quando due livelli segnalano errori insieme, correggete prima quello più basso, perché un tunnel morto può facilmente mascherare un guasto di autenticazione e viceversa.

Mappate un servizio da un capo all’altro

Scrivete cinque righe per il servizio che state diagnosticando: quali peer collega il tunnel, quali sottoreti e porte i selettori consentono, dove termina TLS e quale identità afferma il certificato, quale account e ruolo applicativo vengono usati, e dove registra ciascun livello. Tenetele su una pagina, perché lo scopo della mappa è mostrare dove finisce la responsabilità di un livello e inizia la successiva.

Poi provate un caso negativo per livello. Usate una password sbagliata e confermate di ottenere un 401, non un timeout. Connettetevi da una sottorete fuori dai selettori e confermate che il pacchetto non passa nel tunnel. Presentate un certificato per il nome sbagliato e confermate che il client rifiuta prima di inviare credenziali. Quei tre risultati vi dicono più sulla progettazione di qualsiasi diagramma a caselle.

Infine, decidete deliberatamente quale protezione serve a ciascuna relazione. L’autenticazione di base su TLS è una scelta ragionevole per un piccolo strumento interno dietro un gateway; non sostituisce l’autorizzazione per utente né la protezione del traffico oltre il punto di terminazione TLS. Il tunnel protegge il percorso, il certificato protegge il salto e il 401 protegge l’account, e solo l’ultimo sa chi siete.