Perché usare CAA?
Una CA utilizza sempre metodi di convalida del dominio per assicurarsi che ogni SSL /TLS la richiesta di certificato è autorizzata (di solito assicurandosi che sia collegata in qualche modo a un determinato sito utilizzando quel dominio).
Ad esempio, una CA potrebbe fornire un file di verifica speciale al richiedente. Posizionare questo file sul sito Web dimostra che il richiedente controlla anche quel sito, ma non può garantire il legittimità di quel controllo. Un hacker che ottiene il controllo di un sito potrebbe mascherarsi come il legittimo proprietario e potrebbe quindi richiedere e ricevere un SSL /TLS certificato che supera i controlli standard di qualsiasi CA e quindi sembra legittimo. Potrebbero quindi tornare indietro e utilizzare tale SSL /TLS certificato di danno, su quel sito o altrove.
CAA aiuta a bloccare questo tipo di exploit definendo a quali CA è consentito emettere certificati per un dominio (o addirittura limitando del tutto l'emissione di certificati). Ciò limita il danno che un dirottatore può infliggere: anche se hanno il controllo di un sito, avranno drasticamente meno opzioni per ottenere un SSL non autorizzato /TLS certificato.
Come funziona CAA
CAA utilizza DNS
I Domain Name System (DNS) è una parte cruciale dell'infrastruttura di Internet. Il proprietario di qualsiasi dominio mantiene i record DNS (all'interno del cosiddetto file di zona) che punta il loro nome di dominio all'indirizzo IP in cui è ospitato il loro sito e ci permette di digitare google.com in una finestra del browser anziché 216.58.194.46.
I record DNS sono comunemente usati come "rubrica telefonica per Internet", ma il DNS consente anche altri tipi di record speciali che possono assegnare altre informazioni a un nome di dominio.
Record CAA
CAA utilizza un tipo speciale di record chiamato a Record delle risorse di autorizzazione dell'autorità di certificazione (Record CAA). Questi sono pubblicati tramite DNS e il proprietario del dominio aggiunge semplicemente i record CAA insieme ai suoi altri record DNS. Un record CAA include a etichetta e APPREZZIAMOe la coppia tag-valore viene definita a proprietà. C'è anche una bandiera indicando quanto sia critica questa proprietà. Ecco come appare:
example.com. Problema CAA 0 "ssl.com"
Qui, example.com è il dominio a cui si applica questo record e CAA ci fa sapere che tipo di record è questo. Il 0 è il flag (zero è l'impostazione predefinita - ne parleremo di seguito). Il tag è problema e il valore (tra virgolette) è ssl. com, che insieme costituiscono la proprietà.
Bandiere
Le bandiere hanno attualmente solo due stati rigorosamente definiti: 0 (non critico) e 1 (Critico). Un flag critico dice alla CA che è così devono obbligatoriamente: comprendere completamente il tag della proprietà per procedere. RFC 6844 lascia aperte altre possibilità per l'uso di flag definiti dall'utente (ne parleremo anche di seguito).
tag
RFC 6844 definisce l'uso di tre tag comuni: problema, problema selvaggio ed IODEF. (Come per le bandiere, consente altri potenziali tipi di tag personalizzati.)
I problema etichetta
I problema tag specifica quale (se presente) CA è autorizzata a emettere certificati per questo dominio. Ad esempio, il proprietario del dominio example.com può limitare l'emissione del certificato a una CA (qui, SSL.com) utilizzando il seguente file di zona DNS:
example.com. Problema CAA 0 "ssl.com"
Un proprietario di dominio può scegliere di impostare più file di zona per un dominio:
example.com. CAA 0 problema "ssl.com" example.com. CAA 0 problema "comodoca.com"
I record di cui sopra limitano SSL /TLS rilascio del certificato per example.com a due CA (SSL.com e Comodo.com).
I problema record autorizza inoltre la CA indicata a emettere certificati per qualsiasi sottodominio del dominio specificato. Un record che consente SSL.com può quindi consentire l'emissione di certificati per example.com e sottodomini come www.example.com, mail.example.com e persino il sottodominio con caratteri jolly speciali * .example.com.
È possibile utilizzare un record CAA per limitare anche l'emissione del certificato: questo record lo dice alle autorità di certificazione che utilizzano CAA no SSL /TLS i certificati dovrebbero essere emessi per example.com e sottodomini di in qualsiasi CIRCA:
example.com. Problema CAA 0 ";"
(Il punto e virgola in questo esempio significa "non permettere niente qui", Ma come vedremo in seguito viene utilizzato anche per definire parametri personalizzati.)
Tieni presente che un tag di emissione standard consente alla CA di emettere un certificato per un carattere jolly a meno che non venga modificato da ...
I problema selvaggio etichetta
Questo tag specifica che una CA è autorizzata a emettere certificati con caratteri jolly per il dominio del proprietario (ad es * .example.com).
I caratteri jolly sono un tipo speciale di sottodominio generale e merita particolare attenzione e attenzione quando si emettono certificati con caratteri jolly. Il problema selvaggio tag consente al proprietario del dominio di definire quali CA possono emettere certificati per caratteri jolly separatamente dal dominio principale o da altri sottodomini. problema selvaggio i tag hanno la precedenza su qualsiasi problema tag. Usano la stessa sintassi di problema etichetta. Qualche esempio:
example.com. CAA 0 problema "ssl.com" example.com. CAA 0 issuewild ";"
Quanto sopra consente a SSL.com di emettere certificati per example.com e tutti i sottodomini con l’esclusione di per il carattere jolly * .example.com. (Né SSL.com né altre CA sono autorizzati a emettere certificati con caratteri jolly per example.com.)
example.com. Problema CAA 0 ";" example.com. CAA 0 issuewild "ssl.com"
Questo esempio proibisce contro tutti i Autorità di certificazione per il rilascio di certificati example.com e i suoi sottodomini, ma crea un'eccezione per consentire a SSL.com di emettere certificati con caratteri jolly (e esclusivamente certificati con caratteri jolly) per example.com.
I IODEF etichetta
Il terzo tag definito è IODEF. Questo tag può essere utilizzato per segnalare richieste di certificati non valide al proprietario del dominio e si presentano così:
example.com. CAA 0 iodef "mailto: certissues@example.com" example.com. CAA 0 iodef "certissues.example.com"
Il record principale fornisce le informazioni CA necessarie per inviare una notifica e-mail all'indirizzo certissues@example.com. Il secondo indica alla CA di inviare un messaggio di incidente a un servizio Web (impostato a questo scopo dal proprietario del dominio) all'indirizzo certificati.example.com. (È possibile utilizzare uno o entrambi questi metodi, a seconda di come la CA e il proprietario del dominio hanno impostato le proprie operazioni.)
IODEF i messaggi postali usano un formato standard chiamato Incidente Oggetto Descrizione Formato di scambio o IODEF - da cui il nome. (IODEF è definito in RFC 6546.)
Flag e tag definiti dalla CA.
CAA come descritto in RFC 6844 definisce in modo specifico solo due stati di bandiera (0 e 1) e tre tag (problema, problema selvaggio ed IODEF). Tuttavia, lascia la progettazione sufficientemente aperta per consentire alle autorità di certificazione di creare e utilizzare tag e flag personalizzati per definire il processo di rilascio dei certificati. Esempi potrebbero essere:
example.com. Problema CAA 0 "SSL.com; policy = ev"
Questo record utilizza uno standard problema tag con un parametro aggiuntivo che indica alla CA di utilizzare la propria politica di convalida estesa (EV) durante l'emissione di un certificato per questo dominio.
example.com. CAA 128 pca "PCA = 12345"
Il proprietario del dominio potrebbe utilizzare questo record con un nuovo, definito dalla CA. PCA tag per mostrare che hanno un account cliente preferito e imposta il numero di account come parametro. (Il flag può avere anche un valore personalizzato fino a 255). A seconda di come la CA imposta l'account, ciò potrebbe consentire metodi di fatturazione particolari, una verifica aggiuntiva definita dall'account o altra gestione speciale.
Pro e contro
Vantaggi ...
Ci sono diversi ottimi motivi per utilizzare CAA. Il vantaggio principale e più importante è la capacità della CAA di ridurre notevolmente il rischio di emissione errata dei certificati. Questo aiuta a proteggere il tuo dominio, la tua attività e la tua identità online. I potenziali aggressori che potrebbero aver trovato un bug nel software di una particolare CA non possono sfruttarlo per emettere certificati SSL per il tuo dominio. Inoltre, l'utilizzo del tag iodef consente di ottenere un report se viene tentato un exploit.
Il design di CAA aumenta la sicurezza ma può anche consentire un'allocazione più dettagliata delle risorse: ad esempio, un'azienda potrebbe impostare dei record per consentire (o limitare) al reparto vendite e marketing di acquistare certificati SSL per sales.example.com da una fonte designata.
Inoltre, CAA offre una grande flessibilità. Per un proprietario di dominio, utilizza record di risorse DNS che sono sotto il proprio controllo e possono essere modificati in base alle esigenze, quindi non sono collegati a una CA specifica (e possono avere più di una CA autorizzata con record di problemi per un determinato nome di dominio) . Per le CA, anche a parte gli usi personalizzati, le nuove regole adottate dal Forum CA / B (il gruppo che stabilisce gli standard per le questioni di sicurezza delle CA e dei browser) possono consentire l'utilizzo dei record CAA a fini di convalida, fornendo un'altra valida ragione per utilizzarli.
... e svantaggi
L'unico problema più grande con CAA è che non è stato adottato da tutte le CA. I requisiti di base del forum CA / B (che soddisfano tutte le CA attendibili) richiedono a una CA di specificare il grado di supporto della CAA nella documentazione in linea. Al momento della stesura di questo documento, tuttavia, l'uso di CAA è solo raccomandato, non richiesto. Le autorità di certificazione che non sono conformi alla CAA possono comunque essere prese di mira, e fino a quando la CAA non sarà ampiamente utilizzata, un dirottatore sarà probabilmente in grado di trovare una CA non conforme disposta a rilasciare un certificato canaglia.
Uno svantaggio correlato è che anche quando sono presenti record CAA, un utente non può imporre il suo utilizzo da parte di un'autorità di certificazione. Una CA deve essere conforme a RFC 6844 affinché tali record possano essere utilizzati e una CA non conforme potrebbe semplicemente ignorare i desideri espressi del proprietario del dominio come dichiarato nei propri record CAA.
La CAA deve inoltre essere configurata correttamente sia dal proprietario del dominio che da una CA. Let's Encrypt (che supporta CAA) di recente segnalato un problema minore con la loro base di codice il che ha purtroppo portato all'ignoranza delle regole CAA e all'emissione errata di sei certificati. Nessuna di queste era un'eccezione dannosa (e complimenti al team Let's Encrypt per aver risolto e segnalato il problema entro poche ore dalla scoperta). Tuttavia, questo sottolinea che un'autorità di certificazione conforme devono obbligatoriamente: implementare CAA impeccabile.
Un altro potenziale problema è la dipendenza di CAA dal DNS. A meno che un proprietario di dominio non protegga i propri servizi di denominazione, questo può essere un vettore per l'attacco. RFC 6844 suggerisce l'implementazione Estensioni di sicurezza del sistema dei nomi di dominio (DNSSEC), che utilizza record DNS con firma digitale per autenticare i dati e combattere la minaccia di spoofing DNS.
Infine, anche con CAA in atto e correttamente implementato, un record CAA da solo non può impedire completamente l'emissione di certificati non autorizzati. Sebbene CAA sia uno strumento utile e importante per limitare le opzioni di un utente malintenzionato, un dirottatore con accesso sufficiente (ad esempio, controllando DNS o tramite ingegneria sociale) potrebbe essere in grado di aggirarlo.
Conclusione
L'autorizzazione dell'autorità di certificazione ha un potenziale eccezionale come parte di un ecosistema di sicurezza più ampio e l'adozione e l'implementazione diffusa della CAA proteggerà dall'emissione errata dei certificati. Sebbene sia un peccato che non tutte le autorità di certificazione supportino attualmente la CAA, si discute su come renderlo più fortemente consigliato o obbligatorio per tutte le CA. Sebbene la CAA da sola non fermi ogni emissione errata di certificati, è un buon passo nella giusta direzione e SSL.com desidera esortarti a considerare l'utilizzo dei record CAA da solo.
Riferimenti
- RFC6844: Record di risorse dell'autorità di certificazione DNS (CAA)
- RFC5070: Il formato di scambio della descrizione dell'oggetto incidente
- RFC6546: Trasporto di messaggi di difesa inter-rete (RID) in tempo reale su HTTP /TLS
- RFC4033: Introduzione e requisiti di sicurezza DNS
- CA / B Forum Ballot 125 - Record CAA
- Voce di Wikipedia sull'autorizzazione dell'autorità di certificazione DNS
