3.2 Strict TLS

3.2 Strict TLS

Le seguenti raccomandazioni sono fornite per aiutare a prevenire lo SSL Stripping (un attacco riassunto nella Sezione 2.1 di [RFC7457]):

• Nei casi in cui un protocollo applicativo consente alle implementazioni o alle distribuzioni una scelta tra configurazione TLS rigorosa e aggiornamento dinamico da traffico non crittografato a traffico protetto da TLS (come STARTTLS), i client e i server DOVREBBERO preferire la configurazione TLS rigorosa.

• I protocolli applicativi tipicamente forniscono un modo per il server di offrire TLS durante uno scambio di protocollo iniziale, e talvolta forniscono anche un modo per il server di pubblicizzare il supporto per TLS (ad esempio, attraverso un flag che indica che TLS è richiesto); sfortunatamente, queste indicazioni sono inviate prima che il canale di comunicazione sia crittografato. Un client DOVREBBE tentare di negoziare TLS anche se queste indicazioni non sono comunicate dal server.

• Le implementazioni client e server HTTP DEVONO supportare l'header HTTP Strict Transport Security (HSTS) [RFC6797], al fine di consentire ai server Web di pubblicizzare che sono disposti ad accettare client solo TLS.

• I server Web DOVREBBERO utilizzare HSTS per indicare che sono disposti ad accettare client solo TLS, a meno che non siano distribuiti in modo tale che l'utilizzo di HSTS indebolisca effettivamente la sicurezza complessiva (ad esempio, può essere problematico utilizzare HSTS con certificati autofirmati, come descritto nella Sezione 11.3 di [RFC6797]).

Motivazione: La combinazione di comunicazioni non protette e protette da TLS apre la strada allo SSL Stripping e ad attacchi simili, poiché una parte iniziale della comunicazione non è protetta dall'integrità e quindi può essere manipolata da un attaccante il cui obiettivo è mantenere la comunicazione in chiaro.