pacchetto di richieste WinHTTP e python, non riesce a convalidare il certificato che contiene CN valido ma SAN non valida

Question

pacchetto di richieste WinHTTP e python, non riesce a convalidare il certificato che contiene CN valido ma SAN non valida

#1 da (2 voti)

1

Usiamo WinHTTP per inviare chiamate API dal nostro client. Ora in base al criteri comuni, FCS_TLSC_EXT.1.2 attività di verifica Test 2, se certificato contiene un CN valido (nome comune) ma una SAN non valida (Nome alternativo oggetto), la connessione dovrebbe fallire.

Test 2: The evaluator shall present a server certificate that contains a CN that matches the reference identifier, contains the SAN extension, but does not contain an identifier in the SAN that matches the reference identifier. The evaluator shall verify that the connection fails. The evaluator shall repeat this test for each supported SAN type.

strumento che stiamo utilizzando per generare un certificato con CN valido ma SAN non valida .

Tuttavia, con WinHTTP e il pacchetto di richieste python, accettano la SAN non valida (che non dovrebbe accadere). Non sembra esserci alcuna documentazione su WinHTTP su come questo possa essere gestito. questa è l'implementazione interna di WinHTTP.

Anche Internet Explorer fallisce questo test e accetta la connessione. Tuttavia, Chrome rifiuta la connessione e conferma che il certificato non è valido (che è il comportamento richiesto):

Il test fallisce anche con la libreria di richieste di python.

Stiamo cercando in qualche modo se questo può essere modificato per verificare il problema. Oppure siamo noi che affrontiamo il problema?

Poiché entrambe le librerie python e windows sono usate comunemente, questo comportamento è comune? Qualcun altro ha riscontrato questo problema?

Voglio sapere se questo è il modo in cui WInHTTP implementa il controllo SAN, o è solo la nostra implementazione. Inoltre, non sono riuscito a trovare alcuna documentazione su MSDN per quanto riguarda il controllo SAN in WinHTTP.

tls certificates common-criteria

posta Muhammad Uzair Khan 27.02.2018 - 14:26

fonte

1 risposta

Leggi altre domande sui tag tls certificates common-criteria

Capacità di resistenza per cancellare le chiavi di crittografia del disco rigido che rendono il disco irrecuperabile in Windows? Dovremmo archiviare file di applicazioni Web quando siamo costantemente in sviluppo nella directory criptata?

score 2 · Accepted Answer

Innanzitutto, il problema non riguarda la CN valida rispetto a una SAN non valida, ma un CN corrispondente al dominio rispetto a una SAN non corrispondente al dominio. Una SAN non corrispondente è ancora una voce SAN valida.

La regola secondo RFC 6125 è che il CN NON DEVE essere controllato se c'è una voce SAN DNS. Inoltre, CN viene deprecato per un lungo periodo di tempo e RFC 6125 aggiunge esplicitamente che il CN può essere controllato se non esistono record SAN tipizzati in modo appropriato e non lo richiedono. Tuttavia, la maggior parte delle implementazioni controlla sia SAN che CN. Solo Chrome non controlla il CN da un po 'di tempo. Questo è il motivo principale per cui il problema sembra essere risolto con Chrome ma non con altri e questo in realtà viola "La verifica utilizzando il nome comune è richiesta ai fini della retrocompatibilità" da FCS_TLSC_EXT.1.2.

... and python requests package, they accept the invalid SAN

Per quanto posso vedere, la versione corrente delle richieste utilizza in definitiva la funzionalità di questo modulo ssl in Python per convalidare il nome host. Il codice qui nell'ultima versione di Python garantisce esplicitamente che CN venga controllato solo se non esistono nomi DNS SAN. Naturalmente, questo potrebbe variare con la versione sconosciuta di Python e le richieste che stai usando.

I want to know if this is how WInHTTP implements SAN check, or is it just our implementation

Anche se non posso essere sicuro perché non conosco la tua implementazione, la possibilità è che almeno la versione di WinHTTP stia utilizzando gli strumenti CN che controllano in aggiunta a SAN - almeno per impostazione predefinita. Questo è simile a molte altre implementazioni anche se non corrisponde né a RFC 6125 né a RFC 2818 meno recenti.