Come posso dimostrare che 3 CA radice indipendenti hanno convalidato il mio dominio?

5

Sono preoccupato per l'hacking di una CA radice e voglio acquistare 3 certificati SSL da provider completamente diversi che convalideranno in modo indipendente la mia identità. Poi al momento della presentazione, invierò tutte e 3 le "certificazioni" al cliente.

Quali approcci esistono per soddisfare questa esigenza dal punto di vista del protocollo o cripto (dove le chiavi sono unite in qualche modo)?

Contesto

  • Un client Web HTTP esistente, un'estensione chrome o SOCKS / Proxy che esegue una convalida aggiuntiva
  • Una dimostrazione del concetto per un'altra implementazione non ancora inventata (ad esempio una nuova versione di TLS che incorpora nuova crittografia)

Le possibili soluzioni che ho pensato includono:

  • Il client effettua 3 richieste HTTPS, in cui ogni richiesta viene crittografata con un certificato diverso. La risposta dovrebbe essere un numero casuale uguale in tutte e 3 le risposte.

  • 2 chiavi sono firmate e contengono un campo personalizzato x509 che fa riferimento al numero di serie del certificato "validato"

  • Le chiavi sono combinate matematicamente in un modo interessante che riduce le richieste multiple in una singola richiesta. (RSA o ECC / sottogruppi)

Domanda

  1. Esiste un tale protocollo in bozza ovunque?

  2. Esiste un modo per combinare matematicamente la convalida dei certificati N senza perdere la sicurezza?

    a. Sono interessato alla crittografia che autentica me 3x come host web

    b. Aumenta l'integrità dei dati con un flusso di dati con firma 3x

    c. Aumenta la privacy dei dati con 3x la crittografia

(Nota: so che DANE potrebbe soddisfare parte di questo requisito, ma sto cercando una soluzione non DANE / HTS)

    
posta random65537 29.08.2015 - 03:50
fonte

1 risposta

5

Non esiste un modo standard per fare ciò che si immagina e non sono a conoscenza di alcuna proposta di rilevanza. La struttura PKI attualmente stabilita consente solo una singola catena di certificati (vale a dire un singolo emittente per un certificato) e il protocollo TLS come utilizzato consente solo un certificato a foglia singola. In teoria si potrebbe creare un certificato con più emittenti utilizzando estensioni di certificati e in teoria si potrebbe estendere il processo di convalida in TLS per verificare la presenza di più emittenti. Ma ancora una volta non sono a conoscenza di proposte serie in questo campo.

L'erogazione di certificati diversi tramite più richieste HTTPS richiede anche alcune estensioni o hack, in quanto il server deve sapere quale dei certificati deve inviare. Con le nuove estensioni TLS il cliente potrebbe richiedere un certificato specifico. Senza il client è possibile riutilizzare le estensioni esistenti come SNI per uno scopo diverso, ovvero dare nomi host di destinazione leggermente diversi. Oppure si potrebbero fornire diversi indirizzi IP nel DNS e ciascun server di indirizzi IP un certificato diverso. Oppure si potrebbero ruotare casualmente certificati. In tutti questi casi il cliente deve essere consapevole del fatto che dovrebbe cercare di ottenere più certificati e quanti certificati dovrebbe ottenere e come combinare le informazioni. Ciò significa che sono necessarie alcune conoscenze sul server che è codificato in ciascun certificato (cioè estensione del certificato) o che il client ha ricevuto dalla risorsa esterna in modo sicuro.

Poiché non esiste uno standard o anche uno standard proposto per farlo, devi inventare il tuo o cercare di ottenere il meglio dagli standard attuali. Poiché l'hacking di una CA radice è la tua preoccupazione principale, potresti essere già sufficientemente protetto con lo standard esistente HPKP , ovvero il blocco dei certificati al primo utilizzo. In questo modo, nessuna CA compromessa può creare un certificato utilizzabile nel tuo nome, che viene accettato dai browser che ti hanno già visitato, perché l'utente malintenzionato avrebbe bisogno della tua chiave privata per abusare del certificato. E se HPKP non è abbastanza, puoi richiedere che la tua chiave pubblica sia inclusa nel browser man mano che viene spedita. E questo blocco della chiave pubblica non è limitato a una CA specifica ma solo alla coppia di chiavi, il che significa che la chiave e quindi le informazioni HPKP rimangono invariate se si utilizza la stessa chiave in un altro certificato firmato da un'altra CA. In questo modo è possibile cambiare facilmente CA se si viene diffidati dal browser. Al momento non tutti i browser supportano HPKP ma è migliore . Quindi questo è probabilmente il meglio che si possa ottenere senza provare a stabilire un altro standard o creare un'estensione del browser poco utilizzata. Se HPKP non è un'opzione per te, potresti aggiungere i motivi alla tua domanda.

    
risposta data 29.08.2015 - 08:58
fonte