Fatevi un favore e #SupportLetsEncrypt

Non è la prima volta che se ne parla, vale la pena ripeterlo.

La privacy è una cosa importante ed è un diritto inalienabile: HTTPS aiuta a mantenerla nella nostra vita online, un luogo in cui passiamo sempre più tempo e svolgiamo sempre più attività.

Let’s Encrypt è una Certification Authority gratuita, automatica e aperta. Non è di proprietà di nessuna azienda, ma opera nell’ambito della Linux Foundation ed è una organizzazione 501(c)
Il suo scopo è appunto fornire certificati digitali semplici da usare per arrivare a un 100% encrypted web. Leggi tutto “Fatevi un favore e #SupportLetsEncrypt”

Ci risiamo: ecco #DROWNAttack

Sono passati dodici mesi da quando il cosiddetto FREAK Attack ha scatenato il panico su internet: oggi parliamo di un altro rischio nella sicurezza di portata simile.

Si chiama DROWNAttack, ovvero Decrypting RSA with Obsolete and Weakened eNcryption, è un attacco che sfrutta una debolezza nella versione 2 del protocollo SSL. Questa debolezza non è frutto di un errore, ma di una scelta progettuale dovuta alle restrizioni esistenti negli anni ’90 sulla esportazione di tecnologie crittografiche dagli USA verso l’estero. La storia di come queste restrizioni siano state concepite e di quale danno abbiano provocato dovrebbe essere già noto a tutti, segnalo comunque al lettore interessato la esaustiva pagina su Wikipedia.

Il funzionamento di DROWN è spiegato in questo documento tecnico completo, tuttavia riassumeremo qui di seguito il suo modus operandi a grandi linee. Leggi tutto “Ci risiamo: ecco #DROWNAttack”

TLS logjam

Un gruppo di ricercatori ha pubblicato l’articolo Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice [PDF] spiegato in termini non accademici in un sito apposito.

La pubblicazione illustra una vulnerabilità del protocollo TLS, utilizzato anche da HTTPS. Il metodo è molto simile a quello utilizzato per FREAK: un attacco di tipo MitM forza la connessione tra client e server ad un livello di sicurezza molto basso e, quindi, decodificabile. Il tutto grazie ad un retaggio della Guerra Fredda. Leggi tutto “TLS logjam”

Siamo in https

Era ora!

Finalmente quel fannullone di Luigi si è deciso a fare i cambiamenti strutturali del caso che hanno permesso al sito di passare in https senza problemi (forse).

È attivo un redirect da http a https per non rompere i link, se ci sono problemi scrivete nei commenti di questo articolo, sulla pagina Facebook oppure via mail.

Risolvere gli errori delle CA intermedie

Sempre più siti adottano certificati validati dalla PKI, grazie anche a fornitori molto convenienti.

Alcuni certificati acquistati necessitano di una serie di CA oppure di certificati intermedi affinché il client li possa verificare correttamente.

Esistono tool online come quello di SSL Hopper che permettono di verificare se il server dichiara correttamente la catena di certificati che validano quello che si sta utilizzando. Leggi tutto “Risolvere gli errori delle CA intermedie”

SNI su Apache 2.4

L’adozione di https sta diventando sempre più importante per la tutela della privacy degli utenti e per la sicurezza delle comunicazioni.

Uno dei fattori che più hanno limitato la diffusione di questo protocollo risiede nella caratteristica della sessione TLS che, fino a poco tempo fa obbligava ad avere un solo certificato PKI per una coppia IP:porta. Leggi tutto “SNI su Apache 2.4”

Microsoft Secure Channel

Con l’aggiornamento del patch tuesday di questo mese Microsoft corregge un problema di sicurezza molto serio di Secure Channel (Schannel), la sua libreria per la connessione sicura.

Schannel è per Microsoft quello che per l’open source si chiama OpenSSL e per Apple si chiama Secure Transport. In sostanza è quella serie di routine (libreria) che permette di stabilire connessioni sicure in HTTPS o TLS. Con l’annuncio della vulnerabilità di Schannel si può affermare che quest’anno ciascuna delle maggiori librerie HTTPS/TLS ha avuto dei problemi, con buona pace di chi crede di essere al sicuro per il fatto stesso di utilizzare una piattaforma piuttosto che un’altra.

