Autenticazione del certificato da un indirizzo IP non attendibile

0

Quando avvio Windows, vengono eseguiti i controlli di revoca dei certificati. Questi si verificano una volta all'avvio di explorer.exe, quindi periodicamente, ogni 40 minuti circa, a 5 IP. La maggior parte di questi sono indirizzati a host Microsoft, Google o Akamai di solito geolocalizzati nei Paesi Bassi e negli Stati Uniti. Sconcertante è tuttavia la chiamata a crl.microsoft.com che si risolve in un IP controllato dal mio ISP. Non utilizzo il DNS del mio ISP e applica un DNS di terze parti ([email protected]) a livello di sistema operativo tramite le Opzioni Internet di Windows.

Secondo la risposta DNS, i nomi host si risolvono come segue: CNAME crl.microsoft.com - > ms.akadns.net - > a1363.dscg.akamai.net - > Indirizzo 62. . . *** (ASN: 5089).

Ma questo indirizzo IP è registrato sul mio ISP, non su Akamai o Microsoft. Non ho motivo di credere che il mio ISP sia partner di Akamai o Microsoft.

Successivamente, un elenco di revoche di certificati è ottenuto dall'indirizzo "crl.microsoft.com" del mio ISP.

Quando si effettua una ricerca del nome di dominio altrove, ms.akadns.net si risolve in altri nomi e indirizzi di subhost, quindi il problema si verifica in ms.akadns.net > passo di traduzione a1363.dscg.akamai.net.

a1363.dscg.akamai.net non riesce a risolversi in nulla quando viene cercato direttamente.

Il mio sistema è pulito e non utilizzo alcun software ISP. Il mio modem (ISP-locked) è l'unico hardware dell'ISP sulla mia rete.

Un problema molto simile è descritto qui ma non sono in Romania. L'utente inesperto "risolve" il problema disabilitando le opzioni "verifica revoca certificati" sul proprio sistema.

Mi chiedevo se qualcuno potesse spiegare cosa dovrei fare per valutare l'estensione del problema. Vorrei fare riferimento ai certificati che ottengo dall'indirizzo non attendibile rispetto a quello che dovrebbero essere.

Modifica: Quindi altre persone possono trovare questo problema. Le connessioni in uscita vengono rese Svchost.exe utilizzando il servizio CryptSvc e DNScache. Le richieste di certificazione dei server vengono eseguite utilizzando l'intestazione Microsoft-CryptoAPI.

    
posta Inerva 07.09.2018 - 10:02
fonte

2 risposte

2

Ovviamente Microsoft sta utilizzando i servizi di Akamai per indirizzare i clienti che chiedono crl.microsoft.com da qualche parte . L'intero scopo dei servizi offerti da Akamai è quello di bilanciare il traffico su Internet nel modo più intelligente possibile. Questo è ciò che pagano i clienti di Akamai (sia gli ISP che i fornitori di contenuti).

Quindi, semplicemente parlando, funziona allo stesso modo di 8.8.8.8 (Google DNS), che non è affatto una singola macchina server DNS su tutto il pianeta terra, ma è un meccanismo (IP anycast per essere esatti) che si traduce in: Chiedere al server che fornisce il DNS di Google, che è vicino come nella definizione del proprio ISP.

La stessa cosa qui per CRL invece di DNS. Non c'è il server Microsoft CRL, c'è sicuramente un elenco di revisioni di certificati autorevoli gestito da Microsoft, ma sarà distribuito replicando su un numero di macchine su Internet .

Sei sorpreso che il server finale a cui ti connetti si trovi nel tuo ISP degli ISP; ma questo ha molto senso per il tuo ISP, Microsoft e Akamai. Non ho idea di quanto grande o piccolo sia il tuo ISP, ma impostandolo in questo modo il tuo ISP non deve caricare le sue linee phyiscal ad altri ASN con traffico verso crl.microsoft.com, ma invece eseguono un mirror da solo Rete. Questo è comune con molti servizi.

Se stai chiedendo se ti dovresti fidare di quel meccanismo: stai sostanzialmente fidando del tuo ISP e Akamai qui o no. Naturalmente, sarebbe possibile che per qualsiasi motivo il mirror CRL sulla rete del tuo ISP non venga aggiornato in tempo e perderai una revoca del certificato o il tuo ISP potrebbe teoricamente persino manipolarlo per scopo.

Nel caso in cui si desideri attenuare tale rischio, scoprire se è possibile indirizzare il browser a qualsiasi altro servizio CRL o eseguire l'override di crl.microsoft.com nel meccanismo di risoluzione DNS (ad esempio attraverso il file hosts; vedere collegamento ) non deve essere un CNAME per ms.akadns.net ma per un servizio diverso con un aspetto più affidabile per te.

    
risposta data 07.09.2018 - 15:02
fonte
0

Sono stato in grado di leggere i crls con Certutil. I record di checksum e gli elenchi ottenuti sono gli stessi di quelli di altre reti e del repository Microsoft . In realtà è solo una cache ISP come TorstenS ha gentilmente spiegato.

Qui è lo stesso fenomeno. Akamai punta a un server controllato da Embarq ISP.

    
risposta data 14.09.2018 - 23:51
fonte

Leggi altre domande sui tag