Confonde gli intermediari malintenzionati con HTTPS e HTTP Strict Transport Security

Data la quantità di dati personali che fluiscono attraverso la grande serie di tube di internet, la crittografia non è qualcosa che possiamo o dobbiamo ignorare. I browser moderni offrono diversi meccanismi che puoi utilizzare per garantire che i dati degli utenti siano protetti durante il transito. I cookie sicuri e Strict Transport Security sono due degli aspetti più importanti. Consentono di proteggere gli utenti senza interruzioni, eseguire l'upgrade delle loro connessioni a HTTPS e garantire che i dati utente non vengano mai inviati in modo chiaro.

Perché dovrebbe interessarti? Considera questo aspetto:

Pubblicare una pagina web tramite una connessione HTTP non crittografata è più o meno come dare una busta non sigillata alla prima persona che vedi per strada, che sembra che stia camminando nella direzione dell'ufficio postale. Se sei fortunato, potrebbe portarlo lì fino in fondo oppure passarlo alla persona successiva che vede chi sta seguendo la strada giusta. Potrebbe fare lo stesso, e così via.

La maggior parte degli sconosciuti in questa catena improvvisata è affidabile e non sbircierebbe mai la tua lettera aperta né la modificherebbe. Tuttavia, più volte la lettera passa di mano, maggiore è il numero di persone che hanno accesso completo alla lettera che stai inviando. Alla fine, è molto probabile che il destinatario previsto della lettera ricevi qualcosa per posta, ma se si tratta di qualcosa uguale avete ricevuto inizialmente qualcosa, c'è una domanda aperta. Forse dovresti sigilare quella busta...

Intermediari

Nel bene e nel male, vaste aree di internet fanno affidamento sull'affidabilità degli estranei. I server non sono collegati direttamente l'uno all'altro, ma passano richieste e risposte insieme da router a router in un enorme gioco di telefoni.

Puoi vedere questi hop in azione con il trackroute. Il percorso dal mio computer a HTML5Rocks è simile al seguente:

$ traceroute html5rocks.com
traceroute to html5rocks.com (173.194.71.102), 30 hops max, 60 byte packets
 1  router1-lon.linode.com (212.111.33.229)  0.453 ms
 2  212.111.33.233 (212.111.33.233)  1.067 ms
 3  217.20.44.194 (217.20.44.194)  0.704 ms
 4  google1.lonap.net (193.203.5.136)  0.804 ms
 5  209.85.255.76 (209.85.255.76)  0.925 ms
 6  209.85.253.94 (209.85.253.94)  1.226 ms
 7  209.85.240.28 (209.85.240.28)  48.714 ms
 8  216.239.47.12 (216.239.47.12)  22.575 ms
 9  209.85.241.193 (209.85.241.193)  36.033 ms
10  72.14.233.180 (72.14.233.180)  43.222 ms
11  72.14.233.170 (72.14.233.170)  43.242 ms
12  *
13  lb-in-f102.1e100.net (173.194.71.102)  44.523 ms

13 passaggi non sono un male, davvero. Tuttavia, se invio le richieste tramite HTTP, ognuno di questi router intermedi ha accesso completo alle mie richieste e alle risposte dei server. Tutti i dati vengono trasferiti come testo non criptato non criptato e uno qualsiasi di questi intermediari potrebbe agire come un uomo al centro, leggere i miei dati o persino manipolarli in transito.

Peggio ancora, questo tipo di intercettazione è praticamente impercettibile. Una risposta HTTP modificata in modo dannoso sembra esattamente una risposta valida, poiché non esiste nessun meccanismo che ti consenta di garantire che i dati ricevuti siano esattamente i dati inviati. Se qualcuno decide di stravolgere la mia connessione a internet per ridere, sono più o meno sfortunata.

È una linea protetta?

Il passaggio da HTTP in testo non crittografato a una connessione HTTPS protetta offre la migliore difesa contro gli intermediari. Le connessioni HTTPS criptano l'intero canale end-to-end prima che vengano inviati i dati, impedendo alle macchine tra te e la destinazione di leggere o modificare i dati in transito.

