La mia comprensione di come SSL funziona correttamente?

Naviga le tue risposte
0

Recentemente ho letto su SSL a 2 vie o autenticazione reciproca, ed ecco cosa ho capito finora:

L'autenticazione reciproca è un modo per il client di autenticarsi sul server, proprio come fa il server al client durante le connessioni SSL (a 1 via). I browser Web sono precaricati con i certificati di CA ben note, quindi, quando un sito Web invia la sua chiave pubblica (qualcosa come un file .cer?), Il browser può utilizzare il certificato della CA per capire se questo certificato ricevuto è valido o meno. Allo stesso modo, in SSL a 2 vie, il server deve avere il certificato della CA del cliente, oppure il certificato autofirmato che utilizza il certificato del cliente per confermare se il client è autentico o meno.

Di seguito sono riportate alcune domande specifiche su cui non sono ancora chiaro e sarei grato se qualcuno potesse verificare la mia comprensione:

  1. Il certificato che il server invia per SSL a 1 via contiene solo la chiave pubblica del server giusto? È necessariamente un file .cer o qualcosa di simile a un file .cer?
  2. I certificati CA con cui i browser vengono precaricati - sono come certificati .pfx? E avere solo questi certificati è sufficiente per il browser per confermare se il certificato ricevuto dal server è valido o no?
  3. Nel caso di certificati autofirmati, il server deve avere il certificato autofirmato .pfx da cui è stato creato il certificato client?

Credo sia chiaro dalle mie domande che non sono nemmeno sicuro che quando la chiave pubblica e quando la chiave privata è utilizzata per la crittografia / decrittografia, quindi quando rispondi a queste domande, sarei grato se potessi anche menzionare quali chiavi sono utilizzate per quale scopo quando viene utilizzato un certificato specifico.

    
posta GrowinMan 05.08.2014 - 08:58
fonte

1 risposta

1

Facciamo un riassunto da un file .cer o .pfx per un momento.

Che cos'è un certificato? È qualcosa che lega la chiave pubblica ad un nome (semplificazione eccessiva, ma dovrebbe essere OK per questa domanda). Il certificato è firmato da una terza parte (autorità di certificazione) che certifica che questa chiave pubblica "appartiene" a questo nome (ad esempio www.example.com ).

Ora, quando il browser Web si collega a un sito SSL, il sito risponde con il suo certificato. Il browser Web verifica quel certificato controllando se è stato firmato da un certificato radice attendibile (uno di precaricato con il browser). Se lo fa, il browser può stabilire una sessione sicura usando la chiave pubblica dal certificato (perché ora è sicuro che la chiave pubblica appartiene al sito a cui si sta connettendo).

In pratica i siti restituiscono non un singolo certificato, ma una catena di questi (il certificato foglia del sito e uno o più valori intermedi). Ciò non cambia molto il quadro generale, ma il browser ora deve verificare l'intera catena e assicurarsi che finisca in uno dei certificati radice attendibili (ovvero che il certificato foglia è firmato da un certificato intermedio e che l'intermedio è firmato da un certificato radice).

Come chiavi private / pubbliche ... I certificati non contengono chiavi segrete o private; contengono solo la chiave pubblica dell'entità. In breve, la parte che dimostra la propria identità deve possedere una chiave privata corrispondente al suo certificato. Con SSL a 1 via significa che il server deve avere una chiave privata corrispondente al suo certificato; con 2 vie questo significa che quel client deve avere anche una chiave privata corrispondente al suo certificato. Chiunque abbia una chiave privata corrispondente a un certificato può impersonare il titolare del certificato.

Per le tue domande:

  1. Il certificato è una chiave pubblica + nome + altre informazioni; nessun dato privato in là;
  2. I certificati precaricati sono esattamente identici a quelli restituiti dal server (cioè senza dati segreti); la "magia" è che sono fidati dal sistema per impostazione predefinita, quindi saranno considerati attendibili anche altri certificati firmati da quei certificati attendibili;
  3. Stai parlando dell'autent client qui? Il server richiede solo il certificato del client che può fidarsi (i certificati autofirmati potrebbero soddisfarlo) e il certificato client non deve assolutamente contenere la chiave privata del client.

Ho provato a semplificare un po 'le cose, quindi non sono accurate al 100% e c'è spazio per il pignolo :) Ma spero che questo aiuti a capire meglio le basi.

    
risposta data 05.08.2014 - 09:48
fonte

Leggi altre domande sui tag

Posso scrivere il token CSRF su uno script Basis Authentication Protocol: un attacco concreto