HTTPS Server

Da Wiki-itsos.

Screenshot.jpg
~5°A INFO

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, il quale è largamente utilizzato su Internet. HTTPS consiste nella comunicazione tramite il protocollo HTTP (HyperText Transfer Protocol) all'interno di una connessione criptata dal Transport Layer Security (TLS) o dal suo predecessore, Secure Sockets Layer (SSL). Il principio che sta alla base di HTTPS è quello di avere:

  • un'autenticazione di entrambe le parti coinvolte
  • protezione della privacy
  • integrità dei dati scambiati tra le parti comunicanti.

SSL & TLS

Definizione

SSL o "Secure Sockets Layer" (SSL) e “Transport Layer Security” (TLS) sono due protocolli utilizzati per consentire alle applicazioni di trasmettere informazioni in modo sicuro e protetto. Sono entrambi protocolli di livello Session e Presentation ovvero di livello 4 TCP/IP.
Concentriamoci sul protocollo TLS costruito sulle basi del predecessore SSL ereditandone gli scopi e i punti di forza.
Il protocollo TLS consente alle applicazioni client/server di comunicare attraverso una rete in modo tale da prevenire il 'tampering' (manomissione) dei dati, la falsificazione e l'intercettazione.
TLS è una specifica (RFC 5246) che definisce al suo interno ben 4 protocolli:

  • TSL Record Layer Protocol
  • TSL Handshake Protocol
  • TSL Change Chiper Spec Protocol
  • TSL Alert Protocol

il TSL Record Layer Protocol è il protocollo principale che è sempre presente nella comunicazione. Si occupa di prendere i dati dal livello superiore, criptarli, calcolare il MAC e criptarlo
Gli altri 3 protocolli(Handshake,Change,Alert) insieme al protocollo di livello 7, si alterneranno nelle varie fasi della comunicazione
L’HandShake Protocol è responsabile della negoziazione dei parametri di sicurezza di una sessione tra cui:

  • Chiper Suite
  • Random value (Server e Client)

Il Change Chiper Spec Protocol è utilizzato insieme all’ Handshake Protocol scambiarsi una nuova chiave di sessione
L’Alert Protocol è utilizzato invece per inviare warning o errori.

Attacchi

La maggior parte degli attacchi ad una comunicazione https sono di tipo MiM (man in the middle, uomo nel mezzo) ovvero si tenta di frapporsi tra server e client. Molti attacchi sono mirati a cambiare il tipo di versione del protocollo che verrà utilizzata. Due attacchi sono degni di nota:

Downgrade

All’attaccante basta porsi tra il client e il server e dirottare semplici richieste http in richieste https. Quando digitiamo l’url di una pagina il nostro browser invia una richiesta http che giunta al server verrà tramutata in https. Se un host è in grado di intercettare questa richiesta e convertirla, all’insaputa del client, in https avremo una situazione nella quale il server pensa che il client sia collegato https e quindi potrebbe richiedere dati sensibili (login) e il client invierà i dati in chiaro.

VITTIMA -----canale-insicuro-----ATTACCANTE-----canale-sicuro-----SERVER

Questo problema è parzialmente risolto dall’ HSTS (HTTP Strict Transport Security) ovvero un header che viene inserito nella prima risposta dove è indicato per quanto tempo il client dovrà rivolgersi al server in https. E’ chiaro che se viene intercettata la prima richiesta questo non sarà più utile.

Heartbleed

Heartbeat è un protocollo di openSSL che interviene quando si devono eseguire dei semplici keep-alive per mantenere attiva la connessione così da non doverla rinegoziare. Un client invia un messaggio che contiene una stringa (campo payload) e la sua lunghezza (campo lenght). Il server deve, secondo le specifiche, quindi rispondere con una stringa di lunghezza pari al campo lenght.
Un attacco avviene inviando una richiesta con un piccolo payload e una grande lenght il server risponderà cosi con una stringa della lunghezza specificata dal client. Nella specifica del protocollo è indicato che il server deve prelevare questa stringa dal suo buffer di memoria. Nel buffer vengono chiaramente conservate tutte le chiavi di sessione, i sessionID, e se si è fortunati, la chiave privata dello stesso server.

