L'HTTPS è basato su una chiave privata sul lato utente? [duplicare]

0

L'HTTPS è basato sulla chiave privata sul lato utente?

Dove l'utente ottiene la chiave privata in primo luogo?

Supponiamo che l'utente ottenga la chiave privata scaricando un browser (Chrome, Firefox), quindi gli hacker non sono in grado di intercettare la chiave con un attacco man-in-middle?

Supponiamo che la chiave privata provenga dal numero di registrazione del sistema operativo Windows, quindi questo significa che gli hacker possono intercettare le chiavi private di tutti i download di browser Linux da un attacco man-in-middle perché Linux non ha il numero di registrazione?

Supponiamo che la chiave privata sia basata sulla funzione timer, quindi non è facile forzare la chiave privata?

Se HTTPS non si basa sulla chiave privata dell'utente, allora HTTPS non è molto sicuro?

    
posta guestguest 21.11.2013 - 20:04
fonte

2 risposte

3

Generalmente, una chiave simmetrica viene negoziata al volo e scambiata in modo sicuro tra il browser e il server. Un protocollo che consente alle persone di farlo (scambio di chiavi Diffie-Hellman) è spiegato in questo eccellente video di youtube: link .

I dati casuali per questo sono derivati utilizzando un numero qualsiasi di metodi; non è certamente statico e generalmente non avrà molto a che fare con il tempo corrente. L'esempio classico è quello di utilizzare il numero di microsecondi del tempo, il che è qualcosa che sapendo che l'ora del giorno non è d'aiuto. Altre fonti includono la tempistica di determinati eventi (pressioni di tasti e accessi al disco, come in Linux comune), il numero di fotoni riflessi da uno specchio semitrasparente in un momento (l'entropia derivata da quantum come molti acceleratori SSL), o l'azione di un metastabile oscillatore (il DRBG Intel) e molte altre cose. Questi dati casuali vengono raccolti ogni volta che è necessario, anche se in pratica a volte può essere memorizzato in un pool per un uso successivo (che può essere anche una vulnerabilità, ma questo è un altro argomento).

Dato che la chiave è abbastanza casuale, è necessario fare un sacco di bruteforce per ottenerlo. Se ingrandissi la quantità di entropia che potevi usare per la tua chiave, e il cipher usasse una chiave a 256-bit (AES-256, ecc.), Dovresti provare un sacco di volte (2 ^ 256 * 0.50 tentativi darebbero hai una probabilità del 50% di recuperare la chiave). In pratica, molte persone usano meno entropia di questa e costruiscono il resto della chiave deterministicamente, il che significa che se usassero solo 64 bit di entropia quella formula cambierebbe in 2 ^ 64 * 0.50, purché sapessi esattamente come la chiave è stata generata. Per lo scambio di chiavi DH come ho detto sopra, la matematica è in realtà un po 'più complessa perché devi tener conto del fatto che stai scegliendo due numeri casuali e non uno.

Questo è un sacco di chiavi, e le probabilità che la maggior parte degli attaccanti ne rompa una da bruteforce prima che tu abbia smesso di usarla sono molto minime.

    
risposta data 21.11.2013 - 21:56
fonte
2

Is HTTPS it based on private key on user side?

Parzialmente, sì.

Where does the user get the private key in the first place?

Il browser genera automaticamente una chiave privata casuale.

Suppose the user gets the private key by downloading a browser (Chrome, Firefox), then isn't hackers able to intercept the key by man-in-middle attack?

La chiave non fa parte del browser, viene generata al volo.

Suppose private key comes from Windows OS registration number, then does this mean hackers can intercept private keys of all Linux browser downloads by man-in-middle attack because Linux does not have registration number?

La stessa risposta di sopra

Suppose the private key is based on timer function, then isn't it easy to brute force the private key?

Perché dovrebbe essere? C'è un po 'di casualità.

    
risposta data 21.11.2013 - 20:09
fonte

Leggi altre domande sui tag