Modo corretto per ottenere certificati CA per la verifica

5

Voglio collegarmi in modo sicuro a un'API, ma non sono sicuro di come dovrei ottenere il certificato CA per il passaggio di verifica.

Ho visto alcune persone che hanno utilizzato i certificati per esempio:

openssl s_client -connect graph.facebook.com:443 -showcerts

Questo metodo consente di ottenere certificati sicuri? Dovrei usare qualche altro metodo?

Modifica: poiché non ci sono ancora morsi, forse un esempio di ciò di cui sono preoccupato aiuterà. Dato che il punto principale di SSL (come ho capito) è quello di contrastare gli attacchi MITM, come si possono ottenere i certificati in modo tale che loro non siano soggetti a un MITM, rendendo così necessaria la successiva verifica?

    
posta 13.12.2011 - 23:26
fonte

3 risposte

2

Ho visto questo fatto con l'autenticazione della chiave SSH per telefono. La procedura prevedeva la generazione di chiavi private e pubbliche e l'invio del pubblico al provider di hosting via email. Poi mi telefonavano, leggevano metà dell'impronta digitale e mi chiedevano di leggere l'altra metà. Se corrispondono, metterebbero la mia chiave pubblica sul server e potrei accedere.

È improbabile che ciò sia pratico per la verifica dei certificati SSL di Facebook, tuttavia il punto chiave è che la verifica è stata eseguita utilizzando un metodo diverso rispetto al trasferimento originale, il che rende il lavoro di un potenziale aggressore molto più difficile.

Se puoi richiedere il certificato utilizzando un altro computer su una connessione Internet diversa e confrontarlo con quello che hai, puoi essere ragionevolmente certo di avere il certificato corretto.

SSL ha catene di trust che le chiavi SSH non hanno, quindi dovrebbe essere adeguato per verificare i certificati CA di root e usarli per verificare il certificato di destinazione.

Su Ubuntu, c'è un pacchetto ca-certificates che contiene i certificati di cui i manutentori di Ubuntu si fidano. I certificati stessi possono essere trovati in /usr/share/ca-certificates . Altre distribuzioni Linux avranno pacchetti simili.

    
risposta data 14.12.2011 - 10:09
fonte
2

Sto solo leggendo questo e vedo che hai una risposta che funziona per te ... ma la risposta davvero nerd è "dipende". Se stai cercando di ottenere un certificato server SSL, qualsiasi colpo al server SSL ti porterà il certificato allo stesso modo - il server lo offrirà e darà prova di possesso come parte del protocollo SSL.

La decisione critica è decidere se fidarsi o meno del certificato.

Un certificato ha diversi elementi:  - informazioni sul suo proprietario  - informazioni sul suo emittente  - una catena di certificati che porta a un emittente di root  - informazioni sulla validità.

Un semplice controllo è "è valido il certificato" - se puoi guardare i dati, puoi vedere le date di inizio e di fine validità. A seconda di ciò che stai facendo, puoi controllare a mano o codificare qualcosa da verificare su ciascuna connessione.

Successivamente, potresti voler capire se ti fidi del suo emittente. I certificati autofirmati sono intrinsecamente meno affidabili, perché chiunque può firmarlo. I browser dispongono di un archivio di certificati attendibili di "buone scommesse" comuni - emittenti certificati che producono commercialmente certificati. Ma ci sono altri emittenti for-pay in circolazione, così come prodotti aziendali interni che possono essere perfettamente affidabili per i tuoi scopi. Il passaggio 1 è decidere quale certificato emittente considerare attendibile, ovvero configurare un trust store localmente. Il passaggio 2 sta verificando che il certificato presentato dal server non stia mentendo quando rivendica un emittente - si tratta di un controllo crittografico sulla firma digitale del certificato. Il passaggio 2 deve essere ripetuto per ciascun certificato nella catena ...

Infine, per maggiore sicurezza, potresti voler controllare che il certificato non sia revocato. È fattibile attraverso un paio di protocolli PKI, o manualmente sulla maggior parte dei siti web di emittenti commerciali. Un certificato può contenere informazioni su come verificare il suo stato come parte delle sue informazioni pacchettizzate (un punto di distribuzione CRL o estensione AIA) o potrebbe essere necessario google per trovare la risposta.

La distanza fino alla verifica del certificato del server deve essere commisurata al rischio delle informazioni che fornirai al server.

    
risposta data 16.12.2011 - 23:01
fonte
1

Un certificato è firmato. Ciò significa che viene fornito con la propria sicurezza. La validità di un certificato deriva dalla sua firma da parte di un'autorità di certificazione, non dal modo in cui lo si ottiene. Durante i primi passi di una connessione SSL / TLS ("handshake"), il client deve acquisire una conoscenza affidabile della chiave pubblica del server; il client può farlo in qualsiasi modo lo ritenga opportuno, ma spesso implica trovare un percorso del certificato , ovvero un insieme di certificati che si conclude con un certificato che contiene il nome del server e la chiave pubblica del server. Per semplificare le operazioni, il server include un percorso potenziale in uno dei messaggi di handshake che invia al client.

Validazione di un percorso di certificato implica la verifica della firma su ciascun certificato, per quanto riguarda la chiave pubblica contenuta nel certificato precedente (ci sono molte altre cose che sono controllate, vedi la sezione 6 di RFC 5280 se sei davvero annoiato un giorno). Il punto della firma è di proteggere contro l'alterazione e dimostrare la provenienza. In che modo hai ottenuto il certificato è irrilevante; del resto, potrebbe esserti stato consegnato dal Diavolo stesso, non avrà alcun impatto sulla sicurezza.

Tuttavia, devi ancora essere da qualche parte. Come accennato sopra, la firma di ciascun certificato nel percorso deve essere verificata con la chiave pubblica contenuta nel certificato precedente . Come controlliamo la firma sul primo certificato nel percorso? Per questo, abbiamo bisogno di un trust anchor : è un nome e una chiave pubblica che è noto a priori , ad es. è incorporato nel software client (dopotutto, ti fidi del software stesso per non registrare tutti i dati scambiati e i tuoi colpi chiave, così puoi fidarti anche di questo con l'archiviazione di alcune chiavi pubbliche). Le ancore di sicurezza sono tradizionalmente codificate come certificati radice : non sono certificati reali (la loro firma è fittizia, o spesso una "auto-firma" che non ha alcuna funzione se non quella di riempire lo slot di una firma in un formato di certificato ) ma assumono ancora il formato esterno (come un mucchio di byte) di un certificato.

I "certificati radice" devono essere ottenuti in modo sicuro, poiché non possono essere verificati in alcun modo; tutta la tua fiducia viene da loro. Ecco una sbirciata (all'inizio) dell'elenco dei certificati radice incorporati in Firefox (cioè, i certificati che Mr Firefox ha trovato adatti al suo browser e che io, essendo un utente pigro, "confido" per impostazione predefinita):

    
risposta data 19.01.2012 - 14:42
fonte

Leggi altre domande sui tag