In che modo l'utente riceve il certificato del server?

8

Immaginiamo che il computer dell'utente voglia parlare con un server per la prima volta nella storia tramite https. Il computer invia un messaggio di saluto, il server invia la sua chiave pubblica e il certificato, contenente: nome del server, nome della CA, data di scadenza e hash della chiave pubblica del server, crittografato con la chiave privata della CA (ovvero firma digitale).

Ma cosa impedisce a un hacker di cambiare il "nome del server" nel certificato? Il server crittografa tutti questi campi con la sua chiave pubblica (del server)? E come fa l'utente a sapere che il sito che sta per visitare corrisponde al certificato. L'utente confronta gli URL?

Se il certificato non è crittografato, l'hacker può inviare all'utente il proprio certificato, firmato con la stessa CA, ma con il campo server's urls modificato. Quindi come funziona?

    
posta yanpas 15.12.2015 - 08:46
fonte

2 risposte

13

Tutti i certificati sono firmati per intero (protetti dalle modifiche), quindi non è possibile modificare il nome o altri dati al suo interno.

Il certificato del server a cui ci si connette è firmato dal certificato dell'emittente, che a sua volta può essere firmato da altri certificati più in alto, questa è la catena di certificati. La parte superiore, alias root, è firmata da sola. Se apporti modifiche a uno di questi certificati, non avrà più una firma valida. Se sostituisci la chiave pubblica e la firma, i seguenti certificati non possono più verificare l'utilizzo di questo certificato.

Il proprietario di un certificato di origine è in grado di modificare qualsiasi cosa nel proprio certificato a proprio piacimento, in modo che possano ad esempio estendere la validità (sostituire la data di scadenza), mantenendo comunque tutti i certificati emessi validi.

Ci si aspetta che i browser abbiano tutta la root corrente e alcuni certificati intermedi già memorizzati, quindi puoi verificare tutti i certificati emessi da qualcuno di quelli con la sicurezza di come hai acquisito in sicurezza il tuo sistema operativo o browser (che potrebbe non essere molto sicuro, dopo tutto).

Se gli utenti confrontano gli URL è una cosa diversa: il browser ti avviserà se desideri accedere a un sito e il certificato viene emesso per un nome diverso, ma se il nome digitato è fuorviante e ha un certificato valido , è ancora un problema. Si prevede che le autorità competenti rilasciano certificati solo per i nomi che possono garantire, e hanno inventato quegli EV verdi - i certificati di verifica dell'estensione, che controllano ancora di più.

Ad esempio, se si desidera accedere a storemymoneypal, ma erroneamente storemymoneypai, e il sito si presenta come storemymoneypaI (con una i maiuscola alla fine), è difficile notare la differenza: è questo che si prevede che la verifica eviti . Con i caratteri unicode ci sono personaggi ancora più simili, ma questi pericoli sono ben noti e qualsiasi CA valga la pena di guadagnarsi la fiducia dei produttori di browser ne sarà a conoscenza.

    
risposta data 15.12.2015 - 09:23
fonte
0

funziona nel modo seguente: 1. admin genera una coppia di chiavi pubbliche e private sul server. 2. chiave pubblica e altre informazioni (nome del dominio, contatto, organizzazione, ecc.) 3. CA attendibile (come verisign) verifica tali dichiarazioni 4. se tutto va bene, la CA attendibile firma tutte le informazioni fornite e invia un certificato ad amministratore (ecco come guadagna CA dal cliente) 5. ogni volta che un client accede a HTTPS, riceverà tale certificato e dovrà verificare se il certificato è ok, valido e non manomesso. Poiché la macchina / browser del cliente (windows, linux) ha un elenco di tutte le CA attendibili, il client può quindi verificare in modo efficiente il certificato.

In questo modo, se un hacker cambia certificato, il client rileverà tali modifiche.

    
risposta data 15.12.2015 - 12:05
fonte

Leggi altre domande sui tag