Credenziali delegate per TLS

Terminare a TLS la connessione richiede l'utilizzo della chiave privata di un certificato. Di conseguenza, la chiave privata deve essere archiviata su ogni singolo server utilizzato da un servizio. La protezione della segretezza di questa chiave privata è fondamentale per il buon funzionamento di uno schema di infrastruttura a chiave pubblica. Un'entità in possesso della chiave privata può eseguire attacchi man-in-the-middle per il resto della validità del certificato. In genere, quando un utente malintenzionato compromette una chiave privata, il certificato associato a questa chiave viene revocato e ne viene emesso uno nuovo. Tuttavia, per le aziende che utilizzano più server, come Facebook o

” per i server che indicano che sono autorizzati a terminare il TLS connessione.

“Un meccanismo di delega limitata che consente a TLS peer di rilasciare le proprie credenziali nell'ambito di un certificato emesso da una CA esterna. Queste credenziali consentono solo al destinatario della delega di parlare per i nomi che la CA ha autorizzato.

Le credenziali delegate sono progettate con lo scopo di aumentare la sicurezza. Quindi, possiedono determinati tratti, come definiti nella bozza IEFT.

• Il periodo massimo di validità di una credenziale delegata è sette (7) giorni per ridurre al minimo l'esposizione se la chiave privata è compromessa. Il breve periodo di validità non significa che la sicurezza delle credenziali delegate debba essere presa alla leggera. Le misure adottate per proteggere la chiave privata del certificato dell'entità finale dovrebbero applicarsi anche alla protezione dei DC. Questi includono controlli del file system, sicurezza fisica e moduli di sicurezza hardware, tra gli altri. Inoltre, le credenziali delegate dovrebbero essere utilizzate solo tra parti che condividono una relazione di fiducia tra loro.
• Le credenziali delegate sono legato crittograficamente al certificato dell'entità finale. In particolare, la chiave privata del certificato dell'entità finale viene utilizzata per calcolare la firma del DC tramite un algoritmo specificato dalla credenziale. La firma associa efficacemente il controller di dominio ai nomi del certificato dell'entità finale.
• Le credenziali delegate vengono emesse dal client, il che è molto più semplice rispetto alla creazione di un certificato firmato da una CA. I certificati emessi dal client sono utili anche per mantenere attivo il servizio anche se la CA ha un tempo di inattività. Inoltre, le organizzazioni possono sperimentare algoritmi non ufficialmente supportati dalla CA senza compromettere la sicurezza del certificato dell'entità finale. 
• Le credenziali delegate hanno brevi periodi di validità per definizione. Quando si imposta la durata delle credenziali delegate, i server devono prendere in considerazione lo sfasamento dell'orologio del client per evitare il rifiuto dei certificati. Lo sfasamento dell'orologio del client è importante anche per il certificato originale, ma è cruciale per la chiave privata delegata di breve durata. Lo sfasamento dell'orologio del cliente dovrebbe essere preso in considerazione sia all'inizio che alla fine dei periodi di validità.
• Non è previsto alcun meccanismo di revoca per le credenziali delegate. Sono resi non validi alla scadenza del periodo di validità. Tuttavia, la revoca della chiave privata del certificato dell'entità finale (utilizzata per firmare le credenziali delegate) revoca implicitamente la credenziale delegata. 
• Le credenziali delegate sono progettate per essere utilizzate in TLS 1.3 o più tardi. C'è una vulnerabilità nota quando TLS I server 1.2 supportano lo scambio di chiavi RSA, consentendo la creazione di una firma RSA su un messaggio arbitrario. Supponiamo che un attaccante sia in grado di falsificare una firma. In tal caso, possono creare credenziali delegate contraffatte per l'intero periodo di validità del certificato dell'entità finale. Questa vulnerabilità non è presente nelle implementazioni di TLS 1.3 o successivo. Inoltre, la vulnerabilità non interessa i certificati con crittografia a curva ellittica, che SSL.com fornisce. 
• Le organizzazioni possono utilizzare le API di emissione automatizzata esistenti come ACME per fornire credenziali delegate. In questo caso gli algoritmi utilizzati sono solo quelli supportati dalla CA, ma questa pratica riduce la possibilità di compromessi chiave. SSL.com approva questa pratica. 
• Le credenziali delegate non possono essere riutilizzate in più contesti. Le parti emittenti calcolano la firma utilizzando una stringa di contesto univoca per il ruolo previsto (client o server), rendendo così impossibile l'uso della stessa credenziale delegata per l'autenticazione client e server. 

utilizza l'ECDSA per attuare il PKI offerto a clienti, le credenziali delegate emesse dai nostri clienti non sono vulnerabili agli attacchi di contraffazione delle firme, come descritto sopra.