Certificato SSL e siti HTTPS: come funzionano

 
 
 
 
 
Autore: Redazione ArgonavisLAB – 03/02/2022
 
 

Un certificato SSL è un certificato digitale che autentica l’identità di un sito web e consente di instaurare una connessione crittografata. SSL è acronimo di Secure Sockets Layer, un protocollo di sicurezza che crea un link crittografato fra un server web e un browser web.

SSL assicura che tutti i dati scambiati fra un client (il browser dell’utente) e un server web (o altro servizio, come ftp, ecc.), in generale fra due sistemi, rimangano impossibili da leggere. Utilizza algoritmi di crittografia allo scopo di rendere irriconoscibili i dati in transito, per impedire agli hacker di leggerli mentre vengono trasmessi sulla connessione.

Per stabilire una sessione tra client e server in modalità https , viene prima eseguita la fase di “handshake SSL” , che prevede

  • Scambio dei certificati pubblici
  • Scambio delle sequenze di byte necessarie per costruire la master secret
  • Verifica dell’autenticità dei certificati
  • Creazione della chiave “master secret” , univoca per ogni sessione e comune a entrambi i sistemi, e che verrà usata per crittografare tutta la sessione di navigazione del client sul server.
  • Messaggio di fine handshake, in cui viene verificato che tutto il processo sia stato regolare e la master secret sia utilizzabile.

Da questo momento può iniziare lo scambio dati tra client e server , tutto il traffico verrà crittografato , impedendo che un intruso sia in grado di leggere il traffico (sniffare), e possa introdursi nella sessione sostituendosi ad uno dei sistemi o di rubare delle informazioni.

Pertanto il certificato SSL assolve a tre funzioni

  • Autenticità: assicura che il server sia chi dice di essere , e non un clone falso.
  • Confidenzialità: definisce una chiave segreta comune ed unica per sessione , usata per crittografare il contenuto del messaggio.
  • Integrità: garantisce che i messaggi tra server e client sia integri e non modificati da un intruso.

La comunicazione SSL tra client e server avviene su quattro fasi

  1. Fase di hello : server e client si scambiano i certificati pubblici e delle sequenze di byte casuali ; il client verifica l’autenticità del certificato inviato dal server.
  2. Processo di costruzione della master secret , la chiave comune unica per ogni sessione, che sarà usata per cifrare il traffico.
  3. Fase di finished : client e server si scambiano il primo messaggio usando la master secret , verificano l’esito positivo e concludono la fase di handshake.
  4. Inizio trasmissione cifrata tra server e client , tramite protocollo SSL.

In conclusione:

Il canale definito durante la fase di SSL handshake è immune da attacchi attivi man-in-the-middle poiché il sistema Server viene autenticato con un certificato digitale.
Il client può comunicare la pre-master secret al sistema server in modo sicuro attraverso la chiave pubblica presente nel certificato del server.

Solo il client e il server , tra cui è iniziata la fase di handshake (tramite il meccanismo chiave pubblica-chiave privata) , possono costruire la stessa master secret, su cui poi si fonda la costruzione di tutte le chiavi segrete adottate nelle comunicazioni successive.

La sequenza corrispondente al pre-master secret viene generata dal client e comunicata per via cifrata al server.  La non predicibilità di questa sequenza è cruciale per la sicurezza del canale SSL.

Il messaggio di finished contiene tutte le informazioni scambiate nel corso dell’handshake. Lo scopo è effettuare un ulteriore controllo sulle comunicazioni precedenti per garantire che queste siano avvenute correttamente, che il client e il server dispongano della stessa Master Secret e che la comunicazione non sia stata oggetto di un attacco attivo.

