Come funziona HTTPS? | Linuxiano.it
Privacy Policy

Come funziona HTTPS?

Come funziona HTTPS? – Guida per principianti

Nelle telecomunicazioni e informatica l’HyperText Transfer Protocol over Secure Socket Layer (HTTPS), (anche noto come HTTP over TLS, HTTP over SSL e HTTP Secure) è un protocollo per la comunicazione sicura attraverso una rete di computer utilizzato su Internet.

La porta utilizzata generalmente (ma non necessariamente) è la 443. Consiste nella comunicazione tramite il protocollo HTTP (Hypertext Transfer Protocol) all’interno di una connessione criptata, tramite crittografia asimmetrica, dal Transport Layer Security (TLS) o dal suo predecessore, Secure Sockets Layer (SSL) fornendo come requisti chiave:

  • un’autenticazione del sito web visitato
  • protezione della privacy (riservatezza o confidenzialità)
  • integrità dei dati scambiati tra le parti comunicanti.

Nel suo popolare funzionamento su Internet, HTTPS fornisce l’autenticazione del sito web e del server web associato con cui una delle parti sta comunicando, proteggendo la comunicazione dagli attacchi noti tramite la tecnica del man in the middle. Inoltre, HTTPS fornisce una cifratura bidirezionale delle comunicazioni tra un client e un server, che protegge la stessa contro le possibili operazioni di eavesdropping, (azione mediante il quale viene ascoltata segretamente la conversazione privata tra le parti senza il loro consenso) e tampering (letteralmente manomissione o alterazione della comunicazione) falsificandone i contenuti.[6] In pratica, tale meccanismo fornisce una garanzia soddisfacente del fatto che si sta comunicando esattamente con il sito web voluto (al contrario di un sito falso), oltre a garantire che i contenuti delle comunicazioni tra l’utente e il sito web non possano essere intercettate o alterate da terzi.

Storicamente, le connessioni HTTPS erano usate soprattutto per i pagamenti nelle transazioni sul World Wide Web, e-mail e per le transazioni sensibili all’interno dei sistemi informativi aziendali. Nel tardo 2000 e nei primi anni del 2010, HTTPS ha iniziato ad avere una larga diffusione e ampio utilizzo per proteggere l’autenticità delle pagine web, la sicurezza degli account utente e per mantenere private le comunicazioni, l’identità e la navigazione web dell’utente.

Problemi con HTTP e testo normale

Internet è un canale non affidabile di comunicazione. Quando invii o ricevi informazioni da un vecchio sito HTTP http: // www.example.com nel tuo browser, molte cose potrebbero accadere a metà strada dei tuoi pacchetti.

  1. Un cattivo attore può intercettare la comunicazione, copiare i dati per se stessi, prima di inviarlo di nuovo sul canale verso di te o il server con cui stavi parlando. Senza la conoscenza di entrambe le parti, l’informazione è compromessa. Dobbiamo garantire che la comunicazione sia privata .
  2. Un cattivo signore può modificare le informazioni mentre vengono inviate sul canale. Il signor Rossi potrebbe aver inviato un messaggio “x” ma la signora Alice avrebbe ricevuto “y” dal Signor Rossi, perché un cattivo signore ha intercettato il messaggio e lo ha modificato. In altre parole, l’ integrità del messaggio è compromessa.
  3. Infine, e soprattutto, dobbiamo garantire che la persona con cui stiamo parlando sia effettivamente quella che dicono di essere. Tornando al dominio example.com . Come possiamo assicurarci che il server che ci ha risposto sia effettivamente il titolare legittimo di www.example.com? In qualsiasi punto della rete, è possibile essere indirizzati erroneamente a un altro server. Un DNS da qualche parte è responsabile della conversione di un nome di dominio, come www.example.com, in un indirizzo IP su Internet pubblico. Ma il tuo browser non ha modo di verificare che l’indirizzo IP tradotto DNS.

I primi due problemi possono essere risolti crittografando il messaggio prima che venga inviato su Internet al server. Vale a dire, passando a HTTPS. Tuttavia, l’ultimo problema, il problema dell’identità è dove entra in gioco un’autorità di certificazione.

