Google Chrome, revocation list e altre storie intorno a SSL e TLS

Forse Google intende rimuovere il supporto dei protocolli CRL e OCSP per il controllo dei certificati SSL/TLS dalle prossime versioni di Chrome.

Ma prima facciamo un passo indietro…

Che cosa sono e come funzionano SSL e TLS

SSL (Secure Sockets Layer) e TLS (Transport Layer Security) sono dei protocolli crittografici che permettono una comunicazione sicura – da eventuali attacchi come Man in the middle o DNS cache poisoning – tra client e server. (Quando aprite un sito che utilizza TLS, come ad esempio PayPal o Amazon, avrete notato “https://” che precede l’URL e un colore “rassicurante” :D dello sfondo della favicon e/o un’icona a forma di lucchetto: vuol dire che il vostro browser ha stabilito che il sito in questione è affidabile).

Come funziona in breve:
La comunicazione client/server viene protetta tramite crittografia asimmetrica (vengono usate due chiavi – da 128 bit o più -, le informazioni vengono cifrate con una chiave, chimata pubblica e decifrate attraverso la seconda chiave, chiamata “privata”), una Certification Authority, con una firma digitale, associa una la chiave pubblica ad un’identità (in questo caso il server) e rilascia un certificato digitale: ciò che “legge” il nostro browser per dimostrare l’attendibilità del sito.

Lista delle maggiori CA (Certification Authority):
– VeriSign (Facebook, Twitter, Live.com, PayPal, Amazon, Mozilla…)
– DigiCert (Wikipedia, github, torproject.org…)
– Thawte (kernel.org, Google, …)
– Equifax (Yahoo!…)
– StartCom (certificati gratuiti, EFF…)
– GlobalSign (Skype…)
– GoDaddy
– Google
– Comodo
– Diginotar
– GeoTrust
– RSA Security

Storie buffe circa la disattenzione delle CA:
[more]- Thawte

Zusman knows around careless CA practices. In 2008, he applied for an SSL certificate that would reserve him to acquit as the rightful manipulator of Microsoft’s Living.com field, which is utilised to logon to Hotmail and different radiosensitive online services. In active two hours, VeriSign underling Thawte issued the credential with almost no questions asked. Zusman’s flatfish fittingness was his manipulate of the telecommunicate destination sslcertificates@live.com, which was sufficiency to persuade the automatic processes at Thawte that he was canonized to own the papers.

Website Security: Trusting SSL Certificates

In pratica il signor Mike Zusman ha creato un semplice account live.com/Hotmail, ha “chiesto” il certificato di live.com a al CA Thawte e l’ha ottenuto!

Certigna

Sadly, French SSL specialist Certigna appears to have failed to keep its secret under lock and key. A visit to the site’s revocation list page – which is fully publicly accessible via a standard web browser – allows anyone and everyone to download the private key and other supposedly secret files, potentially enabling the creation of their own valid Certigna-signed SSL certificates.

Certigna publishes SSL private key by mistake

Certigna ha lasciato per un bel po’ di tempo delle chiavi private in una cartella FTP accessibile da tutti![/more]

…Tornando a Google Chrome

All the major desktop browsers will contact those services to inquire whether the certificate has been revoked. There are two protocols/formats involved: OCSP and CRL, although the differences aren’t relevant here. I mention them only so that readers can recognise the terms in other discussions.

Adam Langley, developer di Google, annuncia che il protocollo OCSP (sistema per aggiornare la “revocation list” dei certificati non più validi) può rallentare la navigazione ed inoltre non è garantito che le richieste ai server del CA vadano a buon fine.
An attacker who can intercept HTTPS connections can also make online revocation checks appear to fail and so bypass the revocation checks.

Adam perciò propone di implementare nelle prossime versioni di Google Chrome delle revocation list “push”, senza bisogno di aggiornamento/riavvio del browser.

Blog di Adam Langley: ImperialViolet

Convergence: un’alternativa

Una alternativa al sistema TLS/CA/OCSP può essere trovata in Convergence: estensione, in fase beta, per ora esistente solo per Firefox.
Convergence rimuove il concetto di Certification Authority, introducendo il concetto di “vari punti di vista” attraverso dei server detti “Notary”: l’utente (client) ad esempio va sul sito amazon.com (fa una richiesta ad un server), il server gli “mostra” il suo certificato, il client inoltra il certificato ad uno o più notary (in diverse regioni del pianeta) che a sua volta fa una richiesta ad amazon.com e poi confronta i due certificati, se risultano uguali, e così anche per più notary significa che il sito è affidabile.

Certamente questo metodo non rende più veloce la verifica del certificato, ma così si possono evitare attacchi da hacker che posseggono certi certificati originali.

Nelle opzioni di Convergence si può specificare quanti notary interrogare e quando viene considerato autentico il sito: risposta positiva di un solo notary, consenso della maggior parte, di tutti.
Se vi interessa potete scaricarlo qua e consiglio anche l’estensione HTTPS Everywhere (supportato da Tor Project e EFF) che attiva l’https, quando navigate sul web, su ogni sito che lo permette.

Fonti e link utili
| ItProPortal | Video SSL e Cyberwar | Segfault |

Google parla dell'aumento degli attacchi 0-day e di come li combatterà
Google parla dell'aumento degli attacchi 0-day e di come li combatterà
Caccia ai bug: Google ha pagato oltre 21 milioni di euro in 10 anni
Caccia ai bug: Google ha pagato oltre 21 milioni di euro in 10 anni
Un bug critico in PGP e S/MIME permette di leggere i messaggi criptati
Un bug critico in PGP e S/MIME permette di leggere i messaggi criptati
Denial of Service
Denial of Service
Hacklog: Volume 2, il corso di hacking più seguito in Italia ritorna su IndieGogo
Hacklog: Volume 2, il corso di hacking più seguito in Italia ritorna su IndieGogo
Google Prompt, il nuovo sistema di verifica in due passaggi
Google Prompt, il nuovo sistema di verifica in due passaggi
FBI Wants You for a Social Media Application