Molti siti popolari stanno passando per default alle comunicazioni via HTTPS.
Se per un sito ospitato su un solo server dedicato è un’operazione banale, Per una grossa organizzazione non è un’impresa semplice.
Passare in HTTPS non risolve ogni problema di sicurezza sia perché è un protocollo soggetto ad attacchi (qui e qui) sia perché esiste comunque un single point of failure.
La chiave privata.
(altro…)Abbastanza bene, ma non è una bacchetta magica.
Prima di spiegare HTTPS è necessario spiegare cosa sia la Public Key Infrastructure (PKI) e prima ancora la crittografia asimmetrica, il vero mattone con cui è costruito tutto quanto: se qualcuno scoprisse come crackare velocemente una cifratura asimmetrica verrebbe giù tutto o peggio.
I sistemi di crittografia più noti sono simmetrici, ovvero quelli che richiedono una chiave, la stessa, per cifrare e decifrare un testo: dal cifrario di Cesare a Enigma era questo il modo di nascondere le informazioni fino a qualche decennio fa.
A partire da oggi Wikipedia utilizza HTTPS per il login degli utenti e mantiene il protocollo crittografato per il resto degli accessi al sito.
Questa decisione, già parte del percorso di tutela della sicurezza, è stata anticipata alla luce dei recenti eventi legati alle rivelazioni di Edward Snowden secondo le quali Wikipedia sarebbe stata uno dei metodi per tracciare le persone poste sotto sorveglianza.
Per il momento HTTPS non viene attivato sulle versioni di Wikipedia di Paesi che scoraggiano o vietano quel protocollo: cinese (zh.*), fārsì (fa.*), gilaki (glk.*), curdo (ku.*), mazanderani (mzn.*) e soranî (ckb.*). In seguito la decisione di utilizzare o meno HTTPS sarà basata sulla geolocalizzazione dell’indirizzo IP dell’utente che visita Wikipedia.
Ovviamente HTTPS non garantisce l’anonimato né la riservatezza assoluti di ciò che si sta visitando, ma contribuisce, in generale, a ridurre i rischi di furto di informazioni riservate. Esistono firewall normalmente acquistabili su cui si possono abilitare dei veri e propri attacchi di man-in-the-middle per poter analizzare le pagine visitate e confrontarle con le policy impostate. [via Wikimedia Meta]
I certificati SSL sono oramai disponibili anche a prezzi assai abbordabili.
Da NameCheap (uso quel fornitore come esempio, ma si trovano anche altrove) si possono prendere i Comodo a 7,95 dollari/anno o i GeoTrust a 9,49 dollari/anno. Con questi prezzi la domanda da porsi è se abbia ancora senso usare dei certificati auto emessi.
Ci sono situazioni in cui i certificati di questo tipo non possono essere utilizzati. Ad esempio, se si vuole certificare non un host, ma tutti gli host di un intero dominio si sale di prezzo di un ordine di grandezza.
(altro…)Avendo trasferito i miei domini presso NameCheap a causa dell’affaire GoDaddy e SOPA ho acquistato per l’astronomica cifra di due dollari un certificato SSL.
Qui di seguito la procedura che ho utilizzato per usare il certificato con Apache (rpm), Dovecot (compilato) e Postfix (compilato) su una CentOS 5.x.
Questa procedura non sostituisce il manuale, ma serve solamente come guida di massima. Familiarizzare con le opzioni relative a SSL dei vari programmi prima di procedere. In alcune situazioni potrebbe essere necessario utilizzare ulteriori parametri oltre a quelli indicati.
(altro…)Tutti sappiamo che il protocollo https permette ad Alice e Bob di scambiarsi messaggi senza che Charlie, costantemente in ascolto sulla linea, li legga.
Ogni browser utilizza degli espedienti grafici per indicare che la connessione in corso non è facilmente intercettabile e leggibile.
Ma c’è un tipo di https che offre una sicurezza maggiore rispetto ad un altro e, per ora, i browser non hanno sistemi di avviso immediatamente riconoscibili per informare l’utente in merito.
Innanzi tutto, una carrellata su come funziona il protocollo https. I due attori in gioco (Alice e Bob) sono il client (browser dell’utente) e il server. Lo scopo è fare in modo che Charlie non legga i dati che passano in ciascuna delle due direzioni.
A nemmeno un mese dal lancio, la società tedesca fracese Applidium ha crackato il protocollo di Siri.
La metodologia descritta è molto interessante e può essere applicata a casi analoghi.
Siri invia tutti i dati a guzzoni.apple.com utilizzando il trasporto (trasporto, non protocollo, vedremo poi) HTTPS. Il client che risiede su iOS verifica la validità del certificato SSL di guzzoni.apple.com per impedire che il traffico venga dirottato su un altro server tramite DNS poisoning.
Questo non ha però fermato i tecnici di Applidium, che hanno creato un finto host guzzoni.apple.com con un finto certificato SSL emesso e firmato da una finta CA. Il clienti di Siri verifica, infatti, la validità del certificato di guzzoni.apple.com, ma si fida di qualsiasi CA lo garantisca.
Alcuni dispositivi di rete (switch, router e assimilati) hanno un’interfaccia HTTPS con un certificato autofirmato.
LittleBlackBox è un progetto che raccoglie migliaia di certificati SSL di altrettanti dispositivi di rete con alcune utility di gestione e di analisi.
La maggior parte di questi dispositivi, infatti, ha a bordo lo stesso certificato, alcune volte il certificato varia al variare della release del firmware, ma nessuno lo calcola in maniera univoca la prima colta che viene attivato.
Se si possiede un dispositivo le cui chiavi sono presenti nel database di LittleBlackBox è bene tener presente che il traffico crittografato è facilmente decrittabile. (via full-disclosure)
La struttura attuale delle transazioni sicure via web tramite il protocollo https si basa su un’infrastruttura a chiave pubblica con tre gambe: l’utente, il fornitore del servizio e un’autorità di certificazione (CA) riconosciuta dai due.
Quando vediamo un messaggio simile a quello a fianco (i vecchi lupi del web dicevano «quando si chiude il lucchetto aperto di Netscape») sappiamo che i dati viaggiano crittografati da un sistema a chiave pubblica che dovrebbe godere della nostra fiducia.
Ma, come dicevano i nostri antenati, quis custodiet ipsos custodes?