Scendendo un poco nel dettaglio , abbiamo :

  1. Client hello
  • Il client manda al server un messaggio di “client hello”
  • richiede la creazione di una connessione SSL
  • specifica le prestazioni di “sicurezza” che desidera siano garantite durante la connessione (l’elenco delle cipher suite che e’ in grado di supportare)
  • invia una sequenza di byte casuali.
  1. Server hello
  • Il server manda al client un messaggio di “server hello”
  • seleziona la cipher suite che desidera
  • invia una sequenza di byte casuali
  • Se il client non riceve il messaggio di server hello , il client interrompe la comunicazione
  1. Invio certificato del server
  • Il server invia il suo certificato pubblico (il crt) e i certificati pubblici della catena di certificazione della CA (Intermedi e di root)
  1. Invio del messaggio server hello done
  • Il server invia il messaggio che definisce la conclusione dei messaggi per la definizione del tipo di protezione e relativi parametri.
  1. Verifica dei certificati
  • Il client verifica la data di validita’ del certificato , che la CA sia trust , che la firma apposta dalla CA sia autentica (controllo con la CA). Se il certificato non è stato emesso da una CA pubblica, viene segnalato l’errore e richiesto se accettare comunque il certificato.
  1. Costruzione della pre-master secret
  • Il client genera una sequenza di byte casuali
  • la cifra con la chiave pubblica del server ricevuta nei passi precedenti
  • spedisce la pre-master secret al server
  1. Server e client : Costruzione della master secret
  • Sia il server che il client conoscono le sequenze di byte casuali scambiate tra server e client durante le fasi di client hello e server hello ; e conoscono la pre-master secret
  • Server e client costruiscono la master secret (che sarà uguale per entrambi)
  • L’uso delle sequenze di byte casuali scambiate durante le fasi di hello , client e server) genera una master secret diversa per ogni sessione SSL ; un intruso non può riutilizzare i messaggi di handshake catturati sul canale per sostituirsi in una successiva comunicazione
  1. Message finished
  • E’ il primo messaggio protetto tramite master secret e cipher suite, che i due sistemi si scambiano
  • Il messaggio viene prima costruito dal client e mandato al server
  • Poi il server usando parte del messaggio inviato dal client , costruisce il proprio finished message e lo invia al client
  • nei due invii la struttura del messaggio è la stessa, ma cambiano le informazioni in esso contenute
  1. Fine della fase handshake
  • A questo punto la master secret è utilizzata dal client e dal server per costruire una propria tripla di dati
  • Le triple del client e del server sono diverse tra loro ma note a entrambi i sistemi: ciascuno usa la propria, il che aumenta la sicurezza delle comunicazioni.
  • Client e server sono pronti al colloquio cifrato e inizia la fase del protocollo SSL record
  1. Protocollo SSL record
  • Il canale sicuro approntato dal protocollo SSL handshake viene realizzato dal protocollo SSL record.
  • I dati sono frammentati in blocchi.
  • Ciascun blocco viene numerato, compresso e autenticato mediante l’aggiunta di un MAC cifrato mediate il cifrario simmetrico su cui client e server si sono accordati , trasmesso dall’SSL record utilizzando il protocollo di trasporto sottostante.
  • Il destinatario esegue un procedimento inverso sui blocchi ricevuti:
  1. decifra e verifica la loro integrità
  2. decomprime e riassembla i blocchi in chiaro
  3. consegna all’applicazione sovrastante.

 

Questo articolo, scritto da ArgonavisLAB , ha liberamente preso spunto da vari autori. Si ringraziano Kaspersky Lab e http://pages.di.unipi.it/bernasconi/CRI/ssl.pdf

3 Febbraio 2022

Il Certificato SSL tutela i visitatori e protegge i siti web dalle frodi

 
Autore: Redazione Argonavis – 18/11/2020
 
 

Quale certificato SSL scegliere?

Questa e’ la domanda che i nostri clienti ci pongono spesso quando decidono di proteggere i visitatori del proprio sito.

Tutti i certificati SSL proteggono la navigazione dell’utente finale mediante cifratura del traffico, indipendentemente dal tipo di certificato.

Esistono tre tipi di convalida, ovvero il procedimento con cui la Certification Authority ( CA ) convalida l’autenticità del richiedente il certificato.

In base al tipo di convalida, al certificato vengono aggiunte delle informazioni estese per identificare meglio il proprietario del certificato e, quindi, del sito.

  • DV (Domain Validation): con questo tipo di certificato viene validato il solo dominio, ovvero si convalida che il richiedente del certificato SSL sia effettivamente l’assegnatario del dominio e ne abbia il completo controllo.

Pro: protezione del traffico, certifica il dominio, basso costo, tempi brevi di emissione (pochi minuti).

Contro: il certificato non riporta nessuna informazione estesa, come il nome del proprietario del dominio.

  • OV (Organization Validation)

Con questo tipo di certificato, l’ente certificatorio ( la CA ) effettua una verifica societaria sul richiedente per garantirne l’esistenza. Le informazioni del richiedente sono contenute all’interno del certificato stesso. Chi effettua acquisti su un sito che fornisce questa tipologia di protezione ha la garanzia di acquistare da una società verificata.

Pro: protezione del traffico , costo medio, certifica il dominio e l’azienda (che viene inserita nel certificato stesso).

Contro: i tempi di emissione si allungano a 2/3 giorni, necessari per le verifiche.

  • EV (Extended Validation)

