Perché usare CAA?
Gli informatici Phillip Hallam-Baker e Rob Stradling hanno sviluppato CAA in risposta alle crescenti preoccupazioni sulla sicurezza delle autorità di certificazione pubblicamente attendibili. Questa iniziativa rientra nell'Internet Engineering Task Force (IETF), un'organizzazione leader nello sviluppo di standard (SDO) per Internet. L'IETF crea standard volontari ampiamente adottati dagli utenti di Internet, dagli operatori di rete e dai venditori di apparecchiature, influenzando l'evoluzione di Internet.
L'IETF documenta i suoi standard tecnici in pubblicazioni note come RFC (Requests for Comments). Questi documenti delineano gli aspetti chiave dell'infrastruttura Internet, tra cui tecnologie di indirizzamento, routing e trasporto. CAA è specificamente definito in RFC 6844.
Un'autorità di certificazione (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.
Che cos'è un CNAME?
Un record CNAME è un tipo di configurazione DNS che consente a un dominio, ad esempio store.mybusiness.com, per fungere da alias per un altro, come ilmiobusiness.com. Invece di gestire più record A per riflettere i cambiamenti di indirizzo IP, un CNAME semplifica questo processo puntando l'alias al dominio di destinazione. Questo approccio è altamente vantaggioso per le aziende che cambiano regolarmente web host o provider CDN. Inoltre, i record CNAME sono preziosi per la creazione di sistemi di failover, in cui il traffico viene indirizzato da un server primario a uno secondario, garantendo la continuità del servizio durante le interruzioni.
Nel contesto di Certificate Authority Authorization (CAA), i record CNAME influenzano il processo reindirizzando i controlli CAA al dominio di destinazione. Ad esempio, se shop.miosito.net usa un CNAME per puntare a miosito.net, una CA che esegue un controllo CAA valuterà i record per miosito.net per verificare l'autorizzazione per l'emissione di un certificato. Se il record CAA su miosito.net non autorizza la CA, il certificato non può essere emesso. Ciò garantisce l'applicazione coerente delle policy CAA anche quando i domini sfruttano i record CNAME per l'aliasing DNS.
Come funziona CAA
CAA utilizza DNS
Migliori 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 è il valore predefinito). 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 di proprietà per procedere. RFC 6844 lascia aperte altre possibilità per l'uso di flag definiti dall'utente (maggiori dettagli di seguito).
Tags
RFC 6844 definisce l'uso di tre tag comuni: problema, problema selvaggio and IODEF. (Come per le bandiere, consente altri potenziali tipi di tag personalizzati.)
Migliori problema etichetta
Migliori 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).
Migliori 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 ...
Migliori 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 possono rappresentare un set illimitato di sottodomini, e quindi è necessaria particolare cura e attenzione quando si emettono certificati con caratteri jolly. 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.
Migliori 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.)
Il tag issuemail per S/MIME
Uno sviluppo importante nel CAA è l'estensione a S/MIME Certificati (Secure/Multipurpose Internet Mail Extensions), formalizzati in RFC 9495. S/MIME i certificati forniscono sicurezza e-mail tramite autenticazione, riservatezza dei dati e integrità dei messaggi. Il CA/Browser Forum ha introdotto un nuovo tag di proprietà CAA denominato "issuemail" specificamente per controllare l'emissione di S/MIME certificato.
A partire dal 15 settembre 2024, si raccomanda alle CA di implementare il controllo CAA per S/MIME certificati, con attuazione obbligatoria richiesta entro il 15 marzo 2025. Il modulo di registrazione CAA standard per gli indirizzi e-mail si presenterebbe così:
mail.client.example CAA 0 problemamail "authority.example"
Questa estensione del CAA ai certificati di posta elettronica fornisce ai proprietari di domini lo stesso livello di controllo su S/MIME rilascio del certificato come hanno fatto per TLS certificati, riducendo il rischio di rilascio di certificati non autorizzati.
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 and 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
Ci sono diverse ottime ragioni per usare CAA. Il vantaggio principale e più importante è la capacità di CAA di ridurre notevolmente il rischio di emissione errata di certificati. Ciò 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, usando il tag iodef puoi 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.
Uno svantaggio è che anche quando i record CAA sono in atto, 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
Certification Authority Authorization ha un potenziale formidabile come parte di un più ampio ecosistema di sicurezza, e l'adozione e l'implementazione diffuse di CAA proteggeranno dall'emissione errata di certificati. Sebbene CAA da sola non fermerà ogni emissione errata di certificati, è un buon passo nella giusta direzione, e SSL.com vorrebbe esortarti a considerare l'utilizzo di record CAA.
Referenze
- 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
Guide correlate
- Quali sono i requisiti per SSL.com SSL/TLS Convalida del dominio del certificato?
- Qual è il "valore unico" utilizzato nella convalida del dominio (DV)?
- Nome di dominio SSL /TLS Pre-convalida
