output della catena di certificati openssl

Question

output della catena di certificati openssl

#1 da (2 voti)
#2 da (1 voti)

1

Leggevo la guida "Sicurezza con HTTPS e SSL" per gli sviluppatori Android e leggendo questo paragrafo .

Il paragrafo discute il fatto che i server non restituiscono sempre l'intera catena di certificati durante un handshake SSL, spesso restituiscono solo il certificato del server e la CA radice della catena. La catena viene mostrata usando openssl come: openssl s_client -connect egov.uscis.gov:443

Questo mi ha dato qualche dubbio:

Il paragrafo afferma che i browser, per gestire questa configurazione del server, memorizzano semplicemente le CA intermedie quando visitano siti che si trovano in server che forniscono una catena completa di certificati e quando visitano un altro sito che si trova in un server che fornisce solo il i certificati "leaf" e "root" usano i certificati della CA intermedia della cache per seguire la catena. Ma cosa succede se un browser visita un sito che si trova in un server che restituisce solo il server ei certificati "root" in un momento in cui il browser non ha ancora memorizzato nella cache i certificati delle CA intermedie? Si verificherà un errore di autenticazione?
In che modo un browser segue l'intera catena di certificazione se riceve solo il server e il certificato della CA radice? Per quanto ne so, il processo è qualcosa di simile a una funzione ricorsiva che esamina la firma del certificato, la decrittografa e controlla se il risultato della decifratura coincide con il certificato del passo corrente. Tuttavia, se vengono forniti solo il server ei certificati CA radice, il processo deve terminare con un errore al secondo passaggio, poiché (se più di una CA è coinvolta nella catena di certificati) il certificato del server non è stato firmato direttamente dal root CA ...

Penso di aver frainteso qualcosa nella procedura di verifica PKI ... Potresti per favore chiarirmi e farmi capire dove mi sbaglio?

------ EDIT

Grazie per le buone risposte, quindi mi stai dicendo che quando l'articolo che ho linkato afferma "non è raro configurare un server per non includere la necessaria CA intermedia". si riferisce ai certificati CA intermedi NON INCLUSI la CA radice destra?

openssl public-key-infrastructure tls certificates

posta Alessio Martorana 27.09.2018 - 18:30

fonte

2 risposte

Leggi altre domande sui tag openssl public-key-infrastructure tls certificates

È normale che un sito web mostri una chiave API in formato testo che consente l'accesso completo alle informazioni personali? L'utilizzo della crittografia AES-256 garantisce davvero ulteriore sicurezza?

score 2 · Answer 1

... often return only the server certificate and the root CA of the chain

Anche se è un errore comune restituire solo i siti dei certificati server di solito non restituisce la CA radice (e anche questo non è rivendicato dall'articolo a cui si fa riferimento). Infatti, qualsiasi CA radice verrà ignorata dal client poiché solo la CA radice locale per il client deve essere utilizzata come un'ancora di trust e non una CA radice inviata dal peer. Vedi Framework dei certificati SSL 101: In che modo il browser verifica effettivamente la validità di un determinato certificato del server? per ulteriori informazioni.

... But what happens if a browser visits a site which is in a server returning only the server and the "roots" certificates at a time in which the browser haven't still cached certificates of the intermediate CA's? An authentication error would be triggered?

Questo dipende. Alcuni browser non riusciranno a convalidare il certificato. Altri si impegnano più duramente, ad esempio utilizzare l'accesso alle informazioni dell'autorità per trovare la CA intermedia mancante. Vedi AIA Fetching: risoluzione di una configurazione errata comune di SSL per ulteriori informazioni.

How exactly does a browser follow the entire certification chain if it only receives the server and the root CA certificate?

Ancora una volta, il browser non utilizza una CA radice inviata dal server, ma utilizza solo la CA radice attendibile a livello locale. Se il browser non è a conoscenza dei certificati intermedi e non riesce a trovarli con i metodi descritti, la convalida del certificato avrà esito negativo.

score 1 · Answer 2

Ci sono tre tipi di certificato coinvolti in un handshake TLS standard:

Il certificato del server per il server a cui si sta accedendo, trasmesso dal server. Questo avrà i dettagli del dominio (s) per cui è valido, la sua scadenza, ecc. Sarà firmato da qualche autorità di certificazione, che ha il proprio certificato di firma.
Uno o più certificati radice attendibili, noti anche come "trust ancore", che sono detenuti dal browser (o da qualsiasi altro client con cui ci si sta connettendo). Questi rappresentano terze parti che sono fidate di firmare i singoli certificati.
zero o più certificati intermedi, trasmessi dal server. Ciò consente al browser di costruire una "catena" di firme se non esiste un collegamento diretto tra il certificato del server e un'ancora di trust.

Nel caso più semplice, il certificato del server è stato firmato direttamente da una delle ancore di fiducia detenute dal browser; il browser può verificare tale firma e fidarsi immediatamente del certificato.

Tuttavia, se si è un'autorità di certificazione nuova o piccola, il proprio certificato di firma non sarà considerato attendibile dai browser, quindi nessuno dei certificati emessi sarà. Per risolvere questo problema, ottieni il tuo certificato di firma controfirmato da altre autorità di certificazione. Il browser deve vedere la prova di averlo fatto, sotto forma di un "certificato intermedio" trasmesso dal server.

Ad esempio:

Visita il link utilizzando MyAwesomeBrowser
Invia un certificato SSL firmato da Cheapo Certificates PLC
MyAwesomeBrowser esamina il certificato ed esamina chi è stato firmato da; quindi cerca nel suo trust store un'ancora di attendibilità corrispondente: nota che il server non invia il certificato di root , o lo nomina esplicitamente; è dedotto dalle informazioni sulla firma nel certificato stesso del server
MyAwesomeBrowser non ha PLC Cheapo Certificates nel suo trust store, quindi per impostazione predefinita il certificato - e quindi il sito web - non sarà considerato affidabile

Per risolvere questo problema:

Certificati di Cheapo PLC ottiene Fancy Enterprise Security Corp per contro-firmare il loro certificato di origine, producendo un certificato intermedio
Il proprietario di some-store.example.com configura il proprio server per inviare questo certificato intermedio e il relativo certificato del server; se non lo fanno, non c'è alcuna garanzia che il browser possa mai scoprire questo certificato intermedio
MyAwesomeBrowser verifica che il certificato del server corrisponda al certificato intermedio e quindi procede a verificare che il certificato intermedio sia attendibile
MyAwesomeBrowser ha un certificato radice attendibile per Fancy Enterprise Security Corp, quindi è in grado di verificare la catena e si fida del sito

La memorizzazione nella cache descritta nell'articolo che colleghi, o la scoperta automatica menzionata da Steffen Ullrich, aumenta in modo efficace il pool di attendibilità che il browser può utilizzare: se il browser ha già ricevuto e verificato il certificato intermedio del PLC Cheapo Certificates, può usarlo per fidarsi di altre cose in futuro. Proprio come il certificato radice originario non è stato trasmesso dal server ben configurato, il browser può capire quando utilizzare questo intermedio memorizzato nella cache in base al certificato con cui è stato presentato.