Si tratta di una validazione legata all’azienda richiedente che viene sottoposta a un processo di analisi molto accurato a seguito del quale il nome dell’azienda sarà sinonimo di attendibilità. All’interno di una barra verde nel browser viene mostrato il nome stesso dell’azienda, il che garantisce al visitatore la massima attendibilità dello store dal quale sta effettuando i propri acquisti.
Pro: protezione del traffico, costo medio/alto, certifica il dominio e l’azienda (che viene inserita nel certificato stesso) e attiva la barra verde del browser.

Contro: i tempi di emissione si allungano a 2/3 giorni, necessari per le verifiche.

I certificati possono anche essere emessi con le seguenti opzioni:

  • l’opzione Wildcard, che permette alle aziende di proteggere, con un solo certificato SSL, tutti i sottodomini del sito principale, ad esempio, www.dominio.it, ma anche b2b.dominio.it, e anche cloud.dominio.it, ecc…
  • l’opzione SAN (Subject Alternative Name), che permette alle aziende di inserire, all’interno dello stesso certificato, fino ad un massimo di 250 domini legati alla stessa società ma con “common name” differenti (esempio: shop.primodominio.it, www.secondodominio.com).

I certificati gratuiti

I certificati SSL, come quelli di “Let’s Encrypt”, possono essere gratuiti, ovvero forniti da una CA (Certificate Authority) no-profit, creati per proteggere quei siti web che non possono permettersi di acquistarne uno. Essi però non sono considerati ottimali per portali di carattere commerciale, dove sono previste transazioni di denaro o dove al suo interno sono custoditi dati sensibili.

Let’s Encrypt, infatti, non è in grado di fornire una protezione completa, ma tutela solo il MIM (Man In the Middle), crittografando le comunicazioni. Non prevede alcun tipo di validazione, ma fa apparire semplicemente il lucchetto verde vicino all’url del sito sui browser.

Non è previsto un controllo dell’effettiva proprietà del dominio da parte di chi attiva il certificato. Apparentemente però non c’è alcuna differenza tra un Certificato SSL a pagamento e uno gratuito.

Le versioni gratuite non permettono di certificare i domini di terzo livello, hanno una validità di 90 giorni , ma la cosa più importante è che non offrono nessuna tutela dal rischio di phishing, né garanzia o supporto.

Per ulteriori informazioni: dircom@argonavis.it

18 Novembre 2020

Protezione e controllo delle informazioni. Quali soluzioni ?

 

La crittografia è uno dei metodi più sicuri in assoluto per gestire con facilità le politiche di accesso e di condivisione delle informazioni, sia all’interno che all’esterno dell’organizzazione aziendale, riducendone il rischio di furto o di utilizzo non autorizzato.
E’ possibile proteggere documenti, endpoint (come smartphone, tablet, notebook, workstation, in parte o completamente), e-mail, dispositivi esterni (hard e flash drive). Le varie possibilità possono essere tra loro combinate al fine di raggiungere i più elevati standard di protezione da perdite accidentali o dolose.

Presentiamo alcune soluzioni che possono coprire le esigenze più comuni:

 

Proteggere e controllare sempre e ovunque i tuoi documenti
La soluzione IRM di Sealpath impedisce che informazioni riservate, ovunque esse siano, sulla rete aziendale, sulle reti dei clienti o dei partner, nel cloud (ad es. Box, Dropbox, ecc.) o su un dispositivo mobile, possano essere viste o usate da utenti non autorizzati.
IRM di Sealpath protegge i documenti riservati con crittografia persistente che accompagna i file ovunque essi siano; gestisce e controlla, attraverso una console centralizzata, chi accede ai documenti riservati, quando e con quale permessi (sola lettura, modifica, stampa, copia e incolla, ecc.) e registra i dettagli degli accessi ai documenti.
La soluzione consente inoltre di dimostrare che i documenti con dati personali e/o sensibili sono protetti con sistemi di crittografia e con misure tecniche che assicurano che l’accesso ad essi sia impossibile senza autorizzazione, rispondendo così anche al principio di accountability del GDPR.

 

Cifratura a livello di file, disco o dispositivo
La crittografia di Kaspersky Endpoint Security for Business Advanced, con certificazione FIPS 140-2 e completamente trasparente per l’utente, protegge i dati riservati sui dispositivi fissi e portatili. La tecnologia integrata consente di applicare in maniera centralizzata le policy di crittografia dei dati aziendali a livello di file, disco o dispositivo removibile.

 

End to end email encryption
Il modulo di Email Encryption di Libra Esva Email Security Gateway è una funzionalità di crittografia end-to-end che protegge le e-mail direttamente sul tuo gateway di posta.
La crittografia end-to-end garantisce che solo il destinatario previsto possa leggere il contenuto. Neanche gli amministratori possono leggere il messaggio senza la password.
Ogni volta che il destinatario riceve un messaggio crittografato viene informato sui metodi disponibili per leggere e decodificare il messaggio e, attraverso un apposito servizio web sul gateway ESVA del mittente, può accedere al messaggio e ai contenuti.

 

