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.

chromecertPer default Google Chrome, unico tra i browser più utilizzati, sceglie non verificare online la revoca di un certificato, ma utilizza un proprio metodo che è immune da attacchi esterni. Tuttavia il browser permette di abilitare il controllo online della revoca per far fronti a casi particolari come quello di Heartbleed.

Non esiste una soluzione ottimale al problema della revoca dei certificati perché ci sono dei casi particolari che in situazioni specifiche fanno ritenere inadeguato l’uno o l’altro metodo. Nel frattempo chi utilizza Google Chrome dovrebbe abilitare il controllo della revoca dei certificati presente nelle opzioni avanzate, anche se la pratica non è condivisa da tutti. [via Netcraft]

Autore: Luigi Rosa

Consulente IT, sviluppatore, SysAdmin, cazzaro, e, ovviamente, geek.

3 pensieri riguardo “Revoca dei certificati”

  1. Sull’immunita` del metodo usato da Google Chrome per verificare la revoca dei certificati ho qualche dubbio.
    Giustamente si basa sull’idea che se sono un utente che e` a rischio perche’ un certificato e` stato revocato, allora le mie comunicazioni sono a rischio di un attacco man-in-the-middle, che rende quasi del tutto inutili CRL e OCSP; pero` a quel punto non posso piu` fidarmi nemmeno delle mie comunicazioni con il server di Google da cui devo scaricare la loro lista… dunque il metodo di Chrome e` anche lui molto insicuro.

    La morale? Seguire il consiglio di Luigi, ed attivare in Chrome il controllo della revoca.

    1. In realtà il problema non è solo un MitM del server di revoca, ma anche un DoS dello stesso (molto più semplice DoSsare i server che fare un MitM). Se il server della revoca non risponde il brower fa un soft landing e prosegue (è spiegato in uno dei documenti linkati)

      Non puoi obbligare HTTPS sul server delle revoche perché incorri nel loop della revoca del certificato HTTPS del server medesimo. Non puoi averne più di uno perché potresti incorrere nel rischio di dover revocare tutti i certificati (Heartbleed ha dimostrato che il rischio non è così irrealistico).

      E’ il solito problema che in una relazione di trust distribuita: di qualcuno ti devi ben fidare.

      1. E` vero che un DoS e` piu` facile, ma una gran maggioranza dei certificati (almeno dal punto di vista dell’utente della strada) viene usata semplicemente per garantirti che il server https con cui ti colleghi sia proprio quello che dice di essere, dunque chi viola quel certificato lo usa per un attacco MitM. E dunque devi tener conto di essere a rischio MitM, oltre che DoS.

        Insomma, non e` facile uscirne, e come dici tu, devi decidere che di qualcuno ti devi fidare. Il problema e` che quel “qualcuno” poi diventa un bersaglio appetitoso.

        Come dice sempre Bruce Schneier, la sicurezza e` un processo.

Spazio per un commento