Chiarimento specifico su come la chiave pubblica del server https è attendibile

1

Conosco il concetto generale di funzionamento dei certificati digitali: ad es. il server "firma" il messaggio che desidera inviare al client utilizzando la sua chiave privata e invia un messaggio di digest e sul lato ricevente il client SA la chiave pubblica del server e può verificare che il messaggio sia effettivamente autentico (proviene dal server e non viene modificato in transito) utilizzando una funzione di decrittografia e controllando il contenuto del messaggio, è anche digerire e confermare che il messaggio ricevuto è autentico.

La domanda è: come può il client dire che la chiave pubblica del server inviata in chiaro (suppongo che sia inviata nella risposta ciao al server) sia autentica? Posso capire che le CA di grandi dimensioni hanno i loro certificati già installati sul computer client, ma se il server invia un certificato firmato ad esempio da Digicert, come posso dire al cliente che questo è effettivamente il caso (forse un MIM ha intercettato l'handshake di Ssl cambiando le cose)?

Perchiarirelecosehoaggiuntol'immaginechedescriveilprocessomedianteilqualeilclientverificachelafirmadelcertificatosiareale."Quando il browser riceve il certificato, controlla l'autorità di firma. Se si tratta di un'autorità di firma pubblica e rispettata, il browser conoscerà già la sua chiave pubblica (i browser sono forniti con i certificati di molte autorità di firma preinstallate), quindi può verificare la firma "Domanda: la chiave pubblica dell'autorità di firma deve essere comunicata in qualche modo al client (anche se tale CA è memorizzata localmente, come fai a sapere che cosa usa il server di origine?). Come viene fatto questo processo?

    
posta Ghita 01.10.2015 - 13:50
fonte

2 risposte

1

Ho intenzione di espandere il mio commento in una vera risposta. Penso che la confusione qui sia collegata a un fraintendimento di come funzionano le firme digitali.

Ecco un semplice processo per la creazione di un certificato autofirmato:

  1. Genera una coppia di chiavi pubblica / privata.
  2. Crea un file con la mia chiave pubblica e il mio nome che assomiglia a:

    {public_key, my_name}

  3. Calcola un hash crittografico di quel file (ad esempio sha1) e crittografalo con la mia chiave privata:

    hash = sha1({public_key, my_name}) encrypted_hash = encrypt(hash, private_key)

  4. Aggiungi l'hash crittografato alla fine del file.

A questo punto, il certificato dovrebbe assomigliare a:

{public_key, my_name, encrypted_hash}

Per verificare questo certificato, un client segue questi passaggi:

  1. Calcola hash sha1 del certificato:

    test_hash = sha1({public_key, my_name})

  2. Confronta questo hash all'hash decodificato usando public_key come chiave:

    decrypted_hash = decrypt(encrypted_hash, public_key)

  3. Se decrypted_hash = test_hash, il certificato è un certificato autofirmato valido.

La grande immagine di questo articolo di Wikipedia mi ha davvero chiarito le cose quando per la prima volta volevo girare la testa su questa roba:

Wikipedia: certificato di chiave pubblica

    
risposta data 01.10.2015 - 21:28
fonte
3

I can understand that large CA have their certificates already installed on the client machine

Questo è tutto. È precaricato sui client. Nessuna magia.

È necessario ottenere i propri ancore di fiducia (certificati CA radice) sui client PRIMA di poter avviare HTTPS affidabile. Non c'è modo di aggirare questo.

    
risposta data 01.10.2015 - 14:11
fonte

Leggi altre domande sui tag