2010-10-14 9 views
9

Ho una piccola confusione handshake SSL tra browser e server in un tipico scenario di https web:Come si fa del browser generare chiave simmetrica durante handshake SSL

Quello che ho capito finora è che nel processo di handshake SSL, il client (browser in questo caso) crittografa una chiave simmetrica selezionata a caso con la chiave pubblica (certificato ricevuto dal server). Questo viene inviato al server, il server lo decrittografa (chiave simmetrica) con la chiave privata. Questa chiave simmetrica viene ora utilizzata durante il resto della sessione per crittografare/decrittografare i messaggi ad entrambe le estremità. Uno dei motivi principali per farlo è dato come crittografia più veloce utilizzando le chiavi simmetriche.

Domande 1) In che modo il browser seleziona e genera questa chiave simmetrica selezionata "casualmente"?

2) Do sviluppatori (o/e gli utenti del browser) hanno il controllo su questo meccanismo di generazione di chiavi simmetriche?

+0

Il cliente non genera la chiave di sessione; non lo cripta; e non lo trasmette. La chiave di sessione deriva da un protocollo di chiave d'accordo. La tua descrizione è fondamentalmente errata. La tua domanda è fondata su un falso presupposto. – EJP

risposta

8

Here è una buona descrizione di come funziona HTTPS realizzazione del collegamento. Mi impegno a fornire sintesi come chiave di sessione viene acquisita da entrambe le parti (client e server), questo processo è noto come "un protocollo d'intesa chiave", ecco come funziona:

  1. il client genera il 48 byte “pre- maestro segreto "valore casuale.
  2. Il client esegue il pad di questi byte con dati casuali per rendere l'input uguale a 128 byte.
  3. Il client lo crittografa con la chiave pubblica del server e la invia al server.
  4. Poi Master Key è prodotto da entrambe le parti in modo seguente:

    master_secret = PRF(
        pre_master_secret, 
        "master secret", 
        ClientHello.random + ServerHello.random 
    ) 
    

La PRF è la “pseudo-casuale funzione” che è anche definito nel specifiche ed è molto intelligente. Esso combina il segreto, l'etichetta ASCII, e i dati seme che gli diamo tramite keyed-Hash Message Authentication Code (HMAC) versioni sia MD5 e SHA-1 hash funzioni. La metà dell'input viene inviata a ciascuna funzione di hash. È intelligente perché è abbastanza resistente agli attacchi, anche a fronte dei punti deboli di in MD5 e SHA-1. Questo processo può fornire feedback su se stesso e iterare per sempre per generare il numero di byte necessario.

Seguendo questa procedura, otteniamo un "master secret" da 48 byte.

+0

Il client non genera la chiave di sessione; non lo cripta; e non lo trasmette. La chiave di sessione deriva da un protocollo di chiave d'accordo. – EJP

+0

@EJP hai ragione, la mia risposta è stata completamente errata, l'ho riscritta. Si prega di controllare e dimmi se pensi che sia meglio ora. – Andrey

Problemi correlati