E-mail crittografate e firmate con certificato personale
I certificati email personali consentono agli utenti di firmare e crittografare le e-mail in modo digitale dimostrandone la paternità, impedendone la manomissione e garantendo la riservatezza attraverso la cifratura. Qualunque sia il sistema di posta utilizzato e’ possibile firmare l’email con il proprio certificato personale e crittografarne il contenuto purché anche il destinatario sia in possesso di un certificato email personale.

 

Storage criptato
IStorage produce storage portatili (flash drives, hard drive, ssd drive) ad attivazione a mezzo PIN, con crittografia in real time e autenticazione hardware. Non richiedono installazioni di software, driver o utility, e sono indipendenti dal sistema operativo e dalla piattaforma.

19 Settembre 2018

SealPath : proteggi i tuoi file sempre , ovunque, con facilità

 

La condivisione dei documenti e delle informazioni con colleghi, clienti, fornitori o consulenti, rende più difficile il controllo e la protezione dei dati aziendali sensibili e riservati, non solo sotto il profilo privacy ma anche sotto il profilo delle informazioni che non devono essere divulgate

Il patrimonio informativo dell’azienda può così essere oggetto di perdite, furti, attacchi interni e/o esterni, e occorre difenderlo.

Con Sealpath IRM gli utenti aziendali possono, con estrema facilità, proteggere e controllare sempre i documenti.

Sealpath IRM impedisce che informazioni riservate, ovunque esse siano, sulla rete aziendale, sulle reti dei clienti o dei partner, nel cloud (ad es. Box, Dropbox, ecc.) o su un dispositivo mobile, possano essere visti o usati da utenti non autorizzati. Inoltre, offrendo una APP semplice e intuitiva, ha risolto la complessa gestione di un sistema di crittografia.

La soluzione, in estrema sintesi,

–      protegge i documenti riservati con crittografia persistente che accompagna i file ovunque essi siano
–      gestisce e controlla chi accede ai documenti riservati, quando e con quale permesso (sola lettura, modifica, stampa, copia e incolla, ecc.),
–      registra i dettagli degli accessi ai documenti, ovunque si trovino, e se qualcuno tenta di accedervi senza autorizzazione
–      consente di dimostrare che i documenti con dati personali e/o sensibili sono protetti con sistemi di crittografia e con misure tecniche che assicurano che l’accesso ad essi sia impossibile senza autorizzazione, rispondendo così anche al principio di accountability del GDPR, il nuovo Regolamento Europeo in materia di Privacy.

Scarica la presentazione

28 Giugno 2018

Come funziona DKIM per proteggere la tua posta

DKIM (DomainKeys Identified Mail) è un metodo utilizzato per identificare il mittente di un messaggio, evitando il rischio di Spoofing del dominio mittente (obiettivo raggiunto anche da SPF) ed inoltre permette l’identificazione di alterazioni sul contenuto del messaggio.

DKIM basa il suo funzionamento sul meccanismo crittografico, facendo ricorso all’algoritmo SHA a chiave assimetrica, il mittente conserverà con le opportune precauzioni la chiave privata sul mail gateway (mail server, server antispam o l’smtp relay) del proprio dominio e pubblicherà sul DNS un record TXT con la chiave pubblica.

Quando il messaggio viene inviato dal server corretto, al messaggio viene aggiunto un tag con il digest del messaggio, calcolato usando la chiave privata.

Il destinatario, recuperata la chiave pubblica sul record TXT del DNS del dominio mittente, può verificare se il messaggio è stato alterato o comunque se non è stata utilizzata la chiave privata del dominio mittente, in modo da accorgersi dell’inaffidabilità del mittente.

Se il sistema di posta del destinatario non supportasse DKIM il messaggio verrebbe comunque letto correttamente, infatti il messaggio viaggia in chiaro e non in forma cifrata. DKIM non garantisce la riservatezza della comunicazione ma solo l’identificazione del mittente e l’inalterabilità del contenuto.

Purtroppo è valido lo stesso discorso fatto per SPF, la scarsa diffusione di questi sistemi permette di avere ancora percentuali di spam che superano il 50% dei messaggi validi, una adozione capillare di questi sistemi permetterebbe di abbattere i livelli di spam.

Zimbra supporta pienamente questo meccanismo di protezione del mittente, i tecnici Argonavis sono a tua disposizione per aiutarti ad implementare le tecniche di protezioni più efficaci per proteggere la tua organizzazione da attacchi ed eventuali perdite economiche.

Richiedi Informazioni

13 Gennaio 2017