La omnibox di Chrome fornisce alcuni dettagli sullo stato di una connessione.
La omnibox di Chrome fornisce alcuni dettagli sullo stato di una connessione.

La sicurezza offerta da HTTPS è radicata nel concetto di chiavi di crittografia pubbliche e private. Una discussione approfondita dei dettagli va (fortunatamente) ben oltre l'ambito di questo articolo, ma la premessa principale è piuttosto semplice: i dati criptati con una determinata chiave pubblica possono essere decriptati solo con la chiave privata corrispondente. Quando un browser avvia un handshake HTTPS per creare un canale sicuro, il server fornisce un certificato che fornisce al browser tutte le informazioni necessarie per verificarne l'identità controllando che il server sia in possesso della chiave privata appropriata. Tutte le comunicazioni da quel punto in poi sono criptate in modo da dimostrare che le richieste e le risposte vengono ricevute dal server autenticato.

HTTPS, pertanto, ti dà la certezza che stai comunicando con il server con cui pensi di comunicare e che nessun altro sta ascoltando o ruotando i bit sulla rete. Questo tipo di crittografia è un prerequisito assoluto per la sicurezza sul web; se l'applicazione al momento non viene distribuita tramite HTTPS, è vulnerabile agli attacchi. Correggi l'errore. Ars Technica ha un'ottima guida per ottenere e installare un certificato (senza costi) che ti consiglio di dare un'occhiata per i dettagli tecnici. La configurazione varia da provider a provider e da server a server, ma il processo di richiesta di certificato è lo stesso ovunque.

Sicurezza innanzitutto

Dopo aver richiesto e installato un certificato, assicurati che i tuoi utenti traggano vantaggio dal tuo lavoro: esegui la migrazione degli utenti esistenti alle connessioni HTTPS in modo trasparente tramite la magia del reindirizzamento HTTP e assicurati che i cookie vengano pubblicati solo tramite connessioni sicure.

In questo modo, per favore

Quando un utente visita http://example.com/, reindirizzalo a https://example.com/ inviando una risposta 301 Moved Permanently con un'intestazione Location appropriata:

$ curl -I http://mkw.st/
HTTP/1.1 301 Moved Permanently
Server: nginx/1.3.7
...
Keep-Alive: timeout=20
Location: https://mkw.st/

Puoi configurare facilmente questo tipo di reindirizzamento in server come Apache o Nginx. Ad esempio, una configurazione Nginx che reindirizza da http://example.com/ a https://example.com/ ha il seguente aspetto:

server {
    listen [YOUR IP ADDRESS HERE]:80;
    server_name example.com www.example.com;
    location "/" {
        rewrite ^(.*) https://www.example.com$1 permanent;
    }
}

I cookie ci consentono di offrire agli utenti esperienze di accesso senza interruzioni tramite il protocollo HTTP stateless. I dati memorizzati nei cookie, incluse informazioni sensibili come gli ID sessione, vengono inviati insieme a ogni richiesta, consentendo al server di capire a quale utente sta rispondendo in quel momento. Dopo avere verificato che gli utenti raggiungano il nostro sito tramite HTTPS, dobbiamo anche fare in modo che i dati sensibili memorizzati nei cookie vengano trasferiti solo tramite una connessione sicura e non vengano mai inviati in chiaro.

L'impostazione di un cookie in genere prevede un'intestazione HTTP simile alla seguente:

set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT

Puoi indicare al browser di limitare l'utilizzo dei cookie alle sessioni sicure assegnando una singola parola chiave:

Set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT; secure

I cookie impostati con la parola chiave secure non verranno inviati tramite HTTP.

Chiusura della finestra aperta