HTTPS-Attack.png

Algoritmi

Cosa Garantisce Come lo implementa
Riservatezza Crittografia Simmetrica
Integrità HMAC -> Hash + Crittazione

Come fare a conoscere quali chiavi e quali algoritmi utilizzare?

Chiper Suite

La chiper suite è una lista di tre algoritmi che verranno utilizzati per la comunicazione tra server e client:

  1. Algoritmo di key exchange
  2. Algoritmo di crittografia simmetrica
  3. Algoritmo di HMAC

Attenzione! Non è necessario che vengano inviati tutti e tre gli algoritmi, l’unico che deve esserci per forza è il numero 1. Se qualcuno non fosse presente non si utilizzerà quella funzionalità.
esempio

DH-RSA-AES256-GCM-SHA256

Per gli smanettoni ;)

DH= Diffie-Hellman (Algoritmo di key exchange)
RSA= RSA (Algoritmo di crittografia asimmetrica)(Solo quando sono utilizzato per https)
AES256= AES chiavi da 256 bit (Algoritmo di crittografia simmetrica)
GCM= GMC (Algoritmo di crittografia del MAC)
SHA256= SHA con output a 256 bit (Algoritmo di hash)

Key Exchange

Gli algoritmi di key exchange (tra tutti Diffie-Hellman e le sue derivate) sono utilizzati per generare una chiave casuale uguale per e due gli host senza che questa venga trasmessa sul canale.

Diffie-Hellman

Prendiamo un insieme di numeri limitato per fare questa prova (4-9). Il server sceglie un numero primo in quell’intervallo e lo rivela al client. p Il client ora sceglie dal quell’intervallo un numero minore di quello ricevuto g I due host scelgono casualmente due numeri compresi tra (2-5) a b Ora elevano il numero g al numero che hanno scelto casualmente e lo dividono per il numero primo salvandosi il resto Si inviano reciprocamente i due resti. Ora elevano quest'ultimo numero ricevuto al numero che hanno scelto casualmente e lo dividono per il numero primo salvandosi il resto. Questo resto sarà quindi la chiave

SERVER CANALE CLIENT
Invio numero primo p
Scelta casuale numero a ← Invio numero g
Calcolo A=g^a mod p Invio numero A Scelta casuale numero b
Testo della cella ← Invio numero B Calcolo A=g^b mod p
Chiave = B^a mod p Testo della cella Chiave = A^b mod p

Handshake

In informatica, è il processo attraverso il quale due calcolatori, tramite software o hardware, stabiliscono le regole comuni, ovvero la velocità, i protocolli di compressione, di criptazione, di controllo degli errori, ecc.
Prima di iniziare la connessione vera e propria tra due macchine si crea questo tipo di connessione che consiste nella trasmissione dei pacchetti per regolare i parametri di connessione.

Quando si instaura una connessione HTTPS, o qualsiasi altra connessione che utilizzi TLS, viene inviato un messaggio TLS composto dal Record Layer Protocol e dall’ HandShake Protocol
Se la procedura andrà a buon fine si iniziarà la comunicazione altrimenti verrà mandato un messaggio TLS con Alert Protocol

HTTPS-Handshake.png

Authenticazione Classica

Una classica autenticazione del server

  1. Fase di negoziazione:
    1. Un client invia un messaggio ClientHello specificando la versione più alta del protocollo di cui dispone, un numero casuale (client random), una chiper suite conosciuti e i metodi di compressione utilizzati
    2. Il server risponde con un messaggio ServerHello che contiene il protocollo che verrà utilizzato, un numero casuale (server random), la chiper suite che verrà utilizzata, il metodo di compressione che verrà usato.
    3. I messaggi sono da ora firmati (se specificato nella suite)
    4. Il server manda il suo Certificate
    5. Il server invia un messaggio ServerKeyExchange che contiene la chiave pubblica per lo scambio di chiavi (Tipicamente Diffie Helman)
    6. Il server invia un messaggio ServerHelloDone indicando la fine della negoziazione
    7. Il client risponde con un messaggio ClientKeyExchange che contiene un PreMasterSecret, chiave pubblica per lo scambio di chiavi oppure nulla. Il tutto viene criptato con la chiave pubblica del server
    8. Il client e il server creano se necessario poi un MasterSecret, che verrà utilizzato come chiave simmetrica nelle future comunicazioni.
  2. Il client invia infine un messaggio ChangeCipherSpec dove conferma l’avvenuto successo
    1. L’ultimo messaggio inviato è un messaggio Finished autenticato e criptato
    2. Il server decripta il messaggio ricevuto e se tutto è verificato apre la connessione altrimenti l’handshake fallisce.
  3. Il server invia infine un messaggio ChangeCipherSpec dove conferma l’avvenuto successo
    1. L’ultimo messaggio inviato è un messaggio Finished autenticato e criptato
    2. Il client decripta il messaggio ricevuto e se tutto è verificato apre la connessione altrimenti l’handshake fallisce.
  4. A questo punto parte la comunicazione autenticata e criptata con meccanismo simmetrico tra le due parti.

Handshake con Autenticazione del client

  1. Fase di negoziazione:
    1. Un client invia un messaggio ClientHello specificando la versione più alta del protocollo di cui dispone, un numero casuale (client random), una chiper suite conosciuti e i metodi di compressione utilizzati
    2. Il server risponde con un messaggio ServerHello che contiene il protocollo che verrà utilizzato, un numero casuale (server random), la chiper suite che verrà utilizzata, il metodo di compressione che verrà usato.
    3. I messaggi sono da ora firmati (se specificato nella suite)
    4. Il server manda il suo Certificate
    5. Il server invia un messaggio ServerKeyExchange che contiene la chiave pubblica per lo scambio di chiavi (Tipicamente Diffie Helman)
    6. Il server quindi richiede al client un certificato con un messaggio CertificateRequest
    7. Il server invia un messaggio ServerHelloDone indicando la fine della negoziazione
    8. Il client risponde inviando un messaggio Certificate che contiene il suo certificato.
    9. Il client risponde con un messaggio ClientKeyExchange che contiene un PreMasterSecret, chiave pubblica per lo scambio di chiavi oppure nulla. Il tutto viene criptato con la chiave pubblica del server
    10. Il client invia poi un messaggio CertificateVerify, il quale è criptato con la chiave privata in possesso del client. Se il server riuscirà a decriptarlo con la chiave pubblica ricevuta precedentemente sarà sicuro che il client ha accesso alla chiave privata di chi dice di essere.
    11. Il client e il server creano se necessario poi un MasterSecret, che verrà utilizzato come chiave simmetrica nelle future comunicazioni.
  2. Il client invia infine un messaggio ChangeCipherSpec dove conferma l’avvenuto successo
    1. L’ultimo messaggio inviato è un messaggio Finished autenticato e criptato
    2. Il server decripta il messaggio ricevuto e se tutto è verificato apre la connessione altrimenti l’handshake fallisce.
  3. Il server invia infine un messaggio ChangeCipherSpec dove conferma l’avvenuto successo
    1. L’ultimo messaggio inviato è un messaggio Finished autenticato e criptato
    2. Il client decripta il messaggio ricevuto e se tutto è verificato apre la connessione altrimenti l’handshake fallisce.
  4. A questo punto parte la comunicazione autenticata e criptata con meccanismo simmetrico tra le due parti.

Ripristino di una sessione

Le operazioni con chiave pubblica sono costose in termini di operazioni perciò il TLS proprone un Handshake accorciato che si avvale di un SessionID e Session Ticket scambiati dopo la fine del primo handshake. (da approfondire)

Pacchetti

ClientHello
HTTPS-pack1.png
ServerHello, Certificate, KeyExchange
HTTPS-pack1.png
ClientKeyExchange
HTTPS-pack1.png

Certificati

Nella crittografia asimmetrica un certificato digitale è un documento elettronico che attesta l'associazione univoca tra una chiave pubblica e l'identità di un soggetto (una persona, una società, un computer) che dichiara di utilizzarla nell'ambito delle procedure di cifratura asimmetrica e/o autenticazione tramite firma digitale.
Tale certificato, fornito da un ente terzo fidato e riconosciuto come autorità di certificazione (CA), è a sua volta autenticato per evitarne la falsificazione sempre attraverso firma digitale ovvero cifrato con la chiave privata dell'associazione la quale fornisce poi la rispettiva chiave pubblica per verificarlo.

La struttura di un certificato digitale v3 X.509 è il seguente :

  • Nome certificato
  • Numero della versione
  • Numero di serie
  • ID dell’algoritmo utilizzato per la firma del certificato
  • Nome Emittente CA
  • Periodo di validità CA

(senza validità prima, senza validità dopo)

  • Nome dominio a cui andrà il certificato
  • Informazioni soggetto chiave pubblica
  • Algoritmo a chiave pubblica
  • Soggetto chiave pubblica
  • Emittente identificativo ( opzionale )
  • Soggetto identificativo ( opzionale )
  • Estensioni ( opzionale )
  • L' URL della lista dei Certificati revocati ( CRL)
  • Tipologia algoritmo di firma certificato
  • Firma Certificato.

HTTPS-Cert.png

Certification Authority

Autorità di Certificazione (CA, Certification Authority): deve essere una terza parte credibile (TTP, Thrusted Third Part) incaricata del rilascio dei certificati e della verifica dell’identità richiedente, nonché del mantenimento di quella che va sotto il nome di “lista di revoca dei certificati” (CRL, Certificate Revocation List), dove sono conservati i certificati non validi. Alcune delle maggiori società che si occupano del rilascio dei certificati sono: VeriSign, BelSign, AT&T, Deusche Telekom, American Express. E’ da notare come nessuno abbia incaricato direttamente una di queste società ad essere CA; tuttavia, esse svolgono un ruolo davvero importante nella sicurezza delle reti, sebbene non in maniera gratuita.

Rilasciare Certificati

La CA riceve il certificato del server, e lo autentica firmandolo ovvero crea un HASH del certificato stesso e lo cripta con la sua chiave privata.

Revoca Certificati

CRL

Nel caso una chiave venga compromessa, per limitare i danni si procederà alla revoca della chiave. La situazione che coinvolge i certificati è più difficile, visto che tutte le copie devono essere ritirate. Le motivazioni di una revoca di un certificato, potrebbero includere: il ritiro di un utente da una organizzazione o il cambiamento del suo ruolo, oppure la fine di una richiesta di autorizzazione. Le tecniche per gestire il problema della revoca delle chiavi includono:

  • Lista dei certificati revocati (CRL). Una CRL è un metodo per il trattamento di file pubblico di chiavi revocate.
  • Date di scadenza dei certificati. Le date di scadenza limitano l'esposizione che segue a una compromissione. I certificati on-line hanno vita breve (circa 1 anno) perchè maggiormente sotto attacco. I certificati a breve termine senza CRL possono essere paragonati ai certificati a lungo termine con CRL frequentemente aggiornato.

Una CRL è una lista firmata di entrate corrispondenti alle chiavi pubbliche revocate dove ogni entrata indica il numero seriale del certificato associato, la data della revoca ed altre informazioni, quali le ragioni della revoca. La firma della lista, che garantisce la sua autenticità, è generata dalla CA che in origine ha emesso il certificato; la CRL tipicamente include anche questo nome. L’inclusione della data alla lista totale fornisce un’indicazione del suo ultimo aggiornamento.

OCSP

L'Online Certificate Status Protocol è lo standard emergente dell'IETF (Internet Engineering Task Force) destinato al controllo della validità dei certificati digitali nel corso di una determinata transazione. OCSP permette invece di condurre queste verifiche in tempo reale, risparmiando tempo e denaro, semplice e affidabile per la validazione dei certificati digitali rispetto a quello offerto dal tradizionale scaricamento ed elaborazione delle Certificate Revocation Lists (CRL).


Firma Digitale

La Firma Digitale è l'equivalente informatico di una tradizionale firma autografa apposta su carta e possiede le seguenti caratteristiche:

  • autenticità: la firma digitale garantisce l’identità del sottoscrittore
  • integrità: la firma digitale assicura che il documento non sia stato modificato dopo la sottoscrizione
  • non ripudio: la firma digitale attribuisce piena validità legale al documento, pertanto il documento non può essere ripudiato dal sottoscrittore

Per generare una firma digitale è necessario utilizzare una coppia di chiavi digitali asimmetriche attribuite in maniera univoca ad un soggetto, detto titolare. La chiave privata è conosciuta solo dal titolare ed è usata per generare la firma digitale da apporre al documento. Viceversa, la chiave da rendere pubblica è usata per verificare l’autenticità della firma

Hash

Una funzione crittografica di hash è una funzione che è impossibile invertire, cioè solo hash può ricreare i dati di ingresso. Queste funzioni hash sono unidirezionali.
In crittografia, un codice di autenticazione di messaggio digitato-hash ( HMAC ) è una costruzione specifica per il calcolo di un “codice di autenticazione del messaggio” (MAC) che coinvolge una funzione di hash crittografico in combinazione con una chiave crittografica. Come con qualsiasi MAC, può essere utilizzato per verificare contemporaneamente sia la integrità dei dati e l' autenticazione di un messaggio.
Qualsiasi funzione hash crittografica, come MD5 o SHA-1 , può essere utilizzato nel calcolo di un HMAC. La forza crittografica del HMAC dipende dalla forza crittografica della funzione hash sottostante, la dimensione della sua uscita hash, e la dimensione e la qualità della chiave.
MD5 è l’acronimo di Message Digest 5, un algoritmo di crittografia a senso unico (cioè che non prevede di essere decrittato). MD5 è una funzione di compressione, che dato in input una stringa di lunghezza arbitraria, restituisce una firma digitale che consiste in una stringa da 128 bit (32 caratteri). Si presuppone che l’hash (ovvero l’output) restituito dalla funzione sia univoco o, più precisamente, che sia molto improbabile ottenere due hash identici da due input diversi.
SHA (Secure Hash Algorithm) è un'algoritmo di hashing studiato e poi pubblicato in varie versioni. Si tratta di una famiglia di algoritmi tra cui: SHA-1 e SHA-2.


Tipi di Certificato

  • Certificato Client: permette al server l’identificazione sicura dell’utente che sta accedendo ai servizi.
  • Certificato Server: permette al client di identificare sicuramente il server a cui si sta per accedere. E’ usato per le comunicazioni sicure e, in particolare, è previsto dal protocollo SSL.
  • Certificati di email: permettono lo scambio sicuro di messaggi tramite email (S/MIME).
  • Certificati di applicazioni: permettono di garantire l’autenticità e la sicurezza di una applicazione scaricata dalla rete

Certificato Server

.pem
è il formato più comunemente utilizzato dalle Certification Authorities per emettere i certificati (esistono anche .crt e .cer)
Sono files ASCII con codifica Base64 e contengono "-----BEGIN CERTIFICATE-----" all'inizio e "-----END CERTIFICATE-----" alla fine.

Certificato Client

.p12
Il formato è PKCS#12. Viene utilizzato questo complicato e strano formato perchè è necessario impacchettare in un unico file sia chiave privata che certificato. Questo formato consente di proteggere poi il file creato con una password.

Parte 1 - Completed


50% Totale

10 000 views per la seconda parte ;)