Certificato root SSL facoltativo?

Naviga le tue risposte
23

Forse ho avuto l'impressione sbagliata su come i server dovrebbero essere configurati e su quali certificati vengono effettivamente inviati durante il messaggio del server ciao certificato. Mi sono imbattuto in questo oggi da Symantec / VeriSign:

Root installed on the server. For best practices, remove the self-signed root from the server. The certificate bundle should only include the certificate's public key, and the public key of any intermediate certificate authorities. Browsers will only trust certificates that resolve to roots that are already in their trust store, they will ignore a root certificate sent in the certificate bundle (otherwise, anyone could send any root).

Se questo è vero, e il cert root non ha bisogno di essere installato sul server, beh, ecco quello che pensavo di sapere sulla corretta configurazione del server e su come la catena viene convalidata alla radice. Poi di nuovo, quando guardo questa domanda , sotto la sezione Certificati e Autenticazione di risposta di Thomas Pornin dice:

So the client is supposed to do the following:

  • Get a certificate chain ending with the server's certificate. The Certificate message from the server is supposed to contain, precisely, such a chain.

Questo dice praticamente l'opposto del messaggio di Symantec / VeriSign sopra, a meno che non stia fraintendendo qualcosa. Quindi:

  1. Un server ha bisogno di installare la catena completa, inclusa la radice? In caso contrario, che cosa utilizza un browser per confrontare per la convalida poiché il server non fornirà il suo certificato di root durante l'handshake? Semplicemente guarda il certificato di identità e prendilo da lì? (Come aprire un certificato di identità sul computer locale e vedere la catena completa nel percorso di certificazione?)

  2. Di nuovo, se questo è vero, che dire delle app client stand-alone che utilizzano le librerie SSL? Ciò dipenderà dall'applicazione poiché potrebbe avere metodi di costruzione dei percorsi diversi per una radice attendibile rispetto a un browser?

posta user53029 13.08.2014 - 21:11
fonte

4 risposte

26

Il server invia sempre una catena. Come per lo standard TLS , la catena può includere o meno il certificato di base stesso; il client non ha bisogno di quella radice poiché ce l'ha già. E, in effetti, se il client non ha già la radice, non sarà di aiuto riceverlo dal server dato che una radice può essere considerata attendibile solo in virtù dell'essere già lì .

Ciò che Symantec dice è che raccomandano di non inviare la radice, solo il resto della catena. Questo ha senso: dato che la root è inutile ai fini della validazione, si può anche evitare di inviarlo e salvare 1 kB circa di banda dati per connessione.

In ogni modo:

  • Il certificato del server, con la sua catena, non è per il server. Il server non ha utilità per il proprio certificato. I certificati sono sempre per altre persone (qui, il cliente). Ciò che viene utilizzato dal server è la sua chiave privata (che corrisponde alla chiave pubblica nel suo certificato). In particolare, il server non ha bisogno di fidarsi del proprio certificato o di qualsiasi CA che lo ha emesso.

  • In TLS, il server dovrebbe inviare una catena; e il client dovrebbe in qualche modo utilizzare la chiave pubblica del server per l'handshake. Il client è libero di "conoscere" quella chiave pubblica in qualsiasi modo desideri, anche se ovviamente è previsto che il client ottenga la chiave pubblica del server dalla catena di certificati che il server ha appena inviato. I browser cercheranno principalmente di utilizzare la catena inviata dal server (provando a collegarlo sotto una delle radici già considerate affidabili dal browser); in caso di errore, cercheranno di costruire altre catene basate su certificati CA intermedi che già conoscono o possono scaricare al volo.

    Nelle applicazioni autonome, gli scrittori di applicazioni sono liberi di configurare o ignorare quel passaggio in modi arbitrari, il che può essere utile se la chiave pubblica del server può essere codificata nel codice dell'applicazione (nel qual caso la catena inviata dal server è appena completamente ignorato). Sfortunatamente, la libertà di implementare un passo di convalida del certificato personalizzato è anche la libertà di wallop sicurezza, pugnalarlo a morte e quindi gettare il suo cadavere in un fosso. Succede troppo spesso.

risposta data 13.08.2014 - 21:23
fonte
4

what does a browser use to compare against for validation since the server won't be supplying its root cert during the handshake

L'intera idea del controllo dei certificati è che i client hanno alcuni certificati di root che si fida (forniti con il browser o il sistema operativo) e che convalida il certificato inviato dal browser contro questo ancoraggio di fiducia locale.

Ciò significa che il server non ha bisogno di (e non dovrebbe) inviare il certificato di root al client, perché questo certificato di root dovrebbe essere già presente ai client. Se invia ancora il certificato di root, il client semplicemente lo scarterà, cioè non lo farà fidati di qualsiasi certificato root inviato dal server.

Again if this is true what about stand-alone client apps that use SSL libraries? Will this depend on the application since it may have different path building methods to a trusted root vs a browser?

La procedura di verifica di base tra browser e librerie SSL è la stessa. Ci sono alcune differenze nella costruzione dei percorsi nei casi limite tra openssl e browser (vedi link ) e la verifica del nome host della destinazione rispetto al / i nome / i nel certificato del server è spesso errata o addirittura non esistente al di fuori dei browser comuni.

    
risposta data 13.08.2014 - 21:24
fonte
4

Invio la radice quando è conveniente farlo.

Se il client si fida della root, non fa alcuna differenza se lo si invia o meno.

Quando il client non riconosce la root, nella mia esperienza il client MS Windows produce messaggi diagnostici molto meno confusi se la root non affidabile è stata fornita nella catena.

Per quanto riguarda il modo in cui sa quale root usare se non ne viene fornita una, il next-to-root (che deve essere nella catena fornita) contiene le informazioni di identificazione per la root, che il client usa per cercare il root nell'archivio del cliente.

    
risposta data 13.08.2014 - 22:15
fonte
2

Tieni presente che esistono software server (come IBM HTTP Server) che non verrà avviato se la CA principale non è inclusa nel keystore.

    
risposta data 13.08.2014 - 23:57
fonte

Leggi altre domande sui tag

Come rilevare i certificati SSL "falsi" dal server web Come funzionano le serrature Travel Sentry? (presumibilmente apribile solo dalle agenzie di sicurezza)