Considerata la quantità di dati personali che fluisce attraverso la grande serie di tubi che è internet, la crittografia non è qualcosa che possiamo o dovremmo ignorare con leggerezza. 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 dei più importanti. Consentono di proteggere facilmente gli utenti, eseguendo l'upgrade delle loro connessioni a HTTPS e garantendo che i dati utente non vengano mai inviati in chiaro.
Perché dovrebbe interessarti? Considera questo:
Pubblicare una pagina web tramite una connessione HTTP non criptata equivale più o meno a consegnare una busta aperta alla prima persona che vedi per strada che sembra camminare in direzione dell'ufficio postale. Se sei fortunato, potrebbe portarla direttamente a destinazione o consegnarla alla prima persona che incontra che sta andando nella direzione giusta. Questa persona potrebbe fare lo stesso e così via.
La maggior parte degli sconosciuti in questa catena improvvisata è affidabile e non sbircerebbe mai la tua lettera aperta né la altererebbe. Tuttavia, più volte la lettera passa di mano, maggiore è il numero di persone con accesso completo alla lettera che stai inviando. Alla fine, è molto probabile che il destinatario della tua lettera riceva qualcosa per posta, ma se quel qualcosa è lo stesso che hai consegnato tu è una questione aperta. Forse avresti dovuto sigillare quella busta…
Intermediari
Nel bene o nel male, gran parte di internet si basa sull'affidabilità di sconosciuti. I server non sono collegati direttamente tra loro, ma trasmettono richieste e risposte da un router all'altro in un enorme gioco del telefono.
Puoi vedere questi hop in azione con traceroute. 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 hop non è male, in realtà. Tuttavia, se invio 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 e uno qualsiasi di questi intermediari potrebbe agire come Man in the Middle, leggendo i miei dati o addirittura manipolandoli durante il transito.
Inoltre, questo tipo di intercettazione è praticamente impossibile da rilevare. Una risposta HTTP modificata in modo dannoso ha l'aspetto di una risposta valida, poiché non esiste alcun meccanismo che consenta di garantire che i dati ricevuti siano _esattamente_ quelli inviati. Se qualcuno decide di stravolgere la mia connessione internet per divertimento, non ho molte opzioni.
Questa linea è sicura?
Il passaggio da HTTP con testo non crittografato a una connessione HTTPS sicura offre la migliore difesa contro gli intermediari. Le connessioni HTTPS criptano l'intero canale end-to-end prima che vengano inviati i dati, rendendo impossibile per le macchine tra te e la tua destinazione leggere o modificare i dati in transito.
La sicurezza offerta da HTTPS si basa sul concetto di chiavi di crittografia pubbliche e private. Una discussione approfondita dei dettagli va (fortunatamente) ben oltre lo scopo di questo articolo, ma la premessa di base è abbastanza 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 verificare la sua identità controllando che il server sia in possesso della chiave privata corretta. Tutte le comunicazioni da quel momento in poi vengono crittografate in modo tale da dimostrare che le richieste vengono inviate al server di autenticazione e le risposte vengono ricevute da quest'ultimo.
HTTPS, quindi, ti dà la certezza di comunicare con il server con cui pensi di comunicare e che nessun altro stia ascoltando o modificando i bit in transito. Questo tipo di crittografia è un prerequisito assoluto per la sicurezza sul web; se la tua applicazione non viene attualmente pubblicata 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 consultare per i dettagli tecnici. La configurazione varia da provider a provider e da server a server, ma la procedura di richiesta del certificato è la stessa ovunque.
Sicuro di default
Dopo aver richiesto e installato un certificato, assicurati che i tuoi utenti traggano vantaggio dal tuo duro 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 inviati solo tramite connessioni sicure.
Da questa parte, prego
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;
}
}
Blocca il barattolo dei cookie
I cookie ci consentono di offrire agli utenti esperienze di accesso senza interruzioni tramite il protocollo HTTP stateless. I dati memorizzati nei cookie, incluse le informazioni sensibili come gli ID sessione, vengono inviati con ogni richiesta, consentendo al server di capire a quale utente sta rispondendo in quel momento. Una volta che abbiamo verificato che gli utenti accedono al nostro sito tramite HTTPS, dobbiamo anche assicurarci 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 del cookie alle sessioni protette aggiungendo 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 mai inviati tramite HTTP.
Chiusura della finestra aperta
Il reindirizzamento trasparente a HTTPS significa che la stragrande maggioranza delle volte in cui gli utenti si trovano sul tuo sito, utilizzeranno una connessione sicura. Tuttavia, lascia una piccola finestra di opportunità per gli attacchi: la connessione HTTP iniziale è completamente aperta, vulnerabile allo SSL stripping e ad attacchi correlati. Dato che un man-in-the-middle ha accesso completo alla richiesta HTTP iniziale, può agire come proxy tra te e il server, mantenendoti su una connessione HTTP non sicura indipendentemente dalle intenzioni del server.
Puoi mitigare il rischio di questo tipo di attacco 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 toccare la rete (questo è anche ottimo 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 ha i dettagli) prenderanno nota del fatto che questo sito specifico ha richiesto l'accesso solo tramite HTTPS, il che significa che, indipendentemente da come 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. Inoltre, se il browser rileva un certificato non valido (che potrebbe tentare di falsificare l'identità del tuo server), gli utenti non potranno continuare tramite HTTP; è tutto o niente, il che è ottimo.
Il browser farà scadere lo stato HSTS del server dopo max-age secondi
(circa un mese in questo esempio); imposta un valore ragionevolmente alto.
Puoi anche assicurarti che tutti i sottodomini di un'origine siano protetti aggiungendo
la direttiva 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 ragionevolmente certi che i dati inviati raggiungano il destinatario previsto senza subire alterazioni. Dovresti configurare connessioni sicure per i tuoi siti e le tue applicazioni oggi stesso. È una procedura piuttosto semplice e ti aiuterà a proteggere i dati dei tuoi clienti. Una volta creato un canale criptato, devi reindirizzare in modo trasparente gli utenti a questa connessione sicura, indipendentemente da come arrivano al tuo sito, inviando una risposta HTTP 301. Poi, assicurati che tutte le informazioni sensibili sulla sessione degli utenti utilizzino solo quella connessione sicura aggiungendo la parola chiave secure durante l'impostazione dei cookie.
Una volta completati tutti questi passaggi, assicurati che i tuoi utenti non perdano mai accidentalmente l'accesso: proteggili assicurandoti che il loro browser esegua l'azione corretta inviando un'intestazione Strict-Transport-Security.
La configurazione di HTTPS non richiede molto lavoro e offre enormi vantaggi per il tuo sito e i suoi utenti. Vale la pena fare questo sforzo.
Risorse
- StartSSL offre certificati senza costi con dominio verificato. Non c'è niente di meglio di un servizio senza costi. Passare a livelli di verifica più elevati è, ovviamente, possibile e ha un prezzo ragionevole.
- SSL Server Test: dopo aver configurato HTTPS per i tuoi server, verifica di averlo fatto correttamente eseguendo il test del server di SSL Labs. Riceverai un report dettagliato che ti mostrerà se il tuo sito è effettivamente attivo e funzionante.
- Vale la pena leggere il recente articolo di Ars Technica "Securing your Web Server with SSL/TLS" per avere qualche dettaglio in più sugli aspetti pratici della configurazione di un server.
- Vale la pena dare un'occhiata alla specifica HTTP Strict Transport Security (RFC6797) per tutte le informazioni tecniche sull'intestazione
Strict-Transport-Securityche potresti voler conoscere. - Una volta che hai capito bene cosa fare, un possibile passaggio successivo potrebbe essere quello di pubblicizzare che il tuo sito deve essere raggiungibile solo tramite un insieme specifico di certificati. È in corso un lavoro presso l'IETF che ti consentirebbe di farlo tramite l'intestazione
Public-Key-Pins; è ancora presto, ma è interessante e vale la pena seguirlo.