24 novembre 2011

[Security] Protezione nel tempo delle connessioni HTTPS

Google introduce una nuova interessantissima funzione legata alla sicurezza dei sistemi di autenticazione legati ai suoi prodotti.
Già nel 2010 Google aveva introdotto il protocollo HTTPS di default per Gmail e la ricerca in Google Search in forma criptata.
Questa è la volta di Forward Secrecy.

Forward Secrecy o Perfect Forward Secrecy è un concetto molto interessante ed intrigate che si occupa della protezione in prospettiva futura dei processi di autenticazione basati su chiavi pubbliche  o private, basati cioè più generalmente sulla crittografia asimmetrica.
Forward Secrecy è un metodo, o una proprietà, di HTTPS che ha lo scopo di evitare il rischio della decrittazione retrospettiva.
Per spiegare il concetto di Forward Secrecy, il team di Google Security utilizza un semplice esempio basato su un client di posta.
Immaginiamo di ricevere oggi un messaggio email attraverso protocollo crittografato HTTPS e quindi inaccessibile ai non destinatari della stessa. Un estraneo alla conversazione potrebbe però riuscire a copiare questa email durante il processo di transito tra mittente e destinatario. Attualmente non sarebbe però in grado di decifrarla.
Tuttavia è logico pensare che in un futuro prossimo, per esempio da qui a dieci anni, l’attaccante possa avere le risorse per decifrare il messaggio grazie ad esempio all’incremento della tecnologia e, in particolare, della velocità di calcolo delle macchine del futuro.
E qui entra in gioco Forward Secrecy.
Questo metodo implica che le chiavi private relative ad un’autenticazione non siano archiviate in un luogo persistente nel tempo. Un avversario quindi che nel futuro dovesse riuscire ad infrangere una singola chiave, non sarebbe comunque in grado di decifrare le sessioni HTTPS passate. Nemmeno il gestore del server sarebbe in grado di decifrare retrospettivamente le sessioni HTTPS.
Forward Secrecy è ora abilitato di default in Gmail ed altri servizi di Google, come la Ricerca SSL, Docs e Google+. Google ha inoltre rilasciato il lavoro come Open Source nella libreria OpenSSL su cui si basa questa implementazione.
Per verificare se questa funzione è attiva è sufficiente cliccare sul simbolo del lucchetto verde presente nella barra degli indirizzi dei siti HTTPS.


Il meccanismo di scambio di chiavi dell’implementazione di Forward Secrecy da parte di Google si basa su ECDHE_RSA (Ephemeral Elliptic Curve Diffie-Hellman Cryptography with RSA signatures):

Descrizione estratta dal memo Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) del Network Working Group
[OMISSIS]
                     Table 2: ECC Key Exchange Algorithms
   The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward
   secrecy.  With ECDHE_RSA, a server can reuse its existing RSA
   certificate and easily comply with a constrained client's elliptic
   curve preferences (see Section 4).  However, the computational cost
   incurred by a server is higher for ECDHE_RSA than for the traditional
   RSA key exchange, which does not provide forward secrecy.
   The ECDH_RSA mechanism requires a server to acquire an ECC
   certificate, but the certificate issuer can still use an existing RSA
   key for signing.  This eliminates the need to update the keys of
   trusted certification authorities accepted by TLS clients.  The
   ECDH_ECDSA mechanism requires ECC keys for the server as well as the
   certification authority and is best suited for constrained devices
   unable to support RSA.
   The anonymous key exchange algorithm does not provide authentication
   of the server or the client.  Like other anonymous TLS key exchanges,
   it is subject to man-in-the-middle attacks.  Implementations of this
   algorithm SHOULD provide authentication by other means.
   Note that there is no structural difference between ECDH and ECDSA
   keys.  A certificate issuer may use X.509 v3 keyUsage and
   extendedKeyUsage extensions to restrict the use of an ECC public key
   to certain computations [15].  This document refers to an ECC key as
   ECDH-capable if its use in ECDH is permitted.  ECDSA-capable is
   defined similarly.
Questa nuova funzione rappresenta un interessante passo in avanti nella sicurezza delle comunicazioni importanti via web.
Nota: tutte le versioni di Chrome e Firefox e le ultime versioni di Internet Explorer (a partire da Vista) supportano la Forward Secrecy attraverso la elliptic curve Diffie-Hellman. Tuttavia i servizi Google la implementano solo su Chrome e Firefox in quanto Internet Explorer non supporta al momento la combinazione ECDHE con l'algoritmo di criptazione RC4.

Via | Google Online Security Blog 

Nessun commento:

Posta un commento