Schannel è utilizzato dai client e dai server che stabiliscono o accettano connessioni sicure utilizzando le funzioni di sistema di Microsoft.

La vulnerabilità segnalata e corretta da Microsoft permette di eseguire codice arbitrario da remoto. In altre parole, un attaccante potrebbe eseguire dei programmi che vuole lui su un computer che utilizza Scannel per collegarsi ad un altro computer. I primi (ma non di certo gli unici) membri di questo insieme sono tutti i Windows che hanno un Internet Information Server esposto a Internet con HTTPS abilitato. A titolo di pro memoria, Exchange Server utilizza HTTPS per far connettere i client mobili. Leggi tutto “Microsoft Secure Channel”

POODLE

POODLE (Padding Oracle On Downgraded Legacy Encryption) è un tipo di attacco alle connessioni https in grado di rubare informazioni sensibili, incluse, teoricamente, le password degli account.

L’attacco si basa su una vulnerabilità di SSLv3, RFC6101, un protocollo del novembre 1996 poco sicuro che fa parte del gruppo di protocolli di scambio dati previsti da https e da tutti i protocolli che usano TLS, come IMAPS, POP3S, SMTP con STARTTLS, eccetera.

Quando viene iniziata una connessione TLS client e server confrontano i protocolli supportati e negoziano il più sicuro tra quelli supportati da entrambi. Tuttavia è anche possibile che un attaccante in grado di disturbare la connessione tra client e server riesca a forzare usa sessione con il protocollo meno sicuro. Leggi tutto “POODLE”

Revoca dei certificati

Heartbleed ha provocato una valanga di revoche di certificati che durerà ancora per qualche tempo.

Il metodo più vecchio per verificare se un certificato è stato revocato è la Certificate Revocation List (RFC3280). In tempi più recenti viene utilizzato l’Online Certificate Status Protocol (RFC6960), che si basa su http (senza rendere obbligatoria la cifratura dei dati) ed evita al client di dover decodificare un certificato di revoca.

La verifica online di un certificato in molti contesti è il sistema migliore, specialmente in situazioni come quella creata da Heartbleed in cui i certificati vengono revocati velocemente a causa della compromissione di quelli vecchi. Tuttavia questo metodo non è esente da problemi, in quanto il server che gestisce le revoche potrebbe essere non raggiungibile oppure il browser potrebbe essere tratto in inganno ed utilizzare un server configurato ad arte. Leggi tutto “Revoca dei certificati”

Heartbleed e la PA italiana

by heartbleed.comHeartbleed ha decisamente rubato la scena al fine del supporto di Windows XP.

Secondo le analisi, non solo metterebbe a rischio i server, ma anche i client; nel dubbio, meglio cambiare le password e, se possibile, riemettere i certificati SSL/TLS.

Dal momento che Siamo geek ha un database (scaricabile) dei siti della pubblica amministrazione italiana utilizzato per fare delle statistiche settimanali, ho pensato di utilizzarlo per vedere quanti server utilizzati PA sono vulnerabili.

Queste sono le metodologie e i risultati. Leggi tutto “Heartbleed e la PA italiana”

Heartbleed

by heartbleed.comHeartbleed è il nome di una vulnerabilità molto seria scoperta sulla libreria OpenSSL dalla versione 1.0.1 alla 1.0.1f incluse.

OpenSSL è utilizzata per il traffico https da molti software, tra cui Apache e nginx che da soli costituiscono il 66% dei server web, anche se bisogna rilevare che non tutti i server web hanno https abilitato.

Microsoft Internet Information Server non è interessato da questo problema.

I prodotti Apple non sono interessati dal problema, con l’eccezione dell’AirPort per cui è disponibile un aggiornamento.

Tutto è cominciato nel 2012 con la release di OpenSSL 1.0.1 che introduce il supporto di RFC6520 e implementa l’heartbeat sulle connessioni TLS. Questa funzione serve a mantenere il canale aperto e impedire, quindi, che client e server debbano rinegoziare la connessione in caso di temporanea inattività. L’espediente dell’heartbeat o keep-alive è utilizzato in molti contesti in cui si invia un pacchetto dati senza informazioni con il solo scopo di resettare eventuali contatori di inattività.

Il problema di OpenSSL è che una riposta al’heartbeat modificata ad arte può rivelare all’attaccante informazioni di vario tipo. Non è possibile utilizzare questa vulnerabilità per eseguire codice sul server remoto, ma questo non è certo un fattore mitigante, vediamo perché. Leggi tutto “Heartbleed”

Perfect Forward Secrecy

Il protocollo HTTPS come è implementato da molti siti o browser ha un problema con il futuro.

Ipotizzando che qualcuno stia registrando tutto il traffico HTTPS di un sito adesso potrebbe solamente avere in mano dei dati illeggibili. Ma cosa succederebbe se venisse trafugata la chiave segreta, oppure se un domani i computer riuscissero in poche settimane a scardinare la chiave utilizzata?

C’è un passaggio fondamentale nei primi millisecondi del protocollo HTTPS:

Il browser, verificato il certificato, invia un messaggio al server che contiene un altro numero casuale cifrato con la chiave pubblica del server

Quindi, chi riuscisse a calcolare o trafugare la chiave privata del server potrebbe decifrare tutto il traffico HTTPS protetto con quella coppia di chiavi, ipoteticamente salvato negli anni, che fino a quel momento non era decifrabile (retrospective decryption).

Lo scambio di una chiave segreta condivisa su un canale non sicuro è un problema non nuovo. Whitfield DiffieMartin Hellman e Ralph Merkle avevano trovato una soluzione già negli anni ’70 del secolo scorso elaborando quello che poi sarebbe diventato il protocollo Diffie-Hellman per lo scambio di chiavi (brevetto US4200770 ora scaduto).

Anche in questo caso bisogna fare un passo indietro per vedere come funzionano le cose dietro le quinte.

Leggi tutto “Perfect Forward Secrecy”

La chiave di volta della sicurezza HTTPS

LachaniaMolti 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.

Una sequenza di 2048 bit (256 byte) che può essere trafugata in mille modi. Negli anni aziende come RSA, Sony e Intel hanno provato sulle loro corna cosa vuol dire la compromissione di una chiave privata.

Se la chiave privata di siti come Google, Facebook, Wikipedia o Twitter finisse nelle mani sbagliate, la S in fondo ad HTTP sarebbe solo un sovraccarico di calcolo per server e client perché la sessione iniziale di sicurezza di HTTP non sarebbe più così sicura.

Immaginiamo quanti server esposti a Internet possano avere i grossi fornitori di servizi; ciascuno di questi server deve per forza avere accesso a quei 256 byte della chiave privata per poter cifrare le comunicazioni. Basta che uno solo di questi server sia compromesso e quella chiave diventerebbe tutt’altro che privata. Leggi tutto “La chiave di volta della sicurezza HTTPS”

HTTPS: come funziona?

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.

Leggi tutto “HTTPS: come funziona?”

Wikipedia passa in HTTPS

wikihttpsA 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]

Certificato SSL: perché no?

Lucchetto con combinazione a forma di maiale / Pig shaped combination padlockI 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.

Quando si vuole certificare un servizio che gira da solo su un host con un singolo nome come alternativa al certificato auto emesso questi certificati sono l’ideale.

Leggi tutto “Certificato SSL: perché no?”

Certificato SSL per un mail server Linux

Lucchetto / PadlockAvendo 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.

Innanzi tutto verificare che il firewall lasci passare 443/tcp, 993/tcp e 995/tcp; SMTPS può essere utilizzato nella medesima porta di SMTP.

Leggi tutto “Certificato SSL per un mail server Linux”

Un https migliore

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.

Leggi tutto “Un https migliore”

Crackato il protocollo di Siri

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.

Leggi tutto “Crackato il protocollo di Siri”

LittleBlackBox

Torre / TowerAlcuni 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)