Configurare TLS, HSTS e reindirizzamenti in modo coerente
HTTPS viene imposto in un punto specifico, i certificati vengono verificati e HSTS viene attivato solo dopo la copertura TLS completa con un runtime scelto appositamente.
"Impostazione coerente di TLS, HSTS e reindirizzamenti" viene qui considerata dal punto di vista di "DNS, TLS e reverse proxy". Per gli amministratori di sistema e gli sviluppatori web, "TLS completo" e "Sottodominio bloccato" sono particolarmente importanti.
Pubblicato: 3 minuti di lettura · Autore: Sebastian Geier
In quale ordine vengono implementati in modo sicuro TLS, reindirizzamenti HTTPS e HSTS?
Tutti gli hostname e le risorse devono essere accessibili tramite HTTPS valido prima che HTTP venga reindirizzato in modo permanente. HSTS inizia con un runtime breve e viene esteso, anche ai sottodomini, solo dopo che è stata stabilita una copertura stabile.
Esempio funzionante: "Sottodominio bloccato"
Il dominio principale funziona tramite HTTPS, ma un vecchio sottodominio non funziona. Pertanto, HSTS inizia senza validità del sottodominio; solo dopo un certificato, i reindirizzamenti e il test di tutti gli host, l'ambito viene esteso.
Avvio reversibile di HSTS
Segnale di controllo
Segnale 1
Errori TLS e di contenuto misto a seconda dell'host interessato, del tipo di risorsa e del livello di configurazione che ha attivato l'errore.
Segnale di controllo
Segnale 2
Catene di reindirizzamento e risposte HSTS al di fuori dell'ambito consentito.
Punto di reindirizzamento
Verifica tutti gli host e le risorse direttamente tramite HTTPS con un certificato valido.
Implementare un reindirizzamento persistente canonico al livello responsabile.
Abilitare HSTS con un tempo di esecuzione breve, monitorarlo e solo successivamente estenderlo in modo controllato.
Sottodominio bloccato
Sottodominio bloccato – `includeSubDomains` forza HTTPS su un servizio non ancora configurato.
Catena di reindirizzamenti – Più livelli cambiano host o protocolli in sequenza, creando latenza aggiuntiva o un loop senza destinazione.
Vulnerabilità del certificato – Dopo HSTS, il browser non riesce a raggiungere un host difettoso tramite HTTP.
TLS completo
Criterio di test
TLS completo
Certificato, nomi host e risorse incorporate funzionano senza fallback HTTP.
Criterio di test
Punto di reindirizzamento
Proxy e applicazione non creano catene o destinazioni in conflitto.
Avvio reversibile di HSTS Il runtime breve limita gli errori prima che l'ambito si espanda e i sottodomini aggiuntivi vengano inclusi in modo permanente nella regola.
Cosa è rilevante quando si "Imposta TLS, HSTS e reindirizzamenti in modo coerente"?
Una domanda di approfondimento pertinente con relativa risposta Selezionare l'hosting in base al carico effettivo anziché ai pacchetti pubblicitari.Quali dati di carico sono un indicatore migliore dell'hosting rispetto alle classi di pacchetti pubblicizzate?
Una seconda connessione per "Imposta TLS, HSTS e reindirizzamenti in modo coerente" porta a: Restringere sistematicamente i modelli di errore dopo la migrazione del server. Questo articolo si concentra sulla domanda: "Come isolare sistematicamente gli errori tecnici dopo una migrazione del server? "
Se si desidera implementare in pratica "Configurazione coerente di TLS, HSTS e reindirizzamenti", è possibile fare riferimento a: Sistemi web robusti Questo articolo si concentra su "DNS, TLS e Reverse Proxy" e "TLS completo".
Conclusione: Configurazione coerente di TLS, HSTS e reindirizzamenti
HSTS è l'ultimo passaggio di rinforzo in un'architettura HTTPS funzionante. Il suo ordine e un punto di partenza ridotto limitano gli errori difficili da correggere.
Fonti e ulteriori informazioni
Le seguenti fonti documentano le linee guida tecniche e metodologiche utilizzate per "Configurazione coerente di TLS, HSTS e reindirizzamenti".
RFC 6797: HTTP Strict Transport Security (HSTS)Lo standard IETF definisce il comportamento, l'ambito, la persistenza e i requisiti di sicurezza di HSTS.
Proxy inverso NGINX – Documentazione NGINXLa documentazione ufficiale di NGINX descrive l'inoltro upstream, le intestazioni, il buffering e la configurazione del proxy.
RFC 1034: Nomi di dominio - Concetti e funzionalitàLo standard DNS fondamentale definisce zone, resolver, caching e la semantica della risoluzione distribuita dei nomi.
Tesi chiave
Innanzitutto, il certificato, i nomi host e tutte le risorse funzionano tramite HTTPS; successivamente, viene implementato un singolo reindirizzamento permanente. HSTS inizia con un runtime breve e viene esteso o integrato con sottodomini solo dopo che è stata stabilita una copertura stabile.
Cosa non riguarda
HSTS non deve essere utilizzato per mascherare una configurazione HTTPS incompleta o sottodomini difettosi.
Di cosa si tratta
Il certificato e le risorse HTTPS funzionano prima; poi, viene implementato un singolo reindirizzamento e infine, HSTS viene esteso con cautela.
Hosting, server, CDN e caching.
Configurare Apache e Nginx insieme in modo comprensibile
Come ulteriore fase di test per "configurare TLS, HSTS e reindirizzamenti in modo coerente", la domanda è: come si suddividono le responsabilità tra NGINX e Apache senza duplicare le regole?
Hosting, server, CDN e caching.
Configurare in modo sicuro i reverse proxy per i servizi interni.
Integrando la decisione "Impostazione coerente di TLS, HSTS e reindirizzamenti" con una scelta separata: Quali limiti e intestazioni sono necessari a un proxy inverso sicuro davanti ai servizi interni?
Panoramica degli Insight
Tutti gli Insight di VELUNO in sintesi
Ulteriori analisi sui sistemi web, la visibilità digitale e modelli di lavoro robusti.
Avvio reversibile di HSTS: prossimo punto di controllo
Una matrice host e reindirizzamenti rivela lacune nei certificati e responsabilità sovrapposte. HSTS può quindi essere implementato con un piano di implementazione controllato.