Il reindirizzamento trasparente a HTTPS indica che nella maggior parte del tempo gli utenti si trovano sul tuo sito, utilizzeranno una connessione sicura. Tuttavia, lascia una piccola finestra di opportunità di attacco: la connessione HTTP iniziale è completamente aperta, vulnerabile allo striping SSL e agli attacchi correlati. Dato che un uomo al centro ha accesso completo alla richiesta HTTP iniziale, può fungere da proxy tra te e il server e mantenere una connessione HTTP non sicura indipendentemente dalle intenzioni del server.

Puoi ridurre il rischio di questa classe di attacchi chiedendo al browser di applicare HTTP Strict Transport Security (HSTS). L'invio dell'intestazione HTTP Strict-Transport-Security indica al browser di eseguire il reindirizzamento da HTTP a HTTPS lato client, senza mai contattare la rete (questo è anche ideale per le prestazioni; la richiesta migliore è quella che non devi fare):

$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000

I browser che supportano questa intestazione (attualmente Firefox, Chrome e Opera: caniuse contiene dettagli) noteranno che il sito in questione ha richiesto l'accesso solo HTTPS, il che significa che, indipendentemente dal modo in cui un utente arriva al sito, lo visiterà tramite HTTPS. Anche se digita http://example.com/ nel browser, finirà su HTTPS senza mai stabilire una connessione HTTP. Meglio ancora, se il browser rileva un certificato non valido (che potrebbe tentare di falsificare l'identità del server), gli utenti non potranno continuare tramite HTTP; è tutto o niente, il che è eccellente.

Lo stato HSTS del server scadrà dopo max-age secondi (in questo esempio circa un mese); imposta questo stato su un valore ragionevolmente alto.

Puoi anche assicurarti che tutti i sottodomini di un'origine siano protetti aggiungendo l'istruzione includeSubDomains all'intestazione:

$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000

Vai avanti in sicurezza

HTTPS è l'unico modo per essere anche da remoto che i dati inviati raggiungano il destinatario previsto e intatti. Devi configurare connessioni sicure per i tuoi siti e le tue applicazioni oggi stesso. È abbastanza semplice e ti aiuterà a proteggere i dati dei tuoi clienti. Una volta ottenuto un canale criptato, dovresti reindirizzare in modo trasparente gli utenti a questa connessione sicura, indipendentemente dal modo in cui arrivano al tuo sito, inviando una risposta HTTP 301. Dopodiché assicurati che le informazioni sensibili di tutti i tuoi utenti sulle sessioni utilizzino solo la connessione sicura aggiungendo la parola chiave secure quando imposti i cookie. Dopo aver fatto tutto questo, assicurati che i tuoi utenti non calino mai accidentalmente dal bus: proteggili assicurandoti che il loro browser faccia la cosa giusta inviando un'intestazione Strict-Transport-Security.

La configurazione di HTTPS non è molto complessa e porta grandi vantaggi per il tuo sito e i suoi utenti. Ne vale davvero la pena.

Risorse

  • StartSSL offre certificati senza costi con dominio verificato. Non c'è niente di meglio. Aumentare il livello di verifica è, ovviamente, sia possibile che a un prezzo ragionevole.
  • Test server SSL: una volta configurato HTTPS per i tuoi server, verifica che l'operazione sia stata eseguita correttamente mediante il test dei server dei lab SSL. Verrà visualizzato un report ben dettagliato che indica se il tuo account è operativo.
  • Ti consigliamo di leggere il recente articolo di Ars Technica "Protezione del server web con SSL/TLS" per ottenere ulteriori informazioni di base sulla configurazione di un server.
  • Ti consigliamo di leggere la specifica HTTP Strict Transport Security (RFC6797) per consultare tutte le informazioni tecniche sull'intestazione Strict-Transport-Security che potresti volere.
  • Una volta che sai bene cosa stai facendo, un passaggio successivo possibile consiste nel pubblicizzare che il tuo sito deve essere raggiungibile solo tramite un insieme specifico di certificati. Alla IETF è in corso un lavoro che ti consentirebbe di farlo tramite l'intestazione Public-Key-Pins; ancora nei primi giorni, ma interessante e che vale la pena seguire.