Come gestisce un reverse proxy il TLS per i container di un server domestico?

Un reverse proxy gestisce il TLS per i container del server domestico accettando la connessione crittografata del browser, presentando il certificato per il nome host richiesto, decrittando la richiesta HTTP, selezionando il container corrispondente e creando una connessione upstream separata verso quel servizio.

Le connessioni browser-proxy e proxy-container sono quindi confini di sicurezza differenti. La prima normalmente usa un certificato pubblico o privato attendibile; la seconda può usare una rete HTTP isolata, una connessione HTTPS separata o il passthrough TLS quando il backend deve mantenere la chiave privata.

Dove termina la connessione TLS del browser?

Con la terminazione TLS, il reverse proxy termina il TLS del client. Il browser autentica il punto finale del proxy e negozia la crittografia con esso anziché direttamente con il container dell'applicazione.

Il proxy quindi detiene la chiave privata del certificato e può leggere il metodo HTTP decrittato, il nome host, il percorso, le intestazioni, i cookie e il corpo. Questa visibilità gli permette di instradare, autenticare, filtrare, comprimere, memorizzare nella cache o aggiungere intestazioni di sicurezza.

La terminazione non significa che il backend possieda il certificato pubblico. Dal punto di vista del browser, il reverse proxy è il server HTTPS; dal punto di vista del container, il proxy è un nuovo client che effettua una richiesta separata.

Come fa una porta HTTPS a raggiungere diversi container?

Un nome DNS pubblico indirizza i client al reverse proxy, e i nomi host selezionano la route del container corrispondente. Ogni nome host può avere il proprio certificato e destinazione upstream pur condividendo la porta 443.

Durante il handshake TLS, il client normalmente fornisce il nome del server previsto affinché il proxy possa scegliere un certificato corrispondente. Dopo la decrittazione, l'intestazione HTTP Host e la route configurata determinano se la richiesta va a Jellyfin, Home Assistant, Vaultwarden o a un altro container.

Una route predefinita dovrebbe rifiutare i nomi host sconosciuti anziché inoltrarli a una dashboard arbitraria. Centralizzare l'accesso non richiede che ogni servizio interno sia raggiungibile tramite il proxy pubblico.

Come vengono emessi e rinnovati i certificati?

I reverse proxy possono agire come client ACME e le sfide DNS automatizzano il rinnovo dei certificati creando un record DNS temporaneo che dimostra il controllo del dominio richiesto.

Una sfida HTTP dimostra il controllo tramite un endpoint web, mentre una sfida DNS può emettere certificati per servizi interni o nomi wildcard senza pubblicare direttamente ogni contenitore. Il metodo di convalida cambia l'esposizione e i requisiti delle credenziali.

L'automazione sposta la scadenza del certificato da un'attività manuale su calendario allo stato dell'infrastruttura. Rende inoltre il token API DNS del proxy, i dati dell'account ACME e l'archiviazione dei certificati risorse sensibili che necessitano di permessi ristretti e backup.

Il traffico è crittografato tra il proxy e il contenitore?

La connessione a monte è configurata in modo indipendente, quindi i collegamenti a monte possono usare HTTP o HTTPS. Terminare il TLS pubblico non decide automaticamente se la connessione interna è crittografata.

HTTP semplice può essere ragionevole su una rete di contenitori privata confinata a un host affidabile, ma il proxy può leggere e modificare quel traffico. Se la connessione a monte attraversa host, reti non affidabili o confini di fiducia più forti, una connessione HTTPS verificata separata riduce l'esposizione.

La ri-crittografia crea due sessioni TLS e due decisioni sui certificati. Il proxy deve convalidare il certificato backend e il nome previsto; abilitare semplicemente HTTPS saltando la verifica sostituisce la crittografia con un tunnel non autenticato.

Come fa il contenitore a conoscere il contesto originale del client?

La connessione TCP a monte origina dal proxy, quindi le connessioni proxy nascondono l'indirizzo originale del client. Le intestazioni inoltrate trasportano l'IP del client, lo schema originale, il nome host e la porta necessari all'applicazione.

Senza lo schema HTTPS originale, un'applicazione potrebbe generare reindirizzamenti HTTP, contrassegnare in modo errato i cookie sicuri o costruire un URL di callback sbagliato. Senza un indirizzo client affidabile, i log, i limiti di velocità e le politiche di accesso potrebbero identificare solo il proxy.

Il proxy deve impostare questi valori in modo coerente e il framework del contenitore deve essere configurato per fidarsi del corretto conteggio dei salti o della rete proxy. Inoltrare un'intestazione e interpretarla in modo sicuro sono compiti separati.

Quale nuovo confine di fiducia crea la terminazione TLS?

I client possono inviare intestazioni di inoltro falsificate da soli, quindi i proxy di fiducia devono igienizzare le intestazioni inoltrate prima che il backend le usi per decisioni di sicurezza.

L'accesso diretto al container dovrebbe essere bloccato quando l'app si fida dell'identità fornita dal proxy. Altrimenti, un client può bypassare il proxy, inviare il proprio valore X-Forwarded-For o schema e impersonare il contesto che l'applicazione presume provenga dall'ingresso di fiducia.

l'ingresso container riscrive il percorso client visibile. Proteggi le chiavi private del proxy, limita la sua interfaccia di gestione, esponi solo le rotte previste e monitora il rinnovo dei certificati e la salute a monte perché il proxy è ora una dipendenza di sicurezza condivisa.

FAQ

Ogni container ha bisogno del proprio certificato TLS pubblico?

Non quando il reverse proxy termina TLS. Il proxy può detenere certificati per diversi nomi host e inoltrare richieste decrittografate a container interni separati.

HTTP dal proxy a un container è sempre insicuro?

Dipende dal confine di fiducia. Una rete isolata sullo stesso host ha un'esposizione diversa rispetto a una rete instradata o condivisa. HTTPS con verifica del certificato offre una protezione più forte attraverso segmenti non affidabili.

Un reverse proxy può instradare HTTPS senza decrittografarlo?

Sì. Il passthrough TLS può instradare usando informazioni del handshake come SNI mentre il backend termina TLS, ma il proxy perde la normale visibilità e il filtraggio a livello HTTP.

Perché i container dovrebbero rifiutare l'accesso diretto esterno?

Quando un'app si fida delle intestazioni inoltrate, l'accesso diretto consente ai client di bypassare l'igienizzazione del proxy e inviare valori falsificati di identità, schema o nome host.

Conclusione finale

Un reverse proxy gestisce TLS diventando il punto crittografico pubblico e creando una seconda connessione, governata separatamente, verso ogni container. La sicurezza affidabile dipende da un corretto instradamento del nome host, dal rinnovo automatico ma protetto dei certificati, dalla crittografia intenzionale a monte, dall'igienizzazione delle intestazioni di inoltro e dal blocco dei percorsi che bypassano il proxy di fiducia.