Le regole utilizzate per convalidare i certificati nei principali browser sono documentate ovunque?

Quali browser sono soggetti a modifiche ai capricci di chi li gestisce e lo fanno senza alcuna documentazione adeguata.

Il trattamento dei caratteri jolly in dNSName voci nei certificati è formalmente definito in RFC 2818 , che implicherebbe che, ad esempio, *.*.example.com corrisponderebbe a un nome di sottodominio che è a due livelli in calo di example.com ; dice anche che f*.com deve corrispondere effettivamente a foo.com ma non a bar.com .

È emerso che i browser non rispettano queste regole, per una serie di motivi che non sono mai stati completamente documentati, ma che rientrano principalmente in due categorie:

1. "Motivi di sicurezza"
2. Pigrizia

"Sicurezza" qui significa "ci siamo imbattuti in qualche abuso e cambiare le regole al volo sembrava una buona idea in quel momento". Ad esempio, una volta che qualcuno ha prodotto un certificato *.com , qualcuno ha capito che non era una buona idea e ha ritenuto opportuno semplicemente vietarlo nel codice del browser. Un punto importante da considerare qui è che i venditori di browser e le CA commerciali non sono le stesse persone; dal punto di vista di un manutentore del browser, se qualcosa deve essere fatto rapidamente (ad esempio entro 24 ore, non 24 mesi), deve essere fatto nel browser stesso. I problemi di sicurezza relativi ai browser tendono a essere altamente pubblicizzati e molto dannosi per l'immagine del browser, quindi questa richiesta di reazione rapida, che di solito (e purtroppo) preclude una buona documentazione.

La pigrizia è probabilmente colpa della mancanza di supporto di "caratteri jolly" come *.*.example.com . In generale, se si desidera implementare il supporto per le espressioni con diversi caratteri jolly, è necessario farlo con cicli nidificati (per esplorare tutte le possibili combinazioni di corrispondenza). Limitare i caratteri jolly a un singolo " * ", inoltre all'inizio del nome, semplifica l'implementazione.

Un altro fatto da tenere in considerazione è la proprietà paralizzante della "sicurezza". Quando qualcosa è stato fatto, o sembra di essere stato fatto, in nome della "sicurezza", molti sviluppatori perdono ogni iniziativa e sono estremamente riluttanti a modificarlo - perché sanno che qualsiasi contrattempo legato a la sicurezza comporta la piena colpa.

RFC 6125 ha provato a documentare la pratica esistente, anche se varia molto a seconda del browser (e sistema operativo, poiché alcuni browser delegano la convalida e l'elaborazione dei certificati al sistema operativo). Si noti che RFC 6125 non veramente vieta più di un * in un nome; infatti, è stato presentato un errata e l'editore lo ha inserito nello stato " tenuto per aggiornamento del documento ", che in realtà significa" buon punto, lo sistemeremo in una RFC successiva ".

Mentre RFC 6125 elenca i requisiti sul lato browser (consumatore di certificati), il CA / forum del browser considera anche il lato CA (produttore di certificati). I Requisiti di base sembrano implicare che solo un singolo * può si verificano, e solo alla sinistra di un nome (ma questo non è indicato molto chiaramente).

Mentre c'è molto di più nella convalida dei certificati rispetto all'elaborazione dei nomi con caratteri jolly, tutto il business attorno al carattere * illustra abbastanza bene che nulla è ben documentato, ei venditori di browser hanno già preso l'abitudine di fare le cose per primi e documentare le cose solo molto più tardi (se non del tutto).

Section 6.4.3 in the RFC heavily implies that *.*.example.com should validate,

Ho letto questa sezione in modo diverso. Secondo me dice chiaramente che corrisponde a DOVREBBE essere fatto solo contro l'etichetta più a sinistra (6.4 .3.1) e che se un jolly è l'unico carattere nell'etichetta come nel tuo caso, DOVREBBE essere solo abbinato alla parte più sinistra dell'identificatore (6.4.3.2).

Sulla base di queste regole DOVREBBE corrispondere solo la parte più a sinistra dell'identificatore alla parte più a sinistra del nome del carattere jolly, cioè solo la parte segnata con >>..<< : >>*<<.*.example.com Se ovviamente dice solo DOVREBBE quindi questi sono solo raccomandazioni, ma nella mia esperienza i browser aderiscono a queste.

is there any documentation of the algorithm(s) used by major browsers to validate certificates?

Non sono a conoscenza di alcuna documentazione ufficiale dei vari fornitori. Ma dalla mia esperienza gestiscono le basi allo stesso modo, ma si differenziano in casi più rari:

• Nessun browser corrente supporta più caratteri jolly (era nuovo per me che Safari fa secondo la tua domanda), ma tutti supportano il jolly più a sinistra. Gli strumenti da riga di comando e le convalide nel linguaggio di programmazione raggiungono lentamente questo comportamento.
• Alcuni controllano solo la sezione Subject Alternative Names (SAN) se contiene nomi DNS e ignorano il CN in questo caso. Altri controllano anche CN su SAN. Alcuni smettono di controllare la CN semplicemente se ci sono dei record nella sezione SAN, anche se tutti questi sono solo record di indirizzi IP.
• Quando si convalida un indirizzo IP, la maggior parte richiede l'indirizzo IP come voce IP nella sezione SAN. Alcuni controllano l'indirizzo IP anche contro CN. MSIE richiede invece che l'indirizzo IP sia all'interno di un record DNS nella SAN o come CN e non controlla le voci SAN di tipo indirizzo IP.
• Il comportamento relativo ai suffissi pubblici è diverso. Alcuni di questi suffissi come co.uk hanno un significato speciale, cioè non dovrebbe essere possibile per alcune aziende ottenere un certificato per *.co.uk ma solo per *.example.co.uk . Alcuni browser controllano questo comportamento per alcuni suffissi ma non per tutti . Altri browser non controllano affatto.

Il browser che è il più rigido nella maggior parte dei casi è Safari, a mio parere, quindi se funziona lì di solito funziona anche per altri browser. Tuttavia, quando si convalidano gli indirizzi IP, è necessario affrontare anche la gestione errata di MSIE includendo l'indirizzo IP non solo come record SAN IP ma anche come record SAN DNS.

E ovviamente questa è solo la parte della convalida del nome nell'URL rispetto ai nomi nel certificato. Poi c'è il problema della revoca, come gestiscono i certificati intermedi mancanti, dove ottengono i certificati di root da ecc. Molti comportamenti diversi tra i browser e talvolta anche tra lo stesso browser su piattaforme diverse: (