DKIM canonicalizzazione definisce il modo in cui i byte del messaggio vengono preparati per la verifica dell'hashing e della firma. Permette normalizzazioni specifiche; non rende innocua la modifica arbitraria dei messaggi. Diagnosticare le impostazioni effettive della firma e il contenuto non elaborato prima di modificare la configurazione del mittente.
Leggi le due impostazioni separatamente
Quella della firma c= canonicalizzazione dei nomi dei tag, intestazione e corpo, in quest'ordine. Per esempio, rilassato/semplice utilizza un'elaborazione rilassata per le intestazioni e un'elaborazione semplice per il corpo. RFC 6376 §3.5 definisce semplice/semplice come predefinito quando il tag è assente; se viene indicato solo l'algoritmo dell'intestazione, l'algoritmo del corpo viene impostato su semplice.
Documentazione c=, l'elenco delle intestazioni firmate h=, IL hash del corpo bh= e qualsiasi limite di lunghezza corporea l= accanto d= E s=. Una mancata corrispondenza dell'hash del corpo, una mancata corrispondenza dell'intestazione-firma e una chiave pubblica mancante richiedono indagini diverse. Non dedurre l'impostazione di canonicalizzazione da ciò che viene visualizzato dal client di posta.
Comprendere la normalizzazione consentita
La semplice canonicalizzazione dell'intestazione preserva i campi dell'intestazione come presentati all'algoritmo. L'elaborazione rilassata dell'intestazione riduce in minuscolo i nomi dei campi, spiega le righe di continuazione e normalizza gli spazi bianchi specificati. Non minuscola i valori dei campi né autorizza la modifica delle parole di un Oggetto.
La semplice canonicalizzazione del corpo rimuove le righe vuote alla fine e garantisce il CRLF finale richiesto, pur mantenendo gli altri contenuti del corpo. L'elaborazione rilassata del corpo riduce inoltre le sequenze di spazi e tabulazioni all'interno di una riga e rimuove gli spazi bianchi alle estremità della riga prima di gestire le righe vuote finali. Non combina linee arbitrarie, non riscrive URL, non rimuove i limiti MIME né ignora il testo aggiunto. RFC 6376 §3.4 specifica l'ordine esatto e i casi limite, incluso il diverso trattamento di un corpo vuoto.
Utilizzare un'implementazione conforme per test esatti. Un'approssimazione modificata manualmente che modifica le terminazioni di riga prima della verifica può creare l'errore su cui dovrebbe indagare.
Applicare un esempio controllato
Considera la linea del corpo sintetico Paga<SP><SP>ora<SP><CRLF>, dove le etichette tra parentesi indicano byte anziché testo letterale. Produce la canonicalizzazione del corpo rilassato Paga<SP>adesso<CRLF> per quella linea. La semplice lavorazione del corpo conserva gli spazi interni e finali. Una modifica di questo tipo basata solo sugli spazi può quindi avere risultati diversi con gli algoritmi dei due corpi.
Ora aggiungi una nuova frase dopo il messaggio firmato. Un'elaborazione rilassata non elimina tale aggiunta sostanziale. Supponendo la copertura di tutto il corpo e nessun altro cambiamento nel test, il corpo canonizzato è diverso e così anche l'hash corporeo previsto. Una regola del piè di pagina non può essere dichiarata sicura semplicemente perché il mittente utilizza rilassato/rilassato.
L'esempio spiega la normalizzazione prevista, non un incidente catturato o un test eseguito. Nella produzione, tenere conto della codifica MIME , delle intestazioni firmate e del trattamento della lunghezza effettiva della firma. Due messaggi possono essere visualizzati in modo identico mentre i loro byte con segno differiscono.
Individuare la trasformazione prima di modificare la politica
Conservare il messaggio originale, quindi ottenere campioni di confronto autorizzati prima e dopo i sospetti modificatori. Utilizzare le copie per l'analisi. Confronta un test altrimenti equivalente con e senza il piè di pagina sospetto, la funzionalità di riscrittura o ricodifica del collegamento, mantenendo lo stesso percorso di trasporto.
Se l'architettura supportata lo consente, eseguire le modifiche necessarie al contenuto prima della fase di firma finale appropriata. Se un intermediario si rifirma, valutarne la nuova identità e allineamento. Non disabilitare l'elaborazione del gateway di protezione né indebolire la policy del dominio esclusivamente per rendere verde un test diagnostico.
COME RFC 6376 §8.2 avverte, una lunghezza del corpo l= limitare le modifiche alla quantità di corpo canonizzato coperto. Non si tratta di una soluzione generale per la modifica successiva alla firma e può lasciare il contenuto aggiunto all'esterno della parte firmata. Esaminare le implicazioni sulla sicurezza e il supporto del provider anziché aggiungerlo per eliminare un errore.
Dimostrare la correzione a livello di byte e percorso
Conservare l'errore originale, le impostazioni di canonicalizzazione, il confronto controllato e un risultato ricevuto dal percorso corretto. Se la modifica della canonicalizzazione è il rimedio supportato scelto, verificare che l'operazione di modifica effettiva rientri nelle trasformazioni consentite. Una nuova firma rilassata può tollerare alcune modifiche agli spazi bianchi pur rimanendo vulnerabile alla riscrittura sostanziale originale. Chiudere il problema solo quando il cambiamento osservato e il risultato della verifica coincidono.
Controllare il caso limite a corpo vuoto
Sotto RFC 6376 §3.4.3, un corpo completamente vuoto o mancante diventa un CRLF, o due ottetti, nella canonicalizzazione del corpo semplice. Sotto RFC 6376 §3.4.4, la canonicalizzazione del corpo rilassato produce zero ottetti per un corpo vuoto. Uno strumento che esegue l'hashing CRLF in entrambi i casi non sarà d'accordo con lo standard anche se entrambi i messaggi appaiono vuoti. Questo è un esempio di specifica, non una verifica DKIM completa o un test di posta eseguito.
Lettura correlata
Sintassi della chiave pubblica DKIM : identifica i valori DNS troncati o non corretti · Firme DKIM multiple: trova la firma di passaggio allineata.