Avvio di sessioni HTTP crittografate

Il problema principale con la comunicazione crittografata su un canale non sicuro è “Come possiamo avviarlo?”

Il primo passo coinvolgerebbe le due parti, il browser e il server, per scambiare le chiavi crittografiche da scambiare sul canale non sicuro. Se non hai familiarità con il termine chiavi, pensa a loro come una password veramente lunga generata a caso con la quale i tuoi dati verranno crittografati prima di essere inviati su un canale non sicuro.

Bene, se le chiavi vengono inviate su un canale non sicuro, chiunque può ascoltarle e compromettere la sicurezza della tua sessione HTTPS in futuro. Inoltre, come possiamo credere che la chiave inviata da un server che dichiara di essere www.example.com sia effettivamente il proprietario effettivo di quel nome di dominio? Possiamo avere una comunicazione crittografata con una parte malintenzionata mascherata da un sito legittimo e non conoscere la differenza.

Quindi, il problema di garantire l’identità è importante se vogliamo garantire uno scambio di chiavi sicuro.

Autorità di certificazione

Potresti aver sentito parlare di LetsEncrypt, DigiCert, Comodo e alcuni altri servizi che offrono certificati TLS per il tuo nome di dominio. Puoi scegliere quello che si adatta alle tue necessità. Ora, la persona / organizzazione che possiede il dominio deve dimostrare in qualche modo alla propria autorità di certificazione di avere effettivamente il controllo sul dominio. Questo può essere eseguito creando un record DNS con un valore univoco, come richiesto dall’autorità di certificazione, oppure è possibile aggiungere un file al server web, con contenuti specificati dall’autorità di certificazione, la CA può quindi leggere questo file e conferma di essere un valido proprietario del dominio.

Quindi negoziare un certificato TLS con la CA e il risultato è una chiave privata e un certificato TLS pubblico emesso sul tuo dominio. I messaggi crittografati dalla tua chiave privata possono quindi essere decifrati dal certificato pubblico e viceversa. Questo è noto come crittografia asimmetrica.

I browser client, come Firefox e Chrome (a volte anche il sistema operativo) hanno la conoscenza delle autorità di certificazione. Queste informazioni sono inserite nel browser / dispositivo fin dall’inizio (vale a dire, quando vengono installate) in modo che sappiano che possono fidarsi di determinate CA. Ora, quando tentano di connettersi a www.example.com su HTTPS e visualizzare un certificato emesso da, ad esempio DigiCert, il browser può effettivamente verificare che l’utilizzo delle chiavi memorizzate localmente. In realtà, ci sono alcuni passaggi intermedi ad esso, ma questa è una buona panoramica semplificata di ciò che sta accadendo.

Ora che il certificato fornito da www.example.com può essere considerato affidabile, viene utilizzato per negoziare una chiave di crittografia simmetrica univoca che viene utilizzata tra il client e il server per il resto della sessione. Nella crittografia simmetrica, una chiave viene utilizzata per crittografare e decrittografare e di solito è molto più veloce della sua controparte asimmetrica.
nuances

Se l’idea di TLS e sicurezza Internet ti affascina, puoi approfondire questo argomento scavando in LetsEncrypt e nella loro CA gratuita TLS. C’è molto più minuzioso per questa intera trafila di quanto affermato sopra.

Altre risorse che posso consigliare per saperne di più su TLS sono il blog di Troy Hunt e il lavoro svolto da EFF come HTTPS Everywhere e Certbot. Tutte le risorse sono libere di accedere e molto economiche da implementare (devi solo pagare per la registrazione del nome di dominio e addebiti orari VPS) e ottenere un’esperienza pratica.

Grazie! per l’utilizzo della Guida di Linuxiano.

Trovi questo tutorial utile? Condividi con i tuoi amici per tenerlo in vita.
Sii il primo a commentare, apprezzo i tuoi suggerimenti. Per ulteriori domande potete commentare qui sotto.