Creazione di una Certification Authority con CentOS/Fedora (Parte I)

Addirittura una Certification Authority? Ma cosa te ne fai?

In tanti mi hanno fatto questa domanda. Il fatto è che una CA è sempre utile al giorno d’oggi.
Pensiamo per un attimo ai siti web che gestiscono dati sensibili tramite SSL (https); fareste una transazione bancaria senza vedere il piccolo luccetto chiuso all’interno del vostro browser?

E’ vero, è possibile acquistare certificati dagli enti preposti come ad esempio Verisign ed è vero che ci sono enti no profit che rilasciano certificati senza spendere una lira (anzi un centesimo). Ma volete mettere…
…Avere la propria CA è tutta un’altra cosa.

Scherzi a parte, secondo me, utilizzare una CA creata in casa ha senso specie se si tratta di piccole e medie imprese.

La crittografia oggi viene impiegata praticamente dappertutto:

  • accesso a siti web (HTTPS);
  • autenticazione utente LDAP, RADIUS, connettività WI-FI;
  • trasferimento di domini DNS;
  • reti private virtuali (VPN);
  • transazioni su database;
  • accesso remoto.

Cos’è un Self Signed Certificate?
Partendo dal presupposto che i certificati vengono creati per provare l’identità di qualcuno, si parla di certificati self-signed se questi sono destinati a provare l’identità di chi li ha creati.
In parole povere…

…Tu te la canti e tu te la suoni.

Detto questo, se ci fidiamo di chi ha creato la CA, allora possiamo fidarci di tutti i certificati da essa digitalmente firmati (Signed).

Self-Signed Certificate senza CA
Sarà capitato a tutti di imbattersi in un sito che espone un certificato non verificato:

In genere questo non è un problema, la comunicazione https è criptata ed i dati da e verso il sito non transiteranno in chiaro sulla rete. Bisogna però ricordare tutta la chiave pubblica (fingerprint) a memoria, altrimenti non vi è la certezza di comunicare effettivamente con il sito desiderato. In realtà, possono sorgere problemi di tipo man in the middle (uomo nel mezzo). Nella pratica qualcuno potrebbe interporsi tra client e server e mettersi in ascolto scambiando con il client un certificato finto.

Man in the middle (MITM)
Con l’acronimo di MITM si intende la volontà di un soggetto di interporsi in una comunicazione tra due punti (tipicamente un client ed un server).
L’intromissione può avvenire a diversi livelli:

  • strato fisico (es doppino telefonico);
  • strato logico (es. arp poisoning);
  • strato applicativo (es comunicazioni criptate SSL);

Le persone spesso non riescono a spiegarsi come sia possibile per qualcuno introdursi illecitamente in una comunicazione criptata tra client e server.
Basti pensare che le informazioni vengono trattate da diversi sistemi informativi prima di raggiungere il server di destinazione, Vi sono casi in cui è possibile carpire le informazioni dirottando in uno o più punti il traffico della rete (vedi arp poisoning).
Il problema è stato parzialmente risolto mediante l’impiego di algoritmi come ad esempio il One time Passcode, con il quale le passord scambiate tra client e server cambiano ad ogni connessione.
Nelle comunicazioni criptate tra client e server vengono scambiate le chiavi pubbliche ed altre informazioni che cambiano ad ogni connessione (handshaking); di conseguenza, senza le chiavi private, sarebbe impossibile per qualcuno sniffare la comunicazione tra client e server (vedi figura in basso).

In un attacco MITM però, sia il Client (A) che il Server (B) scambiano le chiavi pubbliche con il MITM (C) che a questo punto può interpretare tutto il traffico. Le informazioni di A vengono Inviate da C a B e viceversa. A e B non sanno di comunicare entrambi con C.

Per arginare questo problema, prima di iniziare una comunicazione privata è necessario controllare il fingerprint del server per essere sicuri che si stia effettivamente comunicando con B e non con C.
Di seguito viene riportata una chiave pubblica (RSA1024) di esempio:

40 81 8F 02 81 81 00 B8 08 84 E0 E2 27 47 BB 8B
4F D1 42 1F 66 88 86 42 DE D7 82 F4 B8 DD DB D8
B6 D2 B2 87 DF 47 18 BB F8 8D E8 4F 81 D4 41 7D
D8 D6 8E 24 E2 74 D2 D4 18 DF 18 6F B1 42 28 74
6B 27 72 1F 2E 8D 44 D4 47 EB 02 21 88 28 DD 72
E2 2F BB 06 4E DD 04 BD 8E BD 4F B6 81 B7 F8 BD
24 D4 BB 01 78 D1 DE F0 6D 14 61 12 88 8D 41 B8
24 B8 22 44 FB 88 80 44 BF 48 DD 4D ED 24 B2 80
64 01 D6 B2 D4 62 DF 02 04 01 00 01

Sfido chiunque ad imparare questa chiave a memoria. Bisogna inoltre ricordare che non è sufficiente imparare la parte iniziale o finale della chiave perchè esistono programmi in circolazione in grado di creare chiavi pubbliche del tutto simili ad altre, proprio con lo scopo di trarre in inganno gli utenti (fuzzy fingerprint).
Per evitare attacchi MITM sarebbe opportuno dotarsi di una CA in grado di stabilire se il certificato del Server è stato emesso o meno tramite la CA stessa.

Per il momento è tutto, nel prossimo articolo vedremo come creare una CA per i propri scopi mediante OpenSSL e CentOS/Fedora.

Leave a comment

1 Comments.

Leave a Reply


[ Ctrl + Enter ]

Trackbacks and Pingbacks: