cryptography &mdash; Cyberdyne Systems https://noblogo.org/aytin/tag:cryptography "Fare o non fare. Non c'è provare!" Thu, 30 Apr 2026 09:56:18 +0000 Archiviare le password in sicurezza con KDF/password-hashing (Trilogia Della Password - 3 di 3) https://noblogo.org/aytin/archiviare-le-password-in-sicurezza-con-kdf-password-hashing-trilogia-della <![CDATA[password hashing Dopo aver capito come creare password inviolabili anche avendo a disposizione tutta l'energia termica dell'universo, pensiamo al modo migliore per archiviarle. Pensare di lasciare la password raw in un database, rappresenta un grosso rischio in virtù di un possibile attacco offline. !--more-- Rainbow Table Come ti blocco la Rainbow Table: Il “Salt” (sale) Il livello successivo: Il Pepper Final step: L’hashing PBKDF2 Bcrypt Scrypt yescrypt Argon2 Un piccolo esempio: hashing di una password con Argon2 Gestione del pepper HSM Key / Algo Rotation Caso A: Algo rotation Caso B: Pepper rotation Una prima linea di difesa consiste nel memorizzare il digest della password, una stringa alfanumerica univoca generata da un apposito algoritmo, così da lasciare nelle mani dell'attaccante degli oggetti che, per la loro non invertibilità, non permettono di risalire alle password. La scelta dell'algoritmo di hashing diventa critica al fine di scongiurare altri tipi di attacchi. Ad es. SHA-256, pur essendo ottimo e molto efficiente per il digest e la firma anche di file di grandi dimensioni, mostra il fianco, proprio in virtù della sua velocità, nel caso di attacchi con: brute-force: si calcola l’hash di password casuali fino a trovare una corrispondenza, dizionario: un'alternativa intelligente alla forza bruta. Si punta alle password più comuni, si calcola l'hash e si controlla se c'è corrispondenza. Rainbow Table: l'attacco al dizionario più insidioso di tutti Oltre al fatto che, la funzione di hashing , essendo deterministica, permette di capire chi sono gli utenti che hanno la stessa password, dal momento che avranno lo stesso digest. Rainbow Table Una Rainbow Table è un enorme dizionario pre-calcolato che contiene: Milioni di password comuni. Il relativo hash corrispondente. Invece di calcolare l’entropia di ogni tentativo, l’attaccante ruba il database degli hash e fa un semplice “Cerca e Trova”. Se l’hash della tua password è nella tabella, la tua password è violata in millisecondi, indipendentemente da quanto fosse alta la sua entropia teorica. smallOss.: Una password totalmente casuale, generata da un CSPRNG affidabile, con un'alta entropia ( 120), rimarrebbe comunque inviolabile anche dalla rainbow table perché la probabilità che quella password si trovi nel dizionario, sarebbe equivalente ad indovinarla./small Come ti blocco la Rainbow Table: Il “Salt” (sale) Per rendere inutili le Rainbow Table, i sistemi sicuri utilizzano il Salt. Il salt è una stringa di dati casuali (generati da una sorgente d’entropia affidabile ovviamente) che viene aggiunta alla password prima di calcolarne il digest. In questo modo le rainbow table vengono vanificate perché gli hash precalcolati sulle password raccolte, mancando il salt, non valgono più. Anche se due utenti avessero la stessa password, avrebbero degli hash completamente diversi. Anche per questo motivo non è un problema che il salt sia pubblico, perché il suo obiettivo non è nascondere quello che è un pezzetto di password a tutti gli effetti, ma di impedire economie di scala degli attacchi perché, pur potendo disporre offline di un database di decine di milioni di utenti, gli hash della mia Rainbow Table (che può arrivare a pesare anche decine di GB) andrebbero tutti ricalcolati per ogni utente, con un costo computazionale e di archiviazione inimmaginabile. Per riassumere, gli ingredienti di base sono: una buona sorgente d’entropia: una fonte di casualità certificata per generare un salt unico; entropia della password: sempre buona norma, ove possibile, come sappiamo ormai fare (https://noblogo.org/aytin/come-generare-una-password-o-un-keyfile-sicuri-trilogia-della-password-1-di). Evita attacchi brute-force o al dizionario in cui l’attaccante prova a indovinare; salt: protegge la password dagli attacchi basati su database pre-calcolati (Rainbow Table). Il livello successivo: Il Pepper È vero che col salt andiamo a complicare lo sfruttamento di un attacco offline ma possiamo fare di meglio. Il punto d'attenzione è che il salt protegge le password di tutti gli utenti. Ma un attaccante potrebbe non essere affatto interessato a violare ogni singolo utente (niente economia di scala) ma solo alcuni. E allora l'attacco attraverso Ranbow Table potrebbe essere di nuovo praticabile. Ma gli informatici sono dei gran giocherelloni, si sa. Visto che abbiamo già il "sale", perché non finire aggiustando con un po’ di “pepe”? Detto, fatto! Il pepper, come il salt, è un'altra password generata con gli stessi criteri del salt ma le analogie finiscono qua perché: a differenza del salt che si trova nel database, il pepper è separato da ques'ultimo. L'ideale sarebbe un HSM; Il salt è visibile a tutti, attaccante compreso. Il pepper è segreto. Un eventuale data breach che permette all'attaccante di disporre offline di tutto il database degli utenti, "vedrà" certamente gli eventuali salt ma sarà ignaro del fatto che gli mancherà sempre un pezzo di chiave; il salt è diverso per ogni utente, il pepper, di solito, è unico; il salt serve a rendere uniche la password degli utenti, il pepper protegge l'intero database da attacchi offline. Il pepper è la chiave di un HMAC, o di un meccanismo di cifratura simmetrica, applicato al digest della password (che ricordo essere salt+password in realtà), che sarà ciò che verrà archiviato. Va detto che l'uso del "pepper" complica ulteriormente lo scenario di archiviazione. Nella stragrande maggioranza dei casi è sufficiente scegliere un buon algoritmo di password hashing (vedi paragrafo successivo) per scoraggiare gli attaccanti. "Pepare" le password prevederebbe, come detto sopra, l'uso di un HSM per es, e tutta una serie di riflessioni di contorno che evidenzierò più avanti. Final step: L'hashing L'ultimo punto da dettagliare è l'hash della password. L'hash crittografico, in uso in questi casi, deve soddisfare le seguenti proprietà: resistenza alla pre-immagine: dato un hash h, deve essere impossibile trovare una password p t.c. H(p) = h (non invertibilità della funzione hash) resistenza alla pre-immagine secondaria: dato una password psub1/sub, deve essere impossibile trovare un'altra password psub2/sub t.c. H(psub1/sub) = H(psub2/sub) (resistenza debole alle collisioni) resistenza alle collisioni: è impossibile trovare due password diverse, psub1/sub e psub2/sub, t.c. H(psub1/sub) = H(psub2/sub) (resistenza forte alle collisioni) effetto valanga: il cambio di un solo bit della password deve cambiare radicalmente l'intero hash In un sistema moderno, l'hash non può essere delegato a funzioni di tipo SHA perché nascono per altri compiti, SHA-2 e SHA-3 nascono per il digest veloce, per verificare l'integrità di file anche molto grossi o firmare documenti. La loro eccellente velocità diventa il loro più grosso difetto quando si parla di password. Negli scenari precedenti di attachi offline, l'hacker che dispone di una grossa potenza di calcolo, può ricostituire velocemente le rainbow table per n utenti. Magari non di tutti ma di quelli attenzionati. Le funzioni di derivazione della chiave (KDF) come pbkdf2 e quelle ancora più estreme come B/Scrypt, Argon2, oltre che soddisfare tutti i punti precedentemente elencati tipici di funzioni di password hashing, sono progettate per essere computazionalmente pesantissime da calcolare perché il loro scopo non è il digest ma la protezione di un segreto contro il brute-force. E mentre le vecchie KDF come pbdfk2 sono CPU bound, ma non GPU bound, le KDF più moderne come Bcrypt, Scrypt ma soprattutto Argon2, agiscono pesantemente su tempo, memoria e parallelismo e l'attacco offline di cui sopra diventa impraticabile. PBKDF2 È il decano delle KDF. Applica iterativamente una funzione pseudorandomica, come HMAC con uno SHA, con salt alla password. Il conteggio delle iterazioni è un parametro configurabile. PBDKF2 è uno standard di lunga data ampiamente adottato. Se non ci sono necessità stringenti di sicurezza o requisiti legacy, è una buona scelta. Il fatto di essere solo CPU bound però non la rende la scelta ideale in scenari dove gli attaccanti possono attingere a risorse di calcolo considerevoli Bcrypt Basato su Blowfish, anche Bcrypt usa un hash crittografico sulla password con parametri il salt e un fattore di costo. Il fattore di costo aumenta esponenzialmente il numero di iterazioni per adattarsi all'aumento di potenza di calcolo dell'hardware. Bcrypt è stato progetto per essere lento e resistente a semplici attacchi di forzat bruta. Tuttavia, il basso utilizzo di ram richiesto dal calcolo lo rendono poco resistente ad attacchi sferrati usando hardware specializzato. Bcrypt ha dalla sua una storia solidissima in ragione della quale da 20 anni a questa parte non sono state trovate vulnerabilità critiche nel suo design. Per questo motivo Bcrypt cifra le password di sistema di OpenBSD dal 1999, come pure ha cifrato quelle di tante distro Linux per anni, prima che passassero ad Argon2 o yescrypt (default di Fedora). Domina nei framework web (\[Python\] Django, \[Ruby\] Ruby on Rails, \[PHP\] Laravel), \[Java\] Spring, Node.js), nelle applicazioni (Ansible / Terraform, Docker), nel web (la cifratura in .htpasswd di Apache e Nginx) visto che la sua semplcitià di implementazione gli ha permesso di trovarsi praticamente in ogni linguaggio. È presente come alternativa anche nei password manager benché molti di essi abbiano spostato il default verso Argon2 o PBKDF2 per conformità agli standard FIPS. È molto semplice implementare e anche da usare perché bisogna agire solo sul fattore di costo (consigliato almeno 10-12, altrimenti diventa troppo vulnerabile ad attacchi sferrati attraverso la GPU) Scrypt Rilasciato nel 2009, Scrypt è stato il primo algoritmo a introdurre il concetto di Memory Hardness ed è stato progettato per rendere economicamente poco conveniente il ricorso ad hardware specializzato come gli ASIC o i FPGA e incidere pesantemente su CPU, ram e parallelismo. Il suo alveo principale sono state le cripto-valute, molte monete lo usano per il mining. Scrypt lo troviamo in quasi tutti i linguaggi di programmazione, in Tarsnap, servizio di baclup online creato dallo stesso autore di Scrypt, è stato usato da LastPass ed è presente come opzione in VeraCrypt per derivare la chiave dalla password. Fino ad Android 9 era l'algoritmo usato per la FDE del dispositvio (passato poi al FBE) . Presente anche su FreeBSD come opzione per la cifratura delle password di sistema e come opzione su LUKS per la cifratura degli slot delle chiavi. Su Scrypt i parametri da configurare sono: Costro CPU/Memoria (N): un parametro che aumenta i costi computazionali di cpu e memoria DImensione del blocco (R): influenza la larghezza di banda della memoria Parallelizzazione (p): indica quanto deve incidere sul calcolo parallelo In questo modo riesce ad essere sia CPU bound che GPU bound che, a differenza di Bcrypt, lo rende resistente anche ad attacchi facenti uso di hardware specializzato.. Di contro, in ambiente in cui siamo vincolati dalle risorse disponibili, la sua potenza diventa un fattore limitante. Quasi paragonabile ad Argon2 in quanto a robustezza, il suo unico tallone d'Achille è la permeabilità ad attacchi di tipo side-channel. yescrypt Piccola menzione per yescrypt, appartenente alla famiglia "Scrypt", pensato per essere ancora più resistente di Scrypt agli attacchi GPU e FPGA ma con una gestione più intelligente delle risorse. Grazie alle sue peculiarità, di fatto, è diventato il successore spirituale di Bcrypt nei sistemi operativi gnu/linux dove, a cominciare da Fedora, passando per Debian, Ubuntu, Arch, Kali, è il default per la cifratura delle password di sistema in /etc/shadow. È talmente incardinato ormai nei sistemi operativi, che è la libreria libxcrypt di yescrypt a gestire la tipica funzione crypt() di C che è la base della crittografia su tutti i sistemi gnu/linux moderni. La sua robustezza unita alla gestione intelligente delle risorse lo rende un coltellino svizzero di riferimento utile per es. per versione custom di LUKS su sistemi embedded, che magari fanno uso di cpu meno recenti, oppure come opzione per strumenti di backup specialistici Di fatto, sui sistemi operativi, yescrypt s'è guadagnato un consenso amplissimo dovuto alla sua scalabilità, alla sua capacità di usare anche la ROM per rendere il cracking ancora più difficile e senza pesare sulla RAM e alla sua compatibilità potendosi inserire perfettamente nella storica funzione crypt() di C come detto prima. Se Argon2 è il vincitore accademico avendo vinto il Password Hashing Competition del 2015, yescrypt per la sua robustezza, efficienza e flessibilità si ritaglia un profilo di indispensabilità nei sistemi operativi, Argon2 E veniamo al dominatore indiscusso di questa che non è una llista esaustiva di KDF. Argon2 è LO standard moderno per il password hashing raccomandato da OWASP e IETF. È il riferimento per praticamente ogni password manager: Bitwarden, KeppasXC, 1Password, a cui assegnanp la protezione della Master Password È la scelta principale per la cifratura degli hard disk anche con impostazioni molto aggressive, in ragione delle quali un ritardo di mezzo secondo (un tempo enorme se venisse scalato esponenzialmente) nell'apertura di un HD è assolutamente accettabile. È il default di LUKS2 (LUKS1 usava PBKDF2) e di VeraCrypt, con cui ha sostituito SHA-512. Come Bcrypt, è implementato estensivamente su praticamente ogni frameword web e backend, da PHP, Django (Python), Laravel fino a Node.js. Nei sistemi operativi, laddove yescrytpt domina nella gestione delle password utente, Argon2 è usato per compiti più critici. Dal kernel Linux per gestire internamente le chiavi crittografiche o da macOS / iOS, dove algoritmi proprietari ispirati fortemente ad Argon2, proteggono i dati nel Secure Enclave. Argon2 setta 3 parametri principali per regolare la sua forza: t: iterazioni, quante volte vengono rimescolati i dati (default Bitwarden = 3) m: memoria, quanta ram deve occupare il calcolo. Questa è la misura anti-GPU (default Bitwarden = 16 (64MB)) p: parallelismo, quanti core della cpu usare. Questa è la misura anti-CPU (default Bitwarden = 4) La variante id è anche resistente agli attacchi side-channel perché impediscono a un attaccante di capire la password osservando i tempi di accesso alla memoria. Un piccolo esempio: hashing di una password con Argon2 Il grosso vantaggio degli algoritmi di kdf è che sono naturalmente resilienti rispetto all'evoluzione tecnologica che produce macchine con sempre maggiore potenza di calcolo. Da pbkdf2 in poi, il salt implicito che invalida le rainbow table precalcolate e la possibilità di calibrare il key stretching in moda da agire intensivamente su ram e cpu, permettono all'algoritmo di adeguarsi per conservare la sua robustezza. Mini-script per l'hashing di una password fornita dall'utente con argon2 settato al default di Bitwarden: echo -n "Password: "; read -s PASSWORD Genero un Salt casuale di 128 bit SALT=$(openssl rand -base64 128) PASSWORDHASH=$(echo "${PASSWORD}" | argon2 "${SALT}" -m 16 -t 3 -p 4 -id -e) PASSWORDHASH e SALT sono i dati che verranno archiviati e, poiché argon2 "frulla" la password con un salt, è praticamente impossibile risalire alla password originale. La verifica è tuttavia banale perché, avendo il salt e la password da verificare, si ricrea l'hash con argon2 e si confronta con l'hash memorizzato. Per maggior sicurezza salt e digest possono essere memorizzati in punti differenti. L'importante è che possano essere recuperate a partire dall'utente. Gestione del pepper Col pepper le cose cambiano un pochino perché: deve essere archiviato con tutte le paranoie possibili in un punto diverso dal database degli utenti il key rotation del pepper non è banale Mini-script che mostra come applicare salt e pepper all'hashing di una password: L'utente inserisce la password echo -n "Password: "; read -s PASSWORD Genero un Salt casuale di 128 bit unico per ogni utente SALT=$(openssl rand -base64 128) Anche PEPPER sarà qualcosa del tipo "openssl rand -base64 128" e si troverà in un punto esterno al database degli utenti. PEPPER=$(getpepperfromext) Digest della password+salt PASSWORDHASH=$(echo "${PASSWORD}" | argon2 "${SALT}" -m 16 -t 3 -p 4 -id -e) HMAC del digest con PEPPER come chiave PASSWORDPEPPER=$(echo "${PASSWORDHASH}" | openssl dgst -sha256 -hmac "${PEPPER}" -binary | base64) HSM Quella vista prima è una versione molto edulcorata di ciò che avviene nella realtà. Il pepper, non può essere gestito con leggerezza visto che è un segreto che protegge non un singolo oggetto ma intere classi, come db di utenti. L'apparato che gestisce chiavi di questo tipo e di questa importanza, deve essere robusto, praticamente inattaccabile, quasi completamente isolato dal resto dei sistemi a meno delle applicazioni, e solo di quelle, che hanno il permesso di richiedere una chiave, Apparati hardware specializzati che assolvono a tutte queste funzioni e anche di più, sono gli HSM (Hardware Security Module) che garantiscono il ciclo di vita delle chiavi, dalla generazione alla distruzione, includendo versionamento, rotazione e backup. Sono concepiti per resistere anche a manipolazioni forzate che possono innescare un meccanismo di autodistruzione e, particolare rilevante, le operazioni crittografiche basate sulle chiavi protette vengono svolte dall'hsm che consegna al client il risultato delle operazioni, non le chiavi. Nel nostro caso, l'HSM dovrebbe restituirci l'hmac del digest della password che gli inviamo. Key / Algo Rotation Cosa succede se cambio pepper o algoritmo (anche la sua configurazione)? Non avendo disponibilità in alcun modo della password dovrò adottare una strategia ad-hoc. Fra tutti gli scenari possibili, il miglior compromesso fra sicurezza e comodità secondo me, è quello basato sul wrapping. È necessario innanzitutto che vengano conservate le versioni delle chiavi per i servizi che le richiedono. E a questo dovrebbe pensarci l'HSM, se ce n'è uno o qualcosa di custom che abbia funzionalità analoghe. Inoltre dovrebbero esserci dei flag che indichino quali sono gli utenti a cui sono state applicate le nuove configurazioni. Caso A: Algo rotation Supponiamo che l'algoritmo di hashing venga cambiato o vengano cambiate le sue configurazioni. Premessa: Nel mio DB degli utenti, in corrispondenza di ogni utente, avrò: il digest della password "pepato": HMAC ( pepper, HASH ( salt, password ) ) il salt Il wrapping: La strategia sarà quello di "avvolgere" la password di ogni utente col nuovo algoritmo, settare un qualche flag che mi indichi l'operazione compiuta e archiviare il tutto. Imponiamo il nuovo algoritmo a tutti gli utenti "imbustando" il digest attuale (in questo caso 'HMAC in realtà, visto che abbiamo a che fare anche col pepper) con il nuovo digest HASH\NEW: HASH\NEW ( salt\new, HMAC ( pepper, HASH ( salt, password ) ) ). Per ogni utente averemo dunque: il nuovo digest al posto di quello vecchio, il nuovo salt il vecchio salt Settiamo il flag del cambio algoritmo a true (o quello che è) Quando l'utente effettuerà il login con successo e il flag sarà a "true", abbiamo la password che ci permetterà di eliminare il vecchio "involucro" e ripristinare l'HMAC del nuovo digest: HMAC ( pepper, HASH\NEW ( salt\new, password ) ) e il flag ritornerà a "false" Considerazioni: La sicurezza non viene compromessa perché il digest di un digest, con KDF configurate a dovere, non comporta alcun rischio. La fase di verifica è quella che si complica di più perché in base al valore del flag, dovrà essere effettuata in maniera differente. Se il flag è "true" (nella nostra convenzione), dopo il login devo avere gli elementi per calcolare il digest in questo modo: HASH\NEW ( salt\new, HMAC ( pepper, HASH ( salt, password ) ) ). Se il flag è a false, calcolerò al solito: HMAC ( pepper, HASH\NEW ( salt\new, password ) ) Caso B: Pepper rotation Supponiamo che a ruotare sia il pepper. Procediamo sempre con il wrapping massivo su tutti gli utenti incapsulando il digest : HMAC ( pepper, HASH ( salt, password ) ) con quello nuovo: HMAC ( pepper\new, HMAC ( pepper, HASH ( salt, password ) ) ) mettendo il flag a "true". Come prima, una volta che gli utenti cominceranno a fare il login, se il flag è "true" innanzitutto verificherò che: HMAC ( pepper\new, HMAC ( pepper, HASH ( salt, password ) ) ) sia uguale a ciò che è stato archiviato. Se così fosse, ora che sono di nuovo in possesso della password, ripristinerò l'HMAC con: HMAC ( pepper\new, HASH ( salt, password ) )_ memorizzandolo al posto di quello vecchio e rimettendo il flag a false. Considerazioni: La modifica massiva delle password degli utenti, stavolta passa dall'HSM e potrebbe essere un problema perché un HSM è progettato per scoraggiare flooding di richieste. È vero che il pepper è sempre lo stesso per tutti gli utenti ma, come ricordavo prima, di solito un HSM non fornisce i suoi segreti ma solo i risultati crittografici delle loro applicazioni. #kdf #pbkdf2 #bcrypt #scrypt #yescrypt #argon2 #luks #cryptography #aes #sha #digest #RainbowTable #BruteForce #salt #pepper #entropy #hsm #hmac #hash]]> password hashing

Dopo aver capito come creare password inviolabili anche avendo a disposizione tutta l'energia termica dell'universo, pensiamo al modo migliore per archiviarle.

Pensare di lasciare la password raw in un database, rappresenta un grosso rischio in virtù di un possibile attacco offline.

Una prima linea di difesa consiste nel memorizzare il digest della password, una stringa alfanumerica univoca generata da un apposito algoritmo, così da lasciare nelle mani dell'attaccante degli oggetti che, per la loro non invertibilità, non permettono di risalire alle password.

La scelta dell'algoritmo di hashing diventa critica al fine di scongiurare altri tipi di attacchi. Ad es. SHA-256, pur essendo ottimo e molto efficiente per il digest e la firma anche di file di grandi dimensioni, mostra il fianco, proprio in virtù della sua velocità, nel caso di attacchi con:

  • brute-force: si calcola l’hash di password casuali fino a trovare una corrispondenza,
  • dizionario: un'alternativa intelligente alla forza bruta. Si punta alle password più comuni, si calcola l'hash e si controlla se c'è corrispondenza.
  • Rainbow Table: l'attacco al dizionario più insidioso di tutti

Oltre al fatto che, la funzione di hashing , essendo deterministica, permette di capire chi sono gli utenti che hanno la stessa password, dal momento che avranno lo stesso digest.

Rainbow Table

Una Rainbow Table è un enorme dizionario pre-calcolato che contiene:

  • Milioni di password comuni.
  • Il relativo hash corrispondente.

Invece di calcolare l’entropia di ogni tentativo, l’attaccante ruba il database degli hash e fa un semplice “Cerca e Trova”. Se l’hash della tua password è nella tabella, la tua password è violata in millisecondi, indipendentemente da quanto fosse alta la sua entropia teorica.

Oss.: Una password totalmente casuale, generata da un CSPRNG affidabile, con un'alta entropia (>120), rimarrebbe comunque inviolabile anche dalla rainbow table perché la probabilità che quella password si trovi nel dizionario, sarebbe equivalente ad indovinarla.

Come ti blocco la Rainbow Table: Il “Salt” (sale)

Per rendere inutili le Rainbow Table, i sistemi sicuri utilizzano il Salt. Il salt è una stringa di dati casuali (generati da una sorgente d’entropia affidabile ovviamente) che viene aggiunta alla password prima di calcolarne il digest.

In questo modo le rainbow table vengono vanificate perché gli hash precalcolati sulle password raccolte, mancando il salt, non valgono più. Anche se due utenti avessero la stessa password, avrebbero degli hash completamente diversi.

Anche per questo motivo non è un problema che il salt sia pubblico, perché il suo obiettivo non è nascondere quello che è un pezzetto di password a tutti gli effetti, ma di impedire economie di scala degli attacchi perché, pur potendo disporre offline di un database di decine di milioni di utenti, gli hash della mia Rainbow Table (che può arrivare a pesare anche decine di GB) andrebbero tutti ricalcolati per ogni utente, con un costo computazionale e di archiviazione inimmaginabile.

Per riassumere, gli ingredienti di base sono:

  1. una buona sorgente d’entropia: una fonte di casualità certificata per generare un salt unico;
  2. entropia della password: sempre buona norma, ove possibile, come sappiamo ormai fare (https://noblogo.org/aytin/come-generare-una-password-o-un-keyfile-sicuri-trilogia-della-password-1-di). Evita attacchi brute-force o al dizionario in cui l’attaccante prova a indovinare;
  3. salt: protegge la password dagli attacchi basati su database pre-calcolati (Rainbow Table).

Il livello successivo: Il Pepper

È vero che col salt andiamo a complicare lo sfruttamento di un attacco offline ma possiamo fare di meglio.

Il punto d'attenzione è che il salt protegge le password di tutti gli utenti. Ma un attaccante potrebbe non essere affatto interessato a violare ogni singolo utente (niente economia di scala) ma solo alcuni. E allora l'attacco attraverso Ranbow Table potrebbe essere di nuovo praticabile.

Ma gli informatici sono dei gran giocherelloni, si sa. Visto che abbiamo già il “sale”, perché non finire aggiustando con un po’ di “pepe”? Detto, fatto!

Il pepper, come il salt, è un'altra password generata con gli stessi criteri del salt ma le analogie finiscono qua perché:

  • a differenza del salt che si trova nel database, il pepper è separato da ques'ultimo. L'ideale sarebbe un HSM;
  • Il salt è visibile a tutti, attaccante compreso. Il pepper è segreto. Un eventuale data breach che permette all'attaccante di disporre offline di tutto il database degli utenti, “vedrà” certamente gli eventuali salt ma sarà ignaro del fatto che gli mancherà sempre un pezzo di chiave;
  • il salt è diverso per ogni utente, il pepper, di solito, è unico;
  • il salt serve a rendere uniche la password degli utenti, il pepper protegge l'intero database da attacchi offline.

Il pepper è la chiave di un HMAC, o di un meccanismo di cifratura simmetrica, applicato al digest della password (che ricordo essere salt+password in realtà), che sarà ciò che verrà archiviato.

Va detto che l'uso del “pepper” complica ulteriormente lo scenario di archiviazione. Nella stragrande maggioranza dei casi è sufficiente scegliere un buon algoritmo di password hashing (vedi paragrafo successivo) per scoraggiare gli attaccanti. “Pepare” le password prevederebbe, come detto sopra, l'uso di un HSM per es, e tutta una serie di riflessioni di contorno che evidenzierò più avanti.

Final step: L'hashing

L'ultimo punto da dettagliare è l'hash della password.

L'hash crittografico, in uso in questi casi, deve soddisfare le seguenti proprietà:

  1. resistenza alla pre-immagine: dato un hash h, deve essere impossibile trovare una password p t.c. H(p) = h (non invertibilità della funzione hash)
  2. resistenza alla pre-immagine secondaria: dato una password p1, deve essere impossibile trovare un'altra password p2 t.c. H(p1) = H(p2) (resistenza debole alle collisioni)
  3. resistenza alle collisioni: è impossibile trovare due password diverse, p1 e p2, t.c. H(p1) = H(p2) (resistenza forte alle collisioni)
  4. effetto valanga: il cambio di un solo bit della password deve cambiare radicalmente l'intero hash

In un sistema moderno, l'hash non può essere delegato a funzioni di tipo SHA perché nascono per altri compiti,

SHA-2 e SHA-3 nascono per il digest veloce, per verificare l'integrità di file anche molto grossi o firmare documenti. La loro eccellente velocità diventa il loro più grosso difetto quando si parla di password. Negli scenari precedenti di attachi offline, l'hacker che dispone di una grossa potenza di calcolo, può ricostituire velocemente le rainbow table per n utenti. Magari non di tutti ma di quelli attenzionati.

Le funzioni di derivazione della chiave (KDF) come pbkdf2 e quelle ancora più estreme come B/Scrypt, Argon2, oltre che soddisfare tutti i punti precedentemente elencati tipici di funzioni di password hashing, sono progettate per essere computazionalmente pesantissime da calcolare perché il loro scopo non è il digest ma la protezione di un segreto contro il brute-force. E mentre le vecchie KDF come pbdfk2 sono CPU bound, ma non GPU bound, le KDF più moderne come Bcrypt, Scrypt ma soprattutto Argon2, agiscono pesantemente su tempo, memoria e parallelismo e l'attacco offline di cui sopra diventa impraticabile.

PBKDF2

È il decano delle KDF. Applica iterativamente una funzione pseudorandomica, come HMAC con uno SHA, con salt alla password. Il conteggio delle iterazioni è un parametro configurabile.

PBDKF2 è uno standard di lunga data ampiamente adottato. Se non ci sono necessità stringenti di sicurezza o requisiti legacy, è una buona scelta.

Il fatto di essere solo CPU bound però non la rende la scelta ideale in scenari dove gli attaccanti possono attingere a risorse di calcolo considerevoli

Bcrypt

Basato su Blowfish, anche Bcrypt usa un hash crittografico sulla password con parametri il salt e un fattore di costo.

Il fattore di costo aumenta esponenzialmente il numero di iterazioni per adattarsi all'aumento di potenza di calcolo dell'hardware.

Bcrypt è stato progetto per essere lento e resistente a semplici attacchi di forzat bruta. Tuttavia, il basso utilizzo di ram richiesto dal calcolo lo rendono poco resistente ad attacchi sferrati usando hardware specializzato.

Bcrypt ha dalla sua una storia solidissima in ragione della quale da 20 anni a questa parte non sono state trovate vulnerabilità critiche nel suo design.

Per questo motivo Bcrypt cifra le password di sistema di OpenBSD dal 1999, come pure ha cifrato quelle di tante distro Linux per anni, prima che passassero ad Argon2 o yescrypt (default di Fedora).

Domina nei framework web ([Python] Django, [Ruby] Ruby on Rails, [PHP] Laravel), [Java] Spring, Node.js), nelle applicazioni (Ansible / Terraform, Docker), nel web (la cifratura in .htpasswd di Apache e Nginx) visto che la sua semplcitià di implementazione gli ha permesso di trovarsi praticamente in ogni linguaggio.

È presente come alternativa anche nei password manager benché molti di essi abbiano spostato il default verso Argon2 o PBKDF2 per conformità agli standard FIPS.

È molto semplice implementare e anche da usare perché bisogna agire solo sul fattore di costo (consigliato almeno 10-12, altrimenti diventa troppo vulnerabile ad attacchi sferrati attraverso la GPU)

Scrypt

Rilasciato nel 2009, Scrypt è stato il primo algoritmo a introdurre il concetto di Memory Hardness ed è stato progettato per rendere economicamente poco conveniente il ricorso ad hardware specializzato come gli ASIC o i FPGA e incidere pesantemente su CPU, ram e parallelismo.

Il suo alveo principale sono state le cripto-valute, molte monete lo usano per il mining.

Scrypt lo troviamo in quasi tutti i linguaggi di programmazione, in Tarsnap, servizio di baclup online creato dallo stesso autore di Scrypt, è stato usato da LastPass ed è presente come opzione in VeraCrypt per derivare la chiave dalla password. Fino ad Android 9 era l'algoritmo usato per la FDE del dispositvio (passato poi al FBE) . Presente anche su FreeBSD come opzione per la cifratura delle password di sistema e come opzione su LUKS per la cifratura degli slot delle chiavi.

Su Scrypt i parametri da configurare sono:

  • Costro CPU/Memoria (N): un parametro che aumenta i costi computazionali di cpu e memoria
  • DImensione del blocco ®: influenza la larghezza di banda della memoria
  • Parallelizzazione (p): indica quanto deve incidere sul calcolo parallelo

In questo modo riesce ad essere sia CPU bound che GPU bound che, a differenza di Bcrypt, lo rende resistente anche ad attacchi facenti uso di hardware specializzato..

Di contro, in ambiente in cui siamo vincolati dalle risorse disponibili, la sua potenza diventa un fattore limitante. Quasi paragonabile ad Argon2 in quanto a robustezza, il suo unico tallone d'Achille è la permeabilità ad attacchi di tipo side-channel.

yescrypt

Piccola menzione per yescrypt, appartenente alla famiglia “Scrypt”, pensato per essere ancora più resistente di Scrypt agli attacchi GPU e FPGA ma con una gestione più intelligente delle risorse.

Grazie alle sue peculiarità, di fatto, è diventato il successore spirituale di Bcrypt nei sistemi operativi gnu/linux dove, a cominciare da Fedora, passando per Debian, Ubuntu, Arch, Kali, è il default per la cifratura delle password di sistema in /etc/shadow.

È talmente incardinato ormai nei sistemi operativi, che è la libreria libxcrypt di yescrypt a gestire la tipica funzione crypt() di C che è la base della crittografia su tutti i sistemi gnu/linux moderni.

La sua robustezza unita alla gestione intelligente delle risorse lo rende un coltellino svizzero di riferimento utile per es. per versione custom di LUKS su sistemi embedded, che magari fanno uso di cpu meno recenti, oppure come opzione per strumenti di backup specialistici

Di fatto, sui sistemi operativi, yescrypt s'è guadagnato un consenso amplissimo dovuto alla sua scalabilità, alla sua capacità di usare anche la ROM per rendere il cracking ancora più difficile e senza pesare sulla RAM e alla sua compatibilità potendosi inserire perfettamente nella storica funzione crypt() di C come detto prima.

Se Argon2 è il vincitore accademico avendo vinto il Password Hashing Competition del 2015, yescrypt per la sua robustezza, efficienza e flessibilità si ritaglia un profilo di indispensabilità nei sistemi operativi,

Argon2

E veniamo al dominatore indiscusso di questa che non è una llista esaustiva di KDF.

Argon2 è LO standard moderno per il password hashing raccomandato da OWASP e IETF.

È il riferimento per praticamente ogni password manager: Bitwarden, KeppasXC, 1Password, a cui assegnanp la protezione della Master Password

È la scelta principale per la cifratura degli hard disk anche con impostazioni molto aggressive, in ragione delle quali un ritardo di mezzo secondo (un tempo enorme se venisse scalato esponenzialmente) nell'apertura di un HD è assolutamente accettabile. È il default di LUKS2 (LUKS1 usava PBKDF2) e di VeraCrypt, con cui ha sostituito SHA-512.

Come Bcrypt, è implementato estensivamente su praticamente ogni frameword web e backend, da PHP, Django (Python), Laravel fino a Node.js.

Nei sistemi operativi, laddove yescrytpt domina nella gestione delle password utente, Argon2 è usato per compiti più critici. Dal kernel Linux per gestire internamente le chiavi crittografiche o da macOS / iOS, dove algoritmi proprietari ispirati fortemente ad Argon2, proteggono i dati nel Secure Enclave.

Argon2 setta 3 parametri principali per regolare la sua forza:

  • t: iterazioni, quante volte vengono rimescolati i dati (default Bitwarden = 3)
  • m: memoria, quanta ram deve occupare il calcolo. Questa è la misura anti-GPU (default Bitwarden = 16 (64MB))
  • p: parallelismo, quanti core della cpu usare. Questa è la misura anti-CPU (default Bitwarden = 4)

La variante id è anche resistente agli attacchi side-channel perché impediscono a un attaccante di capire la password osservando i tempi di accesso alla memoria.

Un piccolo esempio: hashing di una password con Argon2

Il grosso vantaggio degli algoritmi di kdf è che sono naturalmente resilienti rispetto all'evoluzione tecnologica che produce macchine con sempre maggiore potenza di calcolo. Da pbkdf2 in poi, il salt implicito che invalida le rainbow table precalcolate e la possibilità di calibrare il key stretching in moda da agire intensivamente su ram e cpu, permettono all'algoritmo di adeguarsi per conservare la sua robustezza.

Mini-script per l'hashing di una password fornita dall'utente con argon2 settato al default di Bitwarden:

echo -n "Password: "; read -s PASSWORD
# Genero un Salt casuale di 128 bit
SALT=$(openssl rand -base64 128)
PASSWORD_HASH=$(echo "${PASSWORD}" | argon2 "${SALT}" -m 16 -t 3 -p 4 -id -e)

PASSWORD_HASH e SALT sono i dati che verranno archiviati e, poiché argon2 “frulla” la password con un salt, è praticamente impossibile risalire alla password originale.

La verifica è tuttavia banale perché, avendo il salt e la password da verificare, si ricrea l'hash con argon2 e si confronta con l'hash memorizzato.

Per maggior sicurezza salt e digest possono essere memorizzati in punti differenti. L'importante è che possano essere recuperate a partire dall'utente.

Gestione del pepper

Col pepper le cose cambiano un pochino perché:

  • deve essere archiviato con tutte le paranoie possibili in un punto diverso dal database degli utenti
  • il key rotation del pepper non è banale

Mini-script che mostra come applicare salt e pepper all'hashing di una password:

# L'utente inserisce la password
echo -n "Password: "; read -s PASSWORD

# Genero un Salt casuale di 128 bit unico per ogni utente
SALT=$(openssl rand -base64 128)

# Anche PEPPER sarà qualcosa del tipo "openssl rand -base64 128"
# e si troverà in un punto esterno al database degli utenti.
PEPPER=$(get_pepper_from_ext)

# Digest della password+salt
PASSWORD_HASH=$(echo "${PASSWORD}" | argon2 "${SALT}" -m 16 -t 3 -p 4 -id -e)

# HMAC del digest con PEPPER come chiave
PASSWORD_PEPPER=$(echo "${PASSWORD_HASH}" | openssl dgst -sha256 -hmac "${PEPPER}" -binary | base64)

HSM

Quella vista prima è una versione molto edulcorata di ciò che avviene nella realtà. Il pepper, non può essere gestito con leggerezza visto che è un segreto che protegge non un singolo oggetto ma intere classi, come db di utenti.

L'apparato che gestisce chiavi di questo tipo e di questa importanza, deve essere robusto, praticamente inattaccabile, quasi completamente isolato dal resto dei sistemi a meno delle applicazioni, e solo di quelle, che hanno il permesso di richiedere una chiave,

Apparati hardware specializzati che assolvono a tutte queste funzioni e anche di più, sono gli HSM (Hardware Security Module) che garantiscono il ciclo di vita delle chiavi, dalla generazione alla distruzione, includendo versionamento, rotazione e backup. Sono concepiti per resistere anche a manipolazioni forzate che possono innescare un meccanismo di autodistruzione e, particolare rilevante, le operazioni crittografiche basate sulle chiavi protette vengono svolte dall'hsm che consegna al client il risultato delle operazioni, non le chiavi. Nel nostro caso, l'HSM dovrebbe restituirci l'hmac del digest della password che gli inviamo.

Key / Algo Rotation

Cosa succede se cambio pepper o algoritmo (anche la sua configurazione)? Non avendo disponibilità in alcun modo della password dovrò adottare una strategia ad-hoc. Fra tutti gli scenari possibili, il miglior compromesso fra sicurezza e comodità secondo me, è quello basato sul wrapping.

È necessario innanzitutto che vengano conservate le versioni delle chiavi per i servizi che le richiedono. E a questo dovrebbe pensarci l'HSM, se ce n'è uno o qualcosa di custom che abbia funzionalità analoghe. Inoltre dovrebbero esserci dei flag che indichino quali sono gli utenti a cui sono state applicate le nuove configurazioni.

Caso A: Algo rotation

Supponiamo che l'algoritmo di hashing venga cambiato o vengano cambiate le sue configurazioni.

Premessa: Nel mio DB degli utenti, in corrispondenza di ogni utente, avrò:

  1. il digest della password “pepato”: HMAC ( pepper, HASH ( salt, password ) )
  2. il salt

Il wrapping: La strategia sarà quello di “avvolgere” la password di ogni utente col nuovo algoritmo, settare un qualche flag che mi indichi l'operazione compiuta e archiviare il tutto.

  1. Imponiamo il nuovo algoritmo a tutti gli utenti “imbustando” il digest attuale (in questo caso 'HMAC in realtà, visto che abbiamo a che fare anche col pepper) con il nuovo digest HASH_NEW: HASH_NEW ( salt_new, HMAC ( pepper, HASH ( salt, password ) ) ).
  2. Per ogni utente averemo dunque:
    1. il nuovo digest al posto di quello vecchio,
    2. il nuovo salt
    3. il vecchio salt
  3. Settiamo il flag del cambio algoritmo a true (o quello che è)
  4. Quando l'utente effettuerà il login con successo e il flag sarà a “true”, abbiamo la password che ci permetterà di eliminare il vecchio “involucro” e ripristinare l'HMAC del nuovo digest: HMAC ( pepper, HASH_NEW ( salt_new, password ) ) e il flag ritornerà a “false“

Considerazioni:

  • La sicurezza non viene compromessa perché il digest di un digest, con KDF configurate a dovere, non comporta alcun rischio.
  • La fase di verifica è quella che si complica di più perché in base al valore del flag, dovrà essere effettuata in maniera differente.
    • Se il flag è “true” (nella nostra convenzione), dopo il login devo avere gli elementi per calcolare il digest in questo modo: HASH_NEW ( salt_new, HMAC ( pepper, HASH ( salt, password ) ) ).
    • Se il flag è a false, calcolerò al solito: HMAC ( pepper, HASH_NEW ( salt_new, password ) )

Caso B: Pepper rotation

Supponiamo che a ruotare sia il pepper. Procediamo sempre con il wrapping massivo su tutti gli utenti incapsulando il digest :

HMAC ( pepper, HASH ( salt, password ) )

con quello nuovo:

HMAC ( pepper_new, HMAC ( pepper, HASH ( salt, password ) ) )

mettendo il flag a “true”.

Come prima, una volta che gli utenti cominceranno a fare il login, se il flag è “true” innanzitutto verificherò che:

HMAC ( pepper_new, HMAC ( pepper, HASH ( salt, password ) ) )

sia uguale a ciò che è stato archiviato. Se così fosse, ora che sono di nuovo in possesso della password, ripristinerò l'HMAC con:

HMAC ( pepper_new, HASH ( salt, password ) )

memorizzandolo al posto di quello vecchio e rimettendo il flag a false.

Considerazioni: La modifica massiva delle password degli utenti, stavolta passa dall'HSM e potrebbe essere un problema perché un HSM è progettato per scoraggiare flooding di richieste.

È vero che il pepper è sempre lo stesso per tutti gli utenti ma, come ricordavo prima, di solito un HSM non fornisce i suoi segreti ma solo i risultati crittografici delle loro applicazioni.

#kdf #pbkdf2 #bcrypt #scrypt #yescrypt #argon2 #luks #cryptography #aes #sha #digest #RainbowTable #BruteForce #salt #pepper #entropy #hsm #hmac #hash

]]> https://noblogo.org/aytin/archiviare-le-password-in-sicurezza-con-kdf-password-hashing-trilogia-della Thu, 29 Jan 2026 17:49:50 +0000 Gestione TOTP in bash https://noblogo.org/aytin/gestione-totp-in-bash <![CDATA[totp In una giornata in cui avevo un po’ di tempo da investire, ho ripreso la versione 2 dello script "Generazione OTP via bash", e ho deciso di renderlo un po’ più flessibile introducendo una logica crud. Anzi, il termine corretto dovrebbe essere "dave" (Delete, Add, View, Edit). !--more-- Che altro aggiungere? Il file è ancora un insieme di coppie chiave-valore (nome account e chiave privata). Il separatore è il simbolo ":". Ma può essere configurato cambiando il valore della variabile "DELIMITER". Lo script è discretamente commentato così, in futuro, riuscirò a ricordare perché ho fatto quello che ho fatto (tipo "Memento"). Le opzioni di gpg per la cifratura/decifratura del file sono configurabili nello script modificando il valore delle variabili "GPG\ENC\OPTIONS" e "GPG\DEC\OPTIONS". L’uso di getopts, mi rendo conto, è solo un esercizio di stile. Non è molto utile per come l’ho usato, visto che ogni optarg corrisponde ad un’operazione autoconclusiva. Ero partito per rimpiazzare ogni costrutto if con combinazioni di lista and / lista or ma le condizioni risultavano talmente complesse da rendere il codice francamente molto più incomprensibile di adesso. In alternativa avrei potuto delegare l’esecuzione delle condizioni ad un insieme di funzioni con una stratificazione tale da ricadere nel punto precedente: offuscamento permanente del codice che va a vanificare l’intenzione iniziale di semplificare il codice e renderlo più leggibile. !/usr/local/bin/bash init() { # CODICI D'ERRORE DECRYPTERR=64 INVALIDOPTIONERR=65 INVALIDACCOUNTERR=66 ACCOUNTNOTFOUNDERR=67 ACCOUNTNAMEEMPTYERR=68 ACCOUNTEXISTSERR=69 INVALIDKEYERR=70 # Colorscheme LIGHTGREEN='\033[1;32m' LIGHTRED='\033[1;31m' NC='\033[0m' # Path del file cifrato contentente i codici 2FA KEYS2FAFILE="path/fileenc.gpg" # Separatore delle coppie chiave-valore DELIMITER=":" # path gpg e opzioni di cifratura/decifratura GPGTTY=$(tty) export GPGTTY #GPGCOMMAND="/usr/local/bin/gpg" GPGENCOPTIONS="--yes -c --s2k-cipher-algo aes256 --s2k-digest-algo sha512 --s2k-mode 3 --s2k-count 260000 - " GPGDECOPTIONS='-d' # Caratteri consentiti nel nome account PATTERN='^[a-zA-Z0-9.-]+$'; # Su MacOS è disponibile "pbcopy", su nix "xsel" case "$(sysctl hw.targettype 2 /dev/null)" in "") CLIPBOARD="xsel -bi" GPGCOMMAND="/usr/bin/gpg";; ) CLIPBOARD="pbcopy" GPGCOMMAND="/usr/local/bin/gpg";; esac # Decifra e carica in ram il contenuto del file cifrato. echo "Decifratura del file degli account in corso..." KEYS2FAFILEDEC=$(${GPGCOMMAND} ${GPGDECOPTIONS} "${KEYS2FAFILE}" 2 /dev/null) # Se la password non è corretta, restituisce un errore. [[ -z "${KEYS2FAFILEDEC}" ]] && { errmsg "${DECRYPTERR}" 1; } infomsg "Fatto." } getaccount() { ACCOUNTSTDIO="$1" # Check nome account vuoto [[ -z "${ACCOUNTSTDIO}" ]] && return "${ACCOUNTNAMEEMPTYERR}" # Check caratteri invalidi nel nome account [[ ! "${ACCOUNTSTDIO}" =~ $PATTERN ]] && return "${INVALIDACCOUNTERR}" # Estrae l'elemento contenente l'id dato in input OTPLINE=$(echo "${KEYS2FAFILEDEC}" | grep "${ACCOUNTSTDIO}:") # Se l'account non esiste, restituisce un errore [[ -z "${OTPLINE}" ]] && return "${ACCOUNTNOTFOUNDERR}" ACCOUNT=$(echo $OTPLINE | cut -d"${DELIMITER}" -f 1) KEY=$(echo $OTPLINE | cut -d"${DELIMITER}" -f 2) } cryptaccountfile() { ACCOUNTFILE="$1" echo -e "\nCifratura del file degli account in corso..." ${GPGCOMMAND} -o "$KEYS2FAFILE" ${GPGENCOPTIONS} <<< $(echo -e "${ACCOUNTFILE}") } noparam() { clear help exit 0 } Visualizza messaggi di errore su stdio errmsg() { if [[ $# -ne 2 ]]; then echo -r"${LIGHTRED}[DEBUG] [errmsg] Numero di parametri non corretto.${NC}."; exit 1 else case $1 in "${DECRYPTERR}" ) echo -e "${LIGHTRED}[ERRORE] Impossibile decriptare il file.${NC}";; "${INVALIDOPTIONERR}" ) echo -e "${LIGHTRED}[ERRORE] Opzione \"$OPTARG\" non valida.${NC}";; "${INVALIDACCOUNTERR}" ) echo -e "${LIGHTRED}ERRORE] Rilevati caratteri non consentiti.\nI caratteri ammessi sono: [a-z[0-9].-${NC}";; "${ACCOUNTNOTFOUNDERR}" ) echo -e "${LIGHTRED}[ERRORE] Account non trovato${NC}";; "${ACCOUNTNAMEEMPTYERR}" ) echo -e "${LIGHTRED}[ERRORE] Nome account vuoto.${NC}";; "${ACCOUNTEXISTSERR}" ) echo -e "${LIGHTRED}[ERRORE] Nome account già esistente${NC}";; "${INVALIDKEYERR}" ) echo -e "${LIGHTRED}[ERRORE] Chiave privata nulla o non corretta.\nLa chiave privata deve essere base32.\n${NC}";; ) echo -e "${LIGHTRED}[ERRORE] Errore generico.${NC}";; esac [[ $2 -eq 1 ]] && exit $2; fi } Visualizza messaggi info su stdio infomsg() { echo -e "${LIGHTGREEN}$1${NC}" } continuemsg() { case $1 in "insert" ) ACTION="creato";; "edit" ) ACTION="modificato";; "delete" ) ACTION="cancellato";; esac echo -n "L'account \"${ACCOUNT}\" sta per essere ${ACTION}. Vuoi continuare? [y|N]: "; read ANSWER; } continueyn() { ANSWER="0" while [[ "${ANSWER}" != "y" ]]; do [[ -z "${ANSWER}" || "${ANSWER}" == "N" ]] && { echo "Operazione annullata"; exit; } [[ "${ANSWER}" != "y" || "${ANSWER}" != "N" ]] && continuemsg "$1" done } totp() { # Se la'ccount non esiste o è invalido, esco con errore getaccount "$1"; RETCODE=$? case "${RETCODE}" in "${ACCOUNTNOTFOUNDERR}" ) errmsg "${ACCOUNTNOTFOUNDERR}" 1;; "${INVALIDACCOUNTERR}" ) errmsg "${INVALIDACCOUNTERR}" 1;; esac echo -e "\nCopia OTP nella clipboard..." # Calcola l'otp e lo trasferisce nella clipboard con xsel oathtool --totp -b "${KEY}" | $CLIPBOARD infomsg "Fatto." exit } insert() { # Se l'account non esiste o è invalido, esco con errore getaccount "$1"; RETCODE=$? case "${RETCODE}" in 0 ) errmsg "${ACCOUNTEXISTSERR}" 1;; "${INVALIDACCOUNTERR}" ) errmsg "${INVALIDACCOUNTERR}" 1;; esac ACCOUNT="$1" # Inserisci la chiave echo -en "Nuovo account: ${ACCOUNT}\nInserisci la nuova chiave privata: "; read KEY while [[ -z "${KEY}" || ! $(echo ${KEY} | oathtool -b - 2 /dev/null) ]]; do errmsg "${INVALIDKEYERR}" 0 echo -n "Inserisci la chiave privata: "; read KEY done infomsg "\nNuovo account: ${ACCOUNT}\nNuova chiave privata: ${KEY}" continueyn "insert" # Appendo il nuovo record nel file degli account KEYS2FAFILEDEC+="\n${ACCOUNT}${DELIMITER}${KEY}" infomsg "L'account \"${ACCOUNT}\" è stato creato con successo." # Cifratura del file degli account cryptaccountfile "${KEYS2FAFILEDEC}" infomsg "Fatto." exit } edit() { # Se la'ccount non esiste o è invalido, esco con errore getaccount "$1"; RETCODE=$? case "${RETCODE}" in "${ACCOUNTNOTFOUNDERR}" ) errmsg "${ACCOUNTNOTFOUNDERR}" 1;; "${INVALIDACCOUNTERR}" ) errmsg "${INVALIDACCOUNTERR}" 1;; esac # Faccio una copia dell'account per un eventuale ripristino durante # la fase di input ACCOUNTTEMP="${ACCOUNT}" ACCOUNTMOD="${ACCOUNT}" # Inserisco il nuovo nome account. # 1. Se è vuoto: è la conferma dell'account inserito all'inizio e proseguo # 2. Se il nome è invalido: sollevo un'eccezione e reitero # 3. Se il nome è valido: # a. Se è un nome nuovo: acquisisco il nuovo nome, recupero nome e chiave dell'account di partenza e proseguo # b. Sè è lo stesso nome di partenza: è la conferma dell'account iniziale e proseguo # c. Se è un altro nome esistente o invalido: come il punto 2. while true; do echo echo -en "Account: ${ACCOUNT}\nInserisci nuovo nome account: "; read ACCOUNTMOD; getaccount "${ACCOUNTMOD}"; RETCODE=$? case "${RETCODE}" in # Punto 1. "${ACCOUNTNAMEEMPTYERR}" ) ACCOUNTMOD="${ACCOUNT}"; break;; # Punto 2 "${INVALIDACCOUNTERR}" ) errmsg "${INVALIDACCOUNTERR}" 0;; # Punto 3a. "${ACCOUNTNOTFOUNDERR}" ) getaccount "${ACCOUNTTEMP}"; break;; # Punti 3b e 3c, rispettivamente 0 ) [[ "${ACCOUNTMOD}" == "${ACCOUNTTEMP}" ]] && break \ || { getaccount "${ACCOUNTTEMP}"; errmsg "${ACCOUNTEXISTSERR}" 0; };; esac done [[ "${ACCOUNT}" != "${ACCOUNTMOD}" && ! -z "${ACCOUNTMOD}" ]] && msg="\nL'account \"${ACCOUNT}\" è stato modificato in \"${ACCOUNTMOD}\"." \ || msg="\nNessuna modifica rilevata.\n" infomsg "${msg}" # Modifica la chiave privata KEYMOD="${KEY}" echo while true; do echo -en "Chiave privata: ${KEY}\nInserisci la nuova chiave privata: "; read KEYMOD if [[ -z $KEYMOD ]]; then KEYMOD="${KEY}"; break elif [[ ! $(echo "${KEYMOD}" | oathtool -b - 2 /dev/null) ]]; then errmsg "${INVALIDKEYERR}" 0; KEYMOD="${KEY}" else break fi done # Se c'è stata almeno una modifica (account/key), sovrascrivo il record. Altrimenti esco senza fare nulla. if [[ "${ACCOUNT}" != "${ACCOUNTMOD}" || "${KEY}" != "${KEYMOD}" ]]; then # Conferma modifica infomsg "\nAccount: ${ACCOUNT}\nChiave privata: ${KEY}\nNuovo account: ${ACCOUNTMOD}\nNuova chiave privata: ${KEYMOD}\n" continueyn "edit" # Modifica del file degli account KEYS2FAFILEDECTEMP=$(sed "s/${ACCOUNT}${DELIMITER}${KEY}/${ACCOUNTMOD}${DELIMITER}${KEYMOD}/" <<< "${KEYS2FAFILEDEC}") infomsg "L'account \"${ACCOUNT}\" è stato modificato con successo." # Cifratura del file degli account cryptaccountfile "${KEYS2FAFILEDECTEMP}" else infomsg "Nessuna modifica rilevata." fi infomsg "Fatto." } delete() { if getaccount "$1"; then # Conferma eliminazione infomsg "\nAccount: ${ACCOUNT}\nChiave privata: ${KEY}\n" continueyn "delete" # Cancellazione account KEYS2FAFILEDECTEMP=$(sed "/$ACCOUNT/d" <<< "${KEYS2FAFILEDEC}") infomsg "L'account \"$ACCOUNT\" è stato eliminato." # Cifratura del nuovo file degli account cryptaccountfile "${KEYS2FAFILEDECTEMP}" infomsg "Fatto." else errmsg "${ACCOUNTNOTFOUNDERR}" 1 fi } list() { echo while read LINE; do cut -d"${DELIMITER}" -f 1 <<< "${LINE}" done <<< "${KEYS2FAFILEDEC}" } help() { cat<<EOF Usa come: ./totp.sh [options] ARG dove: [options] -l restituisce la lista degli account. -t nomeaccount restituisce l'otp per quell'account. -i nomeaccount inserisce un nuovo account. -d nomeaccount cancella nomeaccount. -e nomeaccount modifica nomeaccount. -h stampa questa pagina di help. ESEMPI: RESTITUISCE LA LISTA DEGLI ACCOUNT totp.sh -l INSERISCE UN ACCOUNT totp.sh -i dropbox CANCELLA UN ACCOUNT totp.sh -d megaupload MODIFICA UN ACCOUNT totp.sh -e paypal GENERA OTP totp.sh -t firefoxsync EOF } main() { init while getopts "lt:i:e:d:" opt; do case $opt in l ) list ;; t ) totp $OPTARG ;; i ) insert $OPTARG ;; e ) edit $OPTARG ;; d ) delete $OPTARG ;; ) clear;errmsg "${INVALIDOPTIONERR}" 1;; esac done shift $(($OPTIND - 1)) } [[ $# -eq 0 || $# -eq 1 && "$1" == "-h" ]] && noparam || main $* #bash #totp #cryptography #gpg #scripting]]> totp

In una giornata in cui avevo un po’ di tempo da investire, ho ripreso la versione 2 dello script “Generazione OTP via bash”, e ho deciso di renderlo un po’ più flessibile introducendo una logica crud. Anzi, il termine corretto dovrebbe essere “dave” (Delete, Add, View, Edit). Che altro aggiungere?

  • Il file è ancora un insieme di coppie chiave-valore (nome account e chiave privata).
  • Il separatore è il simbolo “:”. Ma può essere configurato cambiando il valore della variabile “DELIMITER”.
  • Lo script è discretamente commentato così, in futuro, riuscirò a ricordare perché ho fatto quello che ho fatto (tipo “Memento”).
  • Le opzioni di gpg per la cifratura/decifratura del file sono configurabili nello script modificando il valore delle variabili “GPG_ENC_OPTIONS” e “GPG_DEC_OPTIONS”.
  • L’uso di getopts, mi rendo conto, è solo un esercizio di stile. Non è molto utile per come l’ho usato, visto che ogni optarg corrisponde ad un’operazione autoconclusiva.
  • Ero partito per rimpiazzare ogni costrutto if con combinazioni di lista and / lista or ma le condizioni risultavano talmente complesse da rendere il codice francamente molto più incomprensibile di adesso. In alternativa avrei potuto delegare l’esecuzione delle condizioni ad un insieme di funzioni con una stratificazione tale da ricadere nel punto precedente: offuscamento permanente del codice che va a vanificare l’intenzione iniziale di semplificare il codice e renderlo più leggibile.

#!/usr/local/bin/bash


init() {
    # CODICI D'ERRORE
    DECRYPT_ERR=64
    INVALID_OPTION_ERR=65
    INVALID_ACCOUNT_ERR=66
    ACCOUNT_NOT_FOUND_ERR=67
    ACCOUNT_NAME_EMPTY_ERR=68
    ACCOUNT_EXISTS_ERR=69
    INVALID_KEY_ERR=70

    # Colorscheme
    LIGHT_GREEN='\033[1;32m'
    LIGHT_RED='\033[1;31m'
    NC='\033[0m'

    # Path del file cifrato contentente i codici 2FA
    KEYS_2FA_FILE="<path/file_enc.gpg>"

    # Separatore delle coppie chiave-valore
    DELIMITER=":"

    # path gpg e opzioni di cifratura/decifratura
    GPG_TTY=$(tty)
    export GPG_TTY

    #GPG_COMMAND="/usr/local/bin/gpg"
    GPG_ENC_OPTIONS="--yes -c --s2k-cipher-algo aes256 --s2k-digest-algo sha512 --s2k-mode 3 --s2k-count 260000 - "
    GPG_DEC_OPTIONS='-d'

    # Caratteri consentiti nel nome account
    PATTERN='^[a-zA-Z0-9._-]+$';

    # Su MacOS è disponibile "pbcopy", su *nix "xsel"
    case "$(sysctl hw.targettype 2>/dev/null)" in
        "")
            CLIPBOARD="xsel -bi"
            GPG_COMMAND="/usr/bin/gpg";;
         *)
            CLIPBOARD="pbcopy"
            GPG_COMMAND="/usr/local/bin/gpg";;
    esac

    # Decifra e carica in ram il contenuto del file cifrato.
    echo "Decifratura del file degli account in corso..."
    KEYS_2FA_FILE_DEC=$(${GPG_COMMAND} ${GPG_DEC_OPTIONS} "${KEYS_2FA_FILE}" 2>/dev/null)

    # Se la password non è corretta, restituisce un errore.
    [[ -z "${KEYS_2FA_FILE_DEC}" ]] && { err_msg "${DECRYPT_ERR}" 1; }
    info_msg "Fatto."
}


get_account() {
    ACCOUNT_STDIO="$1"

    # Check nome account vuoto
    [[ -z "${ACCOUNT_STDIO}" ]] && return "${ACCOUNT_NAME_EMPTY_ERR}"

    # Check caratteri invalidi nel nome account
    [[ ! "${ACCOUNT_STDIO}" =~ $PATTERN ]] && return "${INVALID_ACCOUNT_ERR}"

    # Estrae l'elemento contenente l'id dato in input
    OTP_LINE=$(echo "${KEYS_2FA_FILE_DEC}" | grep "${ACCOUNT_STDIO}:")

    # Se l'account non esiste, restituisce un errore
    [[ -z "${OTP_LINE}" ]] && return "${ACCOUNT_NOT_FOUND_ERR}"

    ACCOUNT=$(echo $OTP_LINE | cut -d"${DELIMITER}" -f 1)
    KEY=$(echo $OTP_LINE | cut -d"${DELIMITER}" -f 2)
}


crypt_account_file() {
    ACCOUNT_FILE="$1"
    echo -e "\nCifratura del file degli account in corso..."
    ${GPG_COMMAND} -o "$KEYS_2FA_FILE" ${GPG_ENC_OPTIONS} <<< $(echo -e "${ACCOUNT_FILE}")
}


no_param() {
    clear
    help
    exit 0
}


# Visualizza messaggi di errore su stdio
err_msg() {
    if [[ $# -ne 2 ]]; then
        echo -r"${LIGHT_RED}[DEBUG] [err_msg] Numero di parametri non corretto.${NC}."; exit 1
    else
        case $1 in
            "${DECRYPT_ERR}"            ) echo -e "${LIGHT_RED}[ERRORE] Impossibile decriptare il file.${NC}";;
            "${INVALID_OPTION_ERR}"     ) echo -e "${LIGHT_RED}[ERRORE] Opzione \"$OPTARG\" non valida.${NC}";;
            "${INVALID_ACCOUNT_ERR}"    ) echo -e "${LIGHT_RED}[ERRORE] Rilevati caratteri non consentiti.\nI caratteri ammessi sono: [a-z][A-Z][0-9].-_${NC}";;
            "${ACCOUNT_NOT_FOUND_ERR}"  ) echo -e "${LIGHT_RED}[ERRORE] Account non trovato${NC}";;
            "${ACCOUNT_NAME_EMPTY_ERR}" ) echo -e "${LIGHT_RED}[ERRORE] Nome account vuoto.${NC}";;
            "${ACCOUNT_EXISTS_ERR}"     ) echo -e "${LIGHT_RED}[ERRORE] Nome account già esistente${NC}";;
            "${INVALID_KEY_ERR}"        ) echo -e "${LIGHT_RED}[ERRORE] Chiave privata nulla o non corretta.\nLa chiave privata deve essere base32.\n${NC}";;
            *                           ) echo -e "${LIGHT_RED}[ERRORE] Errore generico.${NC}";;
        esac

        [[ $2 -eq 1 ]] && exit $2;
    fi
}


# Visualizza messaggi info su stdio
info_msg() {
    echo -e "${LIGHT_GREEN}$1${NC}"
}


continue_msg() {
    case $1 in
        "insert"    ) ACTION="creato";;
        "edit"      ) ACTION="modificato";;
        "delete"    ) ACTION="cancellato";;
    esac

    echo -n "L'account \"${ACCOUNT}\" sta per essere ${ACTION}. Vuoi continuare? [y|N]: "; read ANSWER;
}


continue_yn() {
        ANSWER="0"
        while [[ "${ANSWER}" != "y" ]]; do
            [[ -z "${ANSWER}" || "${ANSWER}" == "N" ]] && { echo "Operazione annullata"; exit; }
            [[ "${ANSWER}" != "y" || "${ANSWER}" != "N" ]] && continue_msg "$1"
        done
}


totp() {
    # Se la'ccount non esiste o è invalido, esco con errore
    get_account "$1"; RET_CODE=$?
    case "${RET_CODE}" in
        "${ACCOUNT_NOT_FOUND_ERR}"  ) err_msg "${ACCOUNT_NOT_FOUND_ERR}" 1;;
        "${INVALID_ACCOUNT_ERR}"    ) err_msg "${INVALID_ACCOUNT_ERR}" 1;;
    esac

    echo -e "\nCopia OTP nella clipboard..."
    # Calcola l'otp e lo trasferisce nella clipboard con xsel
    oathtool --totp -b "${KEY}" | $CLIPBOARD
    info_msg "Fatto."
    exit
}


insert() {
    # Se l'account non esiste o è invalido, esco con errore
    get_account "$1"; RET_CODE=$?
    case "${RET_CODE}" in
        0                           ) err_msg "${ACCOUNT_EXISTS_ERR}" 1;;
        "${INVALID_ACCOUNT_ERR}"    ) err_msg "${INVALID_ACCOUNT_ERR}" 1;;
    esac

    ACCOUNT="$1"

    # Inserisci la chiave
    echo -en "Nuovo account: ${ACCOUNT}\nInserisci la nuova chiave privata: "; read KEY
    while [[ -z "${KEY}" || ! $(echo ${KEY} | oathtool -b - 2>/dev/null) ]]; do
        err_msg "${INVALID_KEY_ERR}" 0
        echo -n "Inserisci la chiave privata: "; read KEY
    done

    info_msg "\nNuovo account:        ${ACCOUNT}\nNuova chiave privata: ${KEY}"
    continue_yn "insert"

    # Appendo il nuovo record nel file degli account
    KEYS_2FA_FILE_DEC+="\n${ACCOUNT}${DELIMITER}${KEY}"
    info_msg "L'account \"${ACCOUNT}\" è stato creato con successo."

    # Cifratura del file degli account
    crypt_account_file "${KEYS_2FA_FILE_DEC}"
    info_msg "Fatto."
    exit
}


edit() {
    # Se la'ccount non esiste o è invalido, esco con errore
    get_account "$1"; RET_CODE=$?
    case "${RET_CODE}" in
        "${ACCOUNT_NOT_FOUND_ERR}"  ) err_msg "${ACCOUNT_NOT_FOUND_ERR}" 1;;
        "${INVALID_ACCOUNT_ERR}"    ) err_msg "${INVALID_ACCOUNT_ERR}" 1;;
    esac

    # Faccio una copia dell'account per un eventuale ripristino durante
    # la fase di input
    ACCOUNT_TEMP="${ACCOUNT}"
    ACCOUNT_MOD="${ACCOUNT}"

    # Inserisco il nuovo nome account.
    # 1. Se è vuoto: è la conferma dell'account inserito all'inizio e proseguo
    # 2. Se il nome è invalido: sollevo un'eccezione e reitero
    # 3. Se il nome è valido:
    #    a. Se è un nome nuovo: acquisisco il nuovo nome, recupero nome e chiave dell'account di partenza e proseguo
    #    b. Sè è lo stesso nome di partenza: è la conferma dell'account iniziale e proseguo
    #    c. Se è un altro nome esistente o invalido: come il punto 2.
    while true; do
        echo
        echo -en "Account: ${ACCOUNT}\nInserisci nuovo nome account: "; read ACCOUNT_MOD;
        get_account "${ACCOUNT_MOD}"; RET_CODE=$?
        case "${RET_CODE}" in
            # Punto 1.
            "${ACCOUNT_NAME_EMPTY_ERR}" ) ACCOUNT_MOD="${ACCOUNT}"; break;;
            # Punto 2
            "${INVALID_ACCOUNT_ERR}"    ) err_msg "${INVALID_ACCOUNT_ERR}" 0;;
            # Punto 3a.
            "${ACCOUNT_NOT_FOUND_ERR}"  ) get_account "${ACCOUNT_TEMP}"; break;;
            # Punti 3b e 3c, rispettivamente
            0                           ) [[ "${ACCOUNT_MOD}" == "${ACCOUNT_TEMP}" ]] && break \
                                                                                 || { get_account "${ACCOUNT_TEMP}"; err_msg "${ACCOUNT_EXISTS_ERR}" 0; };;
        esac
    done

    [[ "${ACCOUNT}" != "${ACCOUNT_MOD}" && ! -z "${ACCOUNT_MOD}" ]] && msg="\nL'account \"${ACCOUNT}\" è stato modificato in \"${ACCOUNT_MOD}\"." \
                                                                    || msg="\nNessuna modifica rilevata.\n"
    info_msg "${msg}"

    # Modifica la chiave privata
    KEY_MOD="${KEY}"
    echo

    while true; do
        echo -en "Chiave privata: ${KEY}\nInserisci la nuova chiave privata: "; read KEY_MOD
        if [[ -z $KEY_MOD ]]; then
            KEY_MOD="${KEY}"; break
        elif [[ ! $(echo "${KEY_MOD}" | oathtool -b - 2>/dev/null) ]]; then
            err_msg "${INVALID_KEY_ERR}" 0; KEY_MOD="${KEY}"
        else
            break
        fi
    done

    # Se c'è stata almeno una modifica (account/key), sovrascrivo il record. Altrimenti esco senza fare nulla.
    if [[ "${ACCOUNT}" != "${ACCOUNT_MOD}" || "${KEY}" != "${KEY_MOD}" ]]; then
        # Conferma modifica

        info_msg "\nAccount:              ${ACCOUNT}\nChiave privata:       ${KEY}\nNuovo account:        ${ACCOUNT_MOD}\nNuova chiave privata: ${KEY_MOD}\n"
        continue_yn "edit"

        # Modifica del file degli account
        KEYS_2FA_FILE_DEC_TEMP=$(sed "s/${ACCOUNT}${DELIMITER}${KEY}/${ACCOUNT_MOD}${DELIMITER}${KEY_MOD}/" <<< "${KEYS_2FA_FILE_DEC}")
        info_msg "L'account \"${ACCOUNT}\" è stato modificato con successo."

        # Cifratura del file degli account
        crypt_account_file "${KEYS_2FA_FILE_DEC_TEMP}"
    else
        info_msg "Nessuna modifica rilevata."
    fi
    info_msg "Fatto."
}


delete() {
    if get_account "$1"; then
        # Conferma eliminazione
        info_msg "\nAccount:              ${ACCOUNT}\nChiave privata:       ${KEY}\n"
        continue_yn "delete"

        # Cancellazione account
        KEYS_2FA_FILE_DEC_TEMP=$(sed "/$ACCOUNT/d" <<< "${KEYS_2FA_FILE_DEC}")
        info_msg "L'account \"$ACCOUNT\" è stato eliminato."

        # Cifratura del nuovo file degli account
        crypt_account_file "${KEYS_2FA_FILE_DEC_TEMP}"
        info_msg "Fatto."
    else
        err_msg "${ACCOUNT_NOT_FOUND_ERR}" 1
    fi
}


list() {
    echo
    while read LINE; do
        cut -d"${DELIMITER}" -f 1 <<< "${LINE}"
    done <<< "${KEYS_2FA_FILE_DEC}"
}


help() {
cat<<EOF
Usa come: ./totp.sh [options] ARG
dove:
    [options]
        -l restituisce la lista degli account.
        -t <nome_account> restituisce l'otp per quell'account.
        -i <nome_account> inserisce un nuovo account.
        -d <nome_account> cancella <nome_account>.
        -e <nome_account> modifica <nome_account>.
        -h stampa questa pagina di help.

ESEMPI:
    RESTITUISCE LA LISTA DEGLI ACCOUNT
    totp.sh -l

    INSERISCE UN ACCOUNT
    totp.sh -i dropbox

    CANCELLA UN ACCOUNT
    totp.sh -d megaupload

    MODIFICA UN ACCOUNT
    totp.sh -e paypal

    GENERA OTP
    totp.sh -t firefoxsync
EOF
}


main() {
    init
    while getopts "lt:i:e:d:" opt; do
        case $opt in
            l ) list ;;
            t ) totp $OPTARG ;;
            i ) insert $OPTARG ;;
            e ) edit $OPTARG ;;
            d ) delete $OPTARG ;;
            * ) clear;err_msg "${INVALID_OPTION_ERR}" 1;;
        esac
    done
    shift $(($OPTIND - 1))
}

[[ $# -eq 0 || $# -eq 1 && "$1" == "-h" ]] && no_param || main $*

#bash #totp #cryptography #gpg #scripting

]]> https://noblogo.org/aytin/gestione-totp-in-bash Wed, 21 Feb 2024 15:37:02 +0000 Come creare un certificato digitale https://noblogo.org/aytin/come-creare-un-certificato-digitale <![CDATA[(pubblicato il 30 gennaio 2023) certificati digitali smalliFonte: Foto di a href="https://pixabay.com/it/users/skylarvision-2957633/?utmsource=link-attribution&utmmedium=referral&utmcampaign=image&utmcontent=3344700"skylarvision/a da a href="https://pixabay.com/it//?utmsource=link-attribution&utmmedium=referral&utmcampaign=image&utmcontent=3344700"Pixabay/a/i/small A volte, per ragioni di test o per uso domestico (configurazione di una vpn con openvpn per es. o di un server stunnel), mi càpita di avere bisogno di un certificato digitale. Finché il certificato è self-signed, l'operazione richiede veramente pochissimo sforzo. Ma quando devo far riferimento ad una CA interna, la questione si complica. !--more-- Proverò adesso a descrivere le operazioni che compio quando devo creare: CA + certificati server + certificati client CA + Intermediate CA + certificati server + certificati client Indice a href="#cose-un-certificato-digitale"Cos’è un certificato digitale/a a href="#openssl"OpenSSL/a a href="#struttura-laboratorio"Struttura del “laboratorio”/a a href="#creazione-ca-certificati-client-server"Caso 1: Creazione delle CA e dei certificati client e server/a a href="#creazione-ca-certificati-server"Creazione della CA per i certificati server/a a href="#configurazione-ca-server"Configurazione CA server/a a href="#creazione-ca-server"Creazione CA server/a a href="#creazione-certificato-server"Creazione del certificato server/a a href="#configurazione-csr-server"Configurazione csr server/a a href="#creazione-csr-server"Creazione csr server/a a href="#configurazione-crt-server"Configurazione crt server/a a href="#creazione-crt-server"Creazione crt server/a a href="#creazione-ca-certificati-client"Creazione della CA per i certificati client/a a href="#configurazione-ca-client"Configurazione CA client/a a href="#creazione-ca-client"Creazione CA client/a a href="#creazione-certificato-client"Creazione del certificato client/a a href="#configurazione-csr-client"Configurazione csr client/a a href="#creazione-csr-client"Creazione csr client/a a href="#configurazione-crt-client"Configurazione crt client/a a href="#creazione-crt-client"Creazione crt client/a a href="#riassunto"Riassunto/a a href="#creazione-ca-intermediate-certificati-client-server"Caso 2: Creazione di CA, Intermediate CA e dei certificati client e server/a a id="cose-un-certificato-digitale"Cos'è un certificato digitale/a I certificati digitali sono degli oggetti utilizzati nelle comunicazioni per fornire un canale sicuro su un mezzo intrinsecamente insicuro (internet) e vengono costruiti secondo lo standard X.509, un protocollo che definisce il formato dei certificati e l'insieme degli elementi di contorno come elementi autoritativi, elenchi di revoca e modalità di convalida. Un certificato digitale è un oggetto crittografico costituito da una parte pubblica (chiave pubblica + informazioni personali del possessore del certificato) e una parte privata (la chiave privata). La parte pubblica viene firmata digitalmente per garantire autenticazione e integrità e può essere eseguita: da se stesso (i cosiddetti certificati self-signed, una sorta di autocertificazione) da una CA, un'autorità superiore che garantisce che le informazioni del certificato sono di chi dice di essere. a id="openssl"OpenSSL/a Per la costruzione di un certificato digitale, uso OpenSSL che è sia una libreria crittografica che implementa i protocolli TLS e SSL (deprecato), sia un toolkit professionale per l'utilizzo di funzionalità di crittografia., OpenSSL ha una cli molto complessa che può essere in parte configurata, soprattutto nella parte di definizione dei certificati, da un file di configurazione, openssl.cnf, un file .ini diviso in sezioni, contenenti una lista di coppie (chiave,valore). Nel proseguio, invece che usare un unico file omnicomprensivo, ne verrà usato solo un frammento in base al contesto (certificato o csr di ca, intermediate, server o client). Ho trovato questo approccio più flessibile e più chiaro. Negli esempi, userò questi file che avranno dei nomi "parlanti" in base a ciò che dovrò definire. Non mi dilungherò nella spiegazione delle singole opzioni perché: non le conosco tutte approfondire ogni singola direttiva di openssl.cnf richiederebbe un blog dedicato. Si potrebbe ancora dissertare sulle versioni di openssl da usare, sui suoi fork ma non è questo il momento, forse in altri post (che sono in fase di preparazione.) a id="struttura-laboratorio"Struttura del "laboratorio"/a Data la destinazione dei certificati (test o uso strettamente interno), i certificati vengono generati nella maniera più compatta possibile. Per le root CA, gli unici certificati self-signed, viene generato il csr e il crt in un'unica soluzione. Le intermediate CA vengono generate, come ogni altro certificato server / client, producendo prima un csr che viene firmato dalla root CA per produrre il crt. Anche i certificati server e client, come detto, vengono generati come l'intermediate CA, producendo prima il csr che verrà firmato da una CA. Ogni fase (per "fase" intendo produzione di un csr o di un crt) sarà "guidata" dal frammento di file di configurazione avente quel famoso nome "parlante". Prenderò in considerazione due casistiche. In una i certificati server e client verranno validati da una root CA. Nell'altro, la root CA delegherà ad una intermediate CA la validazione di certificati server / client. Nella prima casistica, per rendere la soluzione più generica, supporrò di avere una CA distinta per i certificati client e una per i server. ⚠️ ⚠️ ⚠️ SUPER WARNING⚠️ ⚠️ ⚠️ Non è questo il modo formalmente corretto per la creazione di un certificato, almeno non quello da usare per un ambiente di produzione. Non farò nessuna assunzione sulle modalità di cifratura, né sul tuning di openssl. Il mio obiettivo qui è: voglio ottenere un certificato nella maniera più rapida possibile (e per rapido intendo senza troppi sbattimenti nelle configurazioni perché, alla fine, tutto può essere scriptabile e quindi veloce). I file di configurazione saranno composti da massimo due sezioni contenenti le extensions X.509 necessarie per la creazione dei certificati. Il resto dei parametri sarà passato nella cli piuttosto che nel file di configurazione. Mi rendo conto che per una buona comprensione occorrerebbe avere un po' di confidenza con: i concetti di cifratura asimmetrica e di certificato digitale configurazione e utilizzo base di openssl conoscenza di openssl.cnf e extensions X.509 a id="creazione-ca-certificati-client-server"Caso 1: Creazione delle CA e dei certificati client e server/a La creazione della CA consisterà in un certificato self-signed ottenuto con un unico comando. Per i certificati invece verrà prodotto prima il csr che poi sarà firmato dalla CA al fine di ottenere il certificato vero e proprio. Piccola nota: gli attributi basicConstraints, nsCertType, extendedKeyUsage saranno determinanti per battezzare una CA piuttosto che un certificato client/server a id="creazione-ca-certificati-server"Creazione della CA per i certificati server/a La creazione del certificato sarà one-shot. a id="configurazione-ca-server"Configurazione CA server/a Il file di configurazione sarà cacert.cnf ############### cacert.cnf ############### [ v3ca ] basicConstraints = critical,CA:true keyUsage = critical, cRLSign, keyCertSign subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer nsCertType = sslCA nsComment = "OpenSSL Generated CA Root Certificate" a id="creazione-ca-server"Creazione CA server/a OUTPUTCERT=pathoutputcert CONFCERT=pathfilecnf CA SERVER openssl req \ -config $CONFCERT/cacert.cnf \ -extensions v3ca \ -x509 \ -days 1825 -sha512 \ -nodes -newkey rsa:4096 \ -subj "/C=IT/ST=Italia/CN=GlobalSign Test RootCA" \ -keyout $OUTPUTCERT/caserver.key \ -out $OUTPUTCERT/caserver.crt openssl req : crea un csr -config $CONFCERT/cacert.cnf : path del file di configurazione -extensions v3ca : sezione del file da prendere come riferimento (in questo caso per le sole extensions X.509) -x509 : fa in modo che l'output sia direttamente un certificato piuttosto che un csr -days 1825 -sha512 : fissa la scadenza a 5 anni e setta sha512 come algoritmo di digest. -nodes -newkey rsa:4096 : crea una chiave rsa non cifrata a 4096 bit -subj "/C=IT/ST=Roma"/CN=GlobalSign Test RootCA" : distinguishedname passato da cli -keyout $OUTPUTCERT/caserver.key : path di destinazione della chiave -out $OUTPUTCERT/caserver.crt : path di destinazione del certificato CA. a id="creazione-certificato-server"Creazione certificato server/a Verrà generato prima il csr (certificate signing request) che sarà firmato dalla CA per generare il certificato effettivo. a id="configurazione-csr-server"Configurazione csr server/a Il file di configurazione per il csr sarà serverreq.cnf, diviso in 3 sezioni. La prima, req, è quella usata da openssl req (in assenza della quale verrà sollevata un'eccezione) e contiene solo il rimando alle extensions X.509 da usare. Come prima, le extensions X.509 (v3serverreq) definiscono i giusti attributi per questo tipo di certificato. N.B. L'ultima sezione è quella degli alternativesname, la cui assenza non comporta problemi nella creazione del certificato ma potrebbe far fallire i check effettuati da alcuni prodotti, ad es. i webserver che pur riconoscendo nel Common Name il nome del servizio (es. la url) scatenano ugualmente l'eccezione BADCERTDOMAIN ################## serverreq.cnf ################## [ req ] reqextensions = v3serverreq [ v3serverreq ] basicConstraints = CA:FALSE subjectKeyIdentifier = hash keyUsage = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment extendedKeyUsage = serverAuth nsCertType = server nsComment = "OpenSSL Generated Server Request Certificate" subjectAltName = @altnames [ altnames ] DNS.1 = server.web.local a id="creazione-csr-server"Creazione csr server/a La sintassi è sostanzialmente uguale a quanto visto per la CA con la sola eccezione del parametro -x509 (che creava un crt invece che un csr). Il csr creerà il certificato e la coppia di chiavi pubblica e privata. OUTPUTCERT=pathoutputcert CONFCERT=pathfilecnf CSR Server openssl req \ -config $CONFCERT/serverreq.cnf \ -nodes -newkey rsa:2048 \ -subj "/C=IT/ST=Italia/L=Roma/O=My Company Ltd/OU=Divisione IT web/CN=server.web.local/emailAddress=it@web.local" \ -keyout $OUTPUTCERT/server.key \ -out $OUTPUTCERT/server.csr openssl req : crea un csr -config $CONFCERT/serverreq.cnf : path del file di configurazione -nodes -newkey rsa:2048 : crea una chiave rsa non cifrata a 2048 bit -subj "/C=IT/ST=Italia/L=Roma/O=My Company Ltd/OU=Divisione IT web/CN=server.web.local/emailAddress=it@web.local" : distinguishedname passato da cli -keyout $OUTPUTCERT/server.key : path di destinazione della chiave -out $OUTPUTCERT/server.csr : path di destinazione del csr a id="configurazione-crt-server"Configurazione crt server/a A differenza di prima, non ho un file di configurazioni vero e proprio. Non usando il file generico openssl.cnf, l'unico file che si può invocare dal comando openssl x509 è un elenco di attributi che il certificato dovrà possedere e questo ci è sufficiente per creare certificati client o server. Il file di configurazione per il crt sarà servercert.cnf. ################### servercert.cnf ################### basicConstraints = CA:FALSE subjectKeyIdentifier = hash keyUsage = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment extendedKeyUsage = serverAuth nsCertType = server nsComment = "OpenSSL Generated Server Certificate" subjectAltName = @altnames [ altnames ] DNS.1 = server.web.local a id="creazione-crt-server"Creazione crt server/a Di fatto, le uniche operazione che compio sono quelle di firmare con la CA il certificato, di fissare una scadenza e l'algoritmo di digest (altrimenti verrà applicato un default). Il resto, lo eredito dal csr (potrei sovrascrivere alcune cose come il subj) o dalle estensioni presenti nel file. OUTPUTCERT=pathoutputcert CONFCERT=pathfilecnf CRT Server openssl x509 \ -extfile $CONFCERT/servercert.cnf \ -req -in $OUTPUTCERT/server.csr \ -days 365 -sha384 \ -CA $OUTPUTCERT/caserver.crt \ -CAkey $OUTPUTCERT/caserver.key \ -CAcreateserial \ -out $OUTPUTCERT/server.crt openssl x509 : crea un certificato x509 -extfile $CONFCERT/servercert.cnf : path del file di estensioni -req : acquisizione del file csr da far firmare -CA $OUTPUTCERT/caserver.crt : acquisizione del certificato della CA -CAkey $OUTPUTCERT/caserver.key : acquisizione della chiave privata della CA che firmerà il certificato -CAcreateserial : crea un seriale randomico per il certificato da creare. Normalmente una CA crea dei seriali progressivi memorizzandoli in un database interno. -days 365 -sha384 : fissa ad un anno la scadenza del certificato e usa sha384 come algoritmo di digest -out $OUTPUTCERT/server.crt : path di destinazione del certificato server. a id="creazione-ca-certificati-client"Creazione della CA per i certificati client/a È praticamente la stessa cosa. La differenza è solo formale visto che, tecnicamente, i comandi che andrò ad eseguire saranno praticamente gli stessi (l'unica differenza di rilievo riguarderà i certificati client a cui corrisponderanno estensioni X.509 leggermente differenti) a id="configurazione-ca-client"Configurazione della CA client/a È lo stesso file visto a href="#configurazione-ca-server"prima/a. a id="creazione-ca-client"Creazione della CA client/a OUTPUTCERT=pathoutputcert CONFCERT=pathfilecnf CA Client openssl req \ -config $CONFCERT/cacert.cnf \ -extensions v3ca \ -x509 \ -days 1825 -sha512 \ -nodes -newkey rsa:4096 \ -subj "/C=IT/ST=Italia/CN=Digicert Test RootCA" \ -keyout $OUTPUTCERT/caclient.key \ -out $OUTPUTCERT/caclient.crt C'è poco da dire. L'unica variazione degna di nota è il subj, per il resto è identico alla a href="#creazione-ca-server"creazione della ca server/a. a id="creazione-certificato-client"Creazione certificato client/a Come fatto per il server, verrà generato prima il csr che sarà firmato dalla CA per generare il certificato effettivo. a id="configurazione-csr-client"Configurazione csr client/a Come per i a href="#configurazione-csr-server"certificati server/a, extendedKeyUsage e nsCertType stabiliscono come viene battezzato il certificato. ################## clientreq.cnf ################## [ req ] reqextensions = v3clientreq [ v3clientreq ] basicConstraints = CA:FALSE subjectKeyIdentifier = hash keyUsage = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment extendedKeyUsage = clientAuth nsCertType = client nsComment = "OpenSSL Generated Client Request Certificate" a id="creazione-csr-client"Creazione csr client/a Nel csr, viene creata la chiave, rsa a 2048 bit, e viene settato il subj. OUTPUTCERT=pathoutputcert CONFCERT=pathfilecnf CSR Client openssl req \ -config $CONFCERT/clientreq.cnf \ -nodes -newkey rsa:2048 \ -subj "/C=IT/ST=Italia/L=Roma/O=Another Company Ltd/OU=User WebApp/CN=John Doe/emailAddress=john.doe@unknown.local" \ -keyout $OUTPUTCERT/johndoe.key \ -out $OUTPUTCERT/johndoe.csr a id="configurazione-crt-client"Configurazione crt client/a Il file di configurazione raccoglie solo le estensioni con cui il certificato viene istanziato ################### clientcert.cnf ################### basicConstraints = CA:FALSE subjectKeyIdentifier = hash keyUsage = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment extendedKeyUsage = clientAuth nsCertType = client nsComment = "OpenSSL Generated Client Certificate" a id="creazione-crt-client"Creazione crt client/a Come per il certificato server, il certificato client verrà creato in seguito alla firma del csr dalla CA e aver settato scadenza a algoritmo di digest (altrimenti verrà applicato un default). Essendo un certificato client, viene mostrato anche come costruire un p12, utile nei casi in cui l'autenticazione del client viene fatta dal browser. OUTPUTCERT=pathoutputcert CONFCERT=pathfilecnf CRT Client openssl x509 \ -extfile $CONFCERT/clientcert.cnf \ -req -in $OUTPUTCERT/johndoe.csr \ -days 365 -sha384 \ -CA $OUTPUTCERT/caclient.crt \ -CAkey $OUTPUTCERT/caclient.key \ -CAcreateserial \ -out $OUTPUTCERT/johndoe.crt Creazione p12 openssl pkcs12 -export -inkey $OUTPUTCERT/johndoe.key -in $OUTPUTCERT/johndoe.crt -out $OUTPUTCERT/johndoe.p12 a id="riassunto"Riassunto/a Di seguito, la raccolta di quanto visto finora, allo scopo di rendere un colpo d'occhio immediato e di dare una base per rendere scriptabile il processo che già così, tenendo presente i file di configurazione così composti e raccogliendo in uno script i comandi proposti, crea 2 CA, un certificato server e uno client (a meno dei subj di fantasia) File di configurazione: ############### cacert.cnf ############### [ v3ca ] basicConstraints = critical,CA:true keyUsage = critical, cRLSign, keyCertSign subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer nsCertType = sslCA nsComment = "OpenSSL Generated CA Root Certificate" ################## serverreq.cnf ################## [ req ] reqextensions = v3serverreq   [ v3serverreq ] basicConstraints = CA:FALSE subjectKeyIdentifier = hash keyUsage = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment extendedKeyUsage = serverAuth nsCertType = server nsComment = "OpenSSL Generated Server Request Certificate" subjectAltName = @altnames [ altnames ] DNS.1 = server.web.local ################### servercert.cnf ################### basicConstraints = CA:FALSE subjectKeyIdentifier = hash keyUsage = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment extendedKeyUsage = serverAuth nsCertType = server nsComment = "OpenSSL Generated Server Certificate" subjectAltName = @altnames   [ altnames ] DNS.1 = server.web.local ################## clientreq.cnf ################## [ req ] reqextensions = v3clientreq   [ v3clientreq ] basicConstraints = CA:FALSE subjectKeyIdentifier = hash keyUsage = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment extendedKeyUsage = clientAuth nsCertType = client nsComment = "OpenSSL Generated Client Request Certificate" ################### clientcert.cnf ################### basicConstraints = CA:FALSE subjectKeyIdentifier = hash keyUsage = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment extendedKeyUsage = clientAuth nsCertType = client nsComment = "OpenSSL Generated Client Certificate" Script di creazione certificati: OUTPUTCERT=pathoutputcert CONFCERT=pathfilecnf ############# CA SERVER ############# openssl req -config $CONFCERT/cacert.cnf -extensions v3ca -x509 -days 1825 -sha512 -nodes -newkey rsa:4096 -subj "/C=IT/ST=Italia/CN=GlobalSign Test RootCA" -keyout $OUTPUTCERT/caserver.key -out $OUTPUTCERT/caserver.crt ########## Server ########## csr openssl req -config $CONFCERT/serverreq.cnf -nodes -newkey rsa:2048 -subj "/C=IT/ST=Italia/L=Roma/O=My Company Ltd/OU=Divisione IT web/CN=server.web.local/emailAddress=it@web.local" -keyout $OUTPUTCERT/server.key -out $OUTPUTCERT/server.csr crt openssl x509 -extfile $CONFCERT/servercert.cnf -req -in $OUTPUTCERT/server.csr -days 365 -sha384 -CA $OUTPUTCERT/caserver.crt -CAkey $OUTPUTCERT/caserver.key -CAcreateserial -out $OUTPUTCERT/server.crt ############# CA Client ############# openssl req -config $CONFCERT/cacert.cnf -extensions v3ca -x509 -days 1825 -sha512 -nodes -newkey rsa:4096 -subj "/C=IT/ST=Italia/CN=Digicert Test RootCA" -keyout $OUTPUTCERT/caclient.key -out $OUTPUTCERT/caclient.crt ########## Client ########## csr openssl req -config $CONFCERT/clientreq.cnf -nodes -newkey rsa:2048 -subj "/C=IT/ST=Italia/L=Roma/O=Another Company Ltd/OU=User WebApp/CN=John Doe/emailAddress=john.doe@unknown.local" -keyout $OUTPUTCERT/johndoe.key -out $OUTPUTCERT/johndoe.csr crt openssl x509 -extfile $CONFCERT/clientcert.cnf -req -in $OUTPUTCERT/johndoe.csr -days 365 -sha384 -CA $OUTPUTCERT/caclient.crt -CAkey $OUTPUTCERT/caclient.key -CAcreateserial -out $OUTPUTCERT/johndoe.crt p12 openssl pkcs12 -export -inkey $OUTPUTCERT/johndoe.key -in $OUTPUTCERT/johndoe.crt -out $OUTPUTCERT/johndoe.p12 a id="creazione-ca-intermediate-certificati-client-server"Caso 2. Creazione di CA, Intermediate CA e dei certificati client e server/a Gli esempi che seguiranno saranno presentati sullo stile del riassunto perché fondamentalmente molto simili al caso 1. Si aggiunge un punto di intermediazione in più dato dal fatto che la CA delega ad una CA "subalterna" l'incarico di verificare le paternità di coloro i quali richiedono certificati. Quindi avremo: una root CA, certificato self-signed un'Intermediate CA, validata dalla root CA (csr + crt firmato dalla root CA) n certificati client/server validati dall'Intermediate CA (csr + crt firmato dall'Intermediate CA) Creazione certificati OUTPUTCERT=$HOME/stunnel/build-cert CONFCERT=$HOME/stunnel/conf.d ########### Root CA ########### openssl req -config $CONFCERT/cacert.cnf -extensions v3ca -x509 -days 1825 -sha512 -nodes -newkey rsa:4096 -subj "/C=IT/ST=Italia/CN=GlobalSign Test RootCA" -keyout $OUTPUTCERT/rootca.key -out $OUTPUTCERT/rootca.crt ################### INTERMEDIATE CA ################### csr openssl req -config $CONFCERT/intermediatereq.cnf -nodes -newkey rsa:2048 -subj "/C=IT/ST=Italia/CN=GlobalSign Test IntermediateCA" -keyout $OUTPUTCERT/intermediate.key -out $OUTPUTCERT/intermediate.csr crt openssl x509 -extfile $CONFCERT/intermediatecert.cnf -req -in $OUTPUTCERT/intermediate.csr -days 365 -sha384 -CA $OUTPUTCERT/rootca.crt -CAkey $OUTPUTCERT/rootca.key -CAcreateserial -out $OUTPUTCERT/intermediate.crt ########## Server ########## csr openssl req -config $CONFCERT/serverreq.cnf -nodes -newkey rsa:2048 -subj "/C=IT/ST=Italia/L=Roma/O=My Company Ltd/OU=Divisione IT web/CN=server.web.local/emailAddress=it@web.local" -keyout $OUTPUTCERT/server.key -out $OUTPUTCERT/server.csr crt openssl x509 -extfile $CONFCERT/servercert.cnf -req -in $OUTPUTCERT/server.csr -CA $OUTPUTCERT/intermediate.crt -CAkey $OUTPUTCERT/intermediate.key -CAcreateserial -days 365 -sha384 -out $OUTPUTCERT/server.crt ########## Client ########## csr openssl req -config $CONFCERT/clientreq.cnf -nodes -newkey rsa:2048 -subj "/C=IT/ST=Italia/L=Roma/O=Another Company Ltd/OU=User WebApp/CN=John Doe/emailAddress=john.doe@unknown.local" -keyout $OUTPUTCERT/johndoe.key -out $OUTPUTCERT/johndoe.csr crt openssl x509 -extfile $CONFCERT/clientcert.cnf -req -in $OUTPUTCERT/johndoe.csr -days 365 -sha384 -CA $OUTPUTCERT/intermediate.crt -CAkey $OUTPUTCERT/intermediate.key -CAcreateserial -out $OUTPUTCERT/johndoe.crt p12 openssl pkcs12 -export -inkey $OUTPUTCERT/johndoe.key -in $OUTPUTCERT/legs.crt -out $OUTPUT_CERT/johndoe.p12 #DigitalCertificate #x509 #csr #openssl #ca #cryptography #AsymmetricEncryption #SymmetricEncryption #DigitalSignature]]> (pubblicato il 30 gennaio 2023) certificati digitali Fonte: Foto di skylarvision da Pixabay

A volte, per ragioni di test o per uso domestico (configurazione di una vpn con openvpn per es. o di un server stunnel), mi càpita di avere bisogno di un certificato digitale.

Finché il certificato è self-signed, l'operazione richiede veramente pochissimo sforzo. Ma quando devo far riferimento ad una CA interna, la questione si complica. Proverò adesso a descrivere le operazioni che compio quando devo creare:

  1. CA + certificati server + certificati client
  2. CA + Intermediate CA + certificati server + certificati client

Indice

  1. Cos’è un certificato digitale
  2. OpenSSL
  3. Struttura del “laboratorio”
  4. Caso 1: Creazione delle CA e dei certificati client e server
    1. Creazione della CA per i certificati server
      1. Configurazione CA server
      2. Creazione CA server
    2. Creazione del certificato server
      1. Configurazione csr server
      2. Creazione csr server
      3. Configurazione crt server
      4. Creazione crt server
    3. Creazione della CA per i certificati client
      1. Configurazione CA client
      2. Creazione CA client
    4. Creazione del certificato client
      1. Configurazione csr client
      2. Creazione csr client
      3. Configurazione crt client
      4. Creazione crt client
    5. Riassunto
  5. Caso 2: Creazione di CA, Intermediate CA e dei certificati client e server

Cos'è un certificato digitale

I certificati digitali sono degli oggetti utilizzati nelle comunicazioni per fornire un canale sicuro su un mezzo intrinsecamente insicuro (internet) e vengono costruiti secondo lo standard X.509, un protocollo che definisce il formato dei certificati e l'insieme degli elementi di contorno come elementi autoritativi, elenchi di revoca e modalità di convalida.

Un certificato digitale è un oggetto crittografico costituito da una parte pubblica (chiave pubblica + informazioni personali del possessore del certificato) e una parte privata (la chiave privata).

La parte pubblica viene firmata digitalmente per garantire autenticazione e integrità e può essere eseguita:

  • da se stesso (i cosiddetti certificati self-signed, una sorta di autocertificazione)
  • da una CA, un'autorità superiore che garantisce che le informazioni del certificato sono di chi dice di essere.

OpenSSL

Per la costruzione di un certificato digitale, uso OpenSSL che è sia una libreria crittografica che implementa i protocolli TLS e SSL (deprecato), sia un toolkit professionale per l'utilizzo di funzionalità di crittografia.,

OpenSSL ha una cli molto complessa che può essere in parte configurata, soprattutto nella parte di definizione dei certificati, da un file di configurazione, openssl.cnf, un file .ini diviso in sezioni, contenenti una lista di coppie (chiave,valore).

Nel proseguio, invece che usare un unico file omnicomprensivo, ne verrà usato solo un frammento in base al contesto (certificato o csr di ca, intermediate, server o client). Ho trovato questo approccio più flessibile e più chiaro.

Negli esempi, userò questi file che avranno dei nomi “parlanti” in base a ciò che dovrò definire. Non mi dilungherò nella spiegazione delle singole opzioni perché:

  1. non le conosco tutte
  2. approfondire ogni singola direttiva di openssl.cnf richiederebbe un blog dedicato.

Si potrebbe ancora dissertare sulle versioni di openssl da usare, sui suoi fork ma non è questo il momento, forse in altri post (che sono in fase di preparazione.)

Struttura del “laboratorio”

Data la destinazione dei certificati (test o uso strettamente interno), i certificati vengono generati nella maniera più compatta possibile.

  • Per le root CA, gli unici certificati self-signed, viene generato il csr e il crt in un'unica soluzione.
  • Le intermediate CA vengono generate, come ogni altro certificato server / client, producendo prima un csr che viene firmato dalla root CA per produrre il crt.
  • Anche i certificati server e client, come detto, vengono generati come l'intermediate CA, producendo prima il csr che verrà firmato da una CA.
  • Ogni fase (per “fase” intendo produzione di un csr o di un crt) sarà “guidata” dal frammento di file di configurazione avente quel famoso nome “parlante”.
  • Prenderò in considerazione due casistiche. In una i certificati server e client verranno validati da una root CA. Nell'altro, la root CA delegherà ad una intermediate CA la validazione di certificati server / client.
  • Nella prima casistica, per rendere la soluzione più generica, supporrò di avere una CA distinta per i certificati client e una per i server.

⚠️ ⚠️ ⚠️ SUPER WARNING⚠️ ⚠️ ⚠️ Non è questo il modo formalmente corretto per la creazione di un certificato, almeno non quello da usare per un ambiente di produzione.

Non farò nessuna assunzione sulle modalità di cifratura, né sul tuning di openssl.

Il mio obiettivo qui è: voglio ottenere un certificato nella maniera più rapida possibile (e per rapido intendo senza troppi sbattimenti nelle configurazioni perché, alla fine, tutto può essere scriptabile e quindi veloce).

I file di configurazione saranno composti da massimo due sezioni contenenti le extensions X.509 necessarie per la creazione dei certificati. Il resto dei parametri sarà passato nella cli piuttosto che nel file di configurazione.

Mi rendo conto che per una buona comprensione occorrerebbe avere un po' di confidenza con:

  • i concetti di cifratura asimmetrica e di certificato digitale
  • configurazione e utilizzo base di openssl
  • conoscenza di openssl.cnf e extensions X.509

Caso 1: Creazione delle CA e dei certificati client e server

La creazione della CA consisterà in un certificato self-signed ottenuto con un unico comando. Per i certificati invece verrà prodotto prima il csr che poi sarà firmato dalla CA al fine di ottenere il certificato vero e proprio.

Piccola nota: gli attributi basicConstraints, nsCertType, extendedKeyUsage saranno determinanti per battezzare una CA piuttosto che un certificato client/server

Creazione della CA per i certificati server

La creazione del certificato sarà one-shot.

Configurazione CA server

Il file di configurazione sarà ca_cert.cnf

###############
# ca_cert.cnf #
###############
[ v3_ca ]
basicConstraints        = critical,CA:true
keyUsage                = critical, cRLSign, keyCertSign
subjectKeyIdentifier    = hash
authorityKeyIdentifier  = keyid:always,issuer
nsCertType              = sslCA
nsComment               = "OpenSSL Generated CA Root Certificate"

Creazione CA server

OUTPUT_CERT=<path_output_cert>
CONF_CERT=<path_file_cnf>

### CA SERVER ###
openssl req \
-config $CONF_CERT/ca_cert.cnf \
-extensions v3_ca \ 
-x509 \
-days 1825 -sha512 \
-nodes -newkey rsa:4096 \
-subj "/C=IT/ST=Italia/CN=GlobalSign Test RootCA" \
-keyout $OUTPUT_CERT/ca_server.key \
-out $OUTPUT_CERT/ca_server.crt
  • openssl req : crea un csr
  • -config $CONFCERT/cacert.cnf : path del file di configurazione
  • -extensions v3_ca : sezione del file da prendere come riferimento (in questo caso per le sole extensions X.509)
  • -x509 : fa in modo che l'output sia direttamente un certificato piuttosto che un csr
  • -days 1825 -sha512 : fissa la scadenza a 5 anni e setta sha512 come algoritmo di digest.
  • -nodes -newkey rsa:4096 : crea una chiave rsa non cifrata a 4096 bit
  • -subj “/C=IT/ST=Roma”/CN=GlobalSign Test RootCA” : distinguished_name passato da cli
  • -keyout $OUTPUTCERT/caserver.key : path di destinazione della chiave
  • -out $OUTPUTCERT/caserver.crt : path di destinazione del certificato CA.

Creazione certificato server

Verrà generato prima il csr (certificate signing request) che sarà firmato dalla CA per generare il certificato effettivo.

Configurazione csr server

Il file di configurazione per il csr sarà server_req.cnf, diviso in 3 sezioni.

La prima, req, è quella usata da openssl req (in assenza della quale verrà sollevata un'eccezione) e contiene solo il rimando alle extensions X.509 da usare.

Come prima, le extensions X.509 (v3serverreq) definiscono i giusti attributi per questo tipo di certificato.

N.B. L'ultima sezione è quella degli alternatives_name, la cui assenza non comporta problemi nella creazione del certificato ma potrebbe far fallire i check effettuati da alcuni prodotti, ad es. i webserver che pur riconoscendo nel Common Name il nome del servizio (es. la url) scatenano ugualmente l'eccezione BADCERTDOMAIN

##################
# server_req.cnf #
##################
[ req ]
req_extensions = v3_server_req

[ v3_server_req ]
basicConstraints        = CA:FALSE
subjectKeyIdentifier    = hash
keyUsage                = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage        = serverAuth
nsCertType              = server
nsComment               = "OpenSSL Generated Server Request Certificate"
subjectAltName          = @alt_names

[ alt_names ]
DNS.1 = server.web.local

Creazione csr server

La sintassi è sostanzialmente uguale a quanto visto per la CA con la sola eccezione del parametro -x509 (che creava un crt invece che un csr). Il csr creerà il certificato e la coppia di chiavi pubblica e privata.

OUTPUT_CERT=<path_output_cert>
CONF_CERT=<path_file_cnf>

### CSR Server ###
openssl req \
-config $CONF_CERT/server_req.cnf \
-nodes -newkey rsa:2048 \
-subj "/C=IT/ST=Italia/L=Roma/O=My Company Ltd/OU=Divisione IT web/CN=server.web.local/emailAddress=it@web.local" \
-keyout $OUTPUT_CERT/server.key \
-out $OUTPUT_CERT/server.csr
  • openssl req : crea un csr
  • -config $CONFCERT/serverreq.cnf : path del file di configurazione
  • -nodes -newkey rsa:2048 : crea una chiave rsa non cifrata a 2048 bit
  • -subj “/C=IT/ST=Italia/L=Roma/O=My Company Ltd/OU=Divisione IT web/CN=server.web.local/emailAddress=it@web.local” : distinguished_name passato da cli
  • -keyout $OUTPUT_CERT/server.key : path di destinazione della chiave
  • -out $OUTPUT_CERT/server.csr : path di destinazione del csr

Configurazione crt server

A differenza di prima, non ho un file di configurazioni vero e proprio. Non usando il file generico openssl.cnf, l'unico file che si può invocare dal comando openssl x509 è un elenco di attributi che il certificato dovrà possedere e questo ci è sufficiente per creare certificati client o server.

Il file di configurazione per il crt sarà server_cert.cnf.

###################
# server_cert.cnf #
###################
basicConstraints        = CA:FALSE
subjectKeyIdentifier    = hash
keyUsage                = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage        = serverAuth
nsCertType              = server
nsComment               = "OpenSSL Generated Server Certificate"
subjectAltName          = @alt_names

[ alt_names ]
DNS.1 = server.web.local

Creazione crt server

Di fatto, le uniche operazione che compio sono quelle di firmare con la CA il certificato, di fissare una scadenza e l'algoritmo di digest (altrimenti verrà applicato un default). Il resto, lo eredito dal csr (potrei sovrascrivere alcune cose come il subj) o dalle estensioni presenti nel file.

OUTPUT_CERT=<path_output_cert>
CONF_CERT=<path_file_cnf>

### CRT Server ###
openssl x509 \
-extfile $CONF_CERT/server_cert.cnf \
-req -in $OUTPUT_CERT/server.csr \
-days 365 -sha384 \
-CA $OUTPUT_CERT/ca_server.crt \
-CAkey $OUTPUT_CERT/ca_server.key \
-CAcreateserial \
-out $OUTPUT_CERT/server.crt
  • openssl x509 : crea un certificato x509
  • -extfile $CONFCERT/servercert.cnf : path del file di estensioni
  • -req : acquisizione del file csr da far firmare
  • -CA $OUTPUTCERT/caserver.crt : acquisizione del certificato della CA
  • -CAkey $OUTPUTCERT/caserver.key : acquisizione della chiave privata della CA che firmerà il certificato
  • -CAcreateserial : crea un seriale randomico per il certificato da creare. Normalmente una CA crea dei seriali progressivi memorizzandoli in un database interno.
  • -days 365 -sha384 : fissa ad un anno la scadenza del certificato e usa sha384 come algoritmo di digest
  • -out $OUTPUT_CERT/server.crt : path di destinazione del certificato server.

Creazione della CA per i certificati client

È praticamente la stessa cosa. La differenza è solo formale visto che, tecnicamente, i comandi che andrò ad eseguire saranno praticamente gli stessi (l'unica differenza di rilievo riguarderà i certificati client a cui corrisponderanno estensioni X.509 leggermente differenti)

Configurazione della CA client

È lo stesso file visto prima.

Creazione della CA client

OUTPUT_CERT=<path_output_cert>
CONF_CERT=<path_file_cnf>

### CA Client ###
openssl req \
-config $CONF_CERT/ca_cert.cnf \
-extensions v3_ca \ 
-x509 \
-days 1825 -sha512 \
-nodes -newkey rsa:4096 \
-subj "/C=IT/ST=Italia/CN=Digicert Test RootCA" \
-keyout $OUTPUT_CERT/ca_client.key \
-out $OUTPUT_CERT/ca_client.crt

C'è poco da dire. L'unica variazione degna di nota è il subj, per il resto è identico alla creazione della ca server.

Creazione certificato client

Come fatto per il server, verrà generato prima il csr che sarà firmato dalla CA per generare il certificato effettivo.

Configurazione csr client

Come per i certificati server, extendedKeyUsage e nsCertType stabiliscono come viene battezzato il certificato.

##################
# client_req.cnf #
##################
[ req ]
req_extensions = v3_client_req

[ v3_client_req ]
basicConstraints        = CA:FALSE
subjectKeyIdentifier    = hash
keyUsage                = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage        = clientAuth
nsCertType              = client
nsComment               = "OpenSSL Generated Client Request Certificate"

Creazione csr client

Nel csr, viene creata la chiave, rsa a 2048 bit, e viene settato il subj.

OUTPUT_CERT=<path_output_cert>
CONF_CERT=<path_file_cnf>

### CSR Client ###
openssl req \
-config $CONF_CERT/client_req.cnf \
-nodes -newkey rsa:2048 \
-subj "/C=IT/ST=Italia/L=Roma/O=Another Company Ltd/OU=User WebApp/CN=John Doe/emailAddress=john.doe@unknown.local" \
-keyout $OUTPUT_CERT/johndoe.key \
-out $OUTPUT_CERT/johndoe.csr

Configurazione crt client

Il file di configurazione raccoglie solo le estensioni con cui il certificato viene istanziato

###################
# client_cert.cnf #
###################
basicConstraints        = CA:FALSE
subjectKeyIdentifier    = hash
keyUsage                = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage        = clientAuth
nsCertType              = client
nsComment               = "OpenSSL Generated Client Certificate"

Creazione crt client

Come per il certificato server, il certificato client verrà creato in seguito alla firma del csr dalla CA e aver settato scadenza a algoritmo di digest (altrimenti verrà applicato un default). Essendo un certificato client, viene mostrato anche come costruire un p12, utile nei casi in cui l'autenticazione del client viene fatta dal browser.

OUTPUT_CERT=<path_output_cert>
CONF_CERT=<path_file_cnf>

### CRT Client ###
openssl x509 \
-extfile $CONF_CERT/client_cert.cnf \
-req -in $OUTPUT_CERT/johndoe.csr \
-days 365 -sha384 \
-CA $OUTPUT_CERT/ca_client.crt \
-CAkey $OUTPUT_CERT/ca_client.key \
-CAcreateserial \
-out $OUTPUT_CERT/johndoe.crt

### Creazione p12 ###
openssl pkcs12 -export -inkey $OUTPUT_CERT/johndoe.key -in $OUTPUT_CERT/johndoe.crt -out $OUTPUT_CERT/johndoe.p12

Riassunto

Di seguito, la raccolta di quanto visto finora, allo scopo di rendere un colpo d'occhio immediato e di dare una base per rendere scriptabile il processo che già così, tenendo presente i file di configurazione così composti e raccogliendo in uno script i comandi proposti, crea 2 CA, un certificato server e uno client (a meno dei subj di fantasia)

File di configurazione:

###############
# ca_cert.cnf #
###############
[ v3_ca ]
basicConstraints        = critical,CA:true
keyUsage                = critical, cRLSign, keyCertSign
subjectKeyIdentifier    = hash
authorityKeyIdentifier  = keyid:always,issuer
nsCertType              = sslCA
nsComment               = "OpenSSL Generated CA Root Certificate"

##################
# server_req.cnf #
##################
[ req ]
req_extensions = v3_server_req
 
[ v3_server_req ]
basicConstraints        = CA:FALSE
subjectKeyIdentifier    = hash
keyUsage                = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage        = serverAuth
nsCertType              = server
nsComment               = "OpenSSL Generated Server Request Certificate"
subjectAltName          = @alt_names

[ alt_names ]
DNS.1 = server.web.local

###################
# server_cert.cnf #
###################
basicConstraints        = CA:FALSE
subjectKeyIdentifier    = hash
keyUsage                = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage        = serverAuth
nsCertType              = server
nsComment               = "OpenSSL Generated Server Certificate"
subjectAltName          = @alt_names
 
[ alt_names ]
DNS.1 = server.web.local

##################
# client_req.cnf #
##################
[ req ]
req_extensions = v3_client_req
 
[ v3_client_req ]
basicConstraints        = CA:FALSE
subjectKeyIdentifier    = hash
keyUsage                = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage        = clientAuth
nsCertType              = client
nsComment               = "OpenSSL Generated Client Request Certificate"

###################
# client_cert.cnf #
###################
basicConstraints        = CA:FALSE
subjectKeyIdentifier    = hash
keyUsage                = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage        = clientAuth
nsCertType              = client
nsComment               = "OpenSSL Generated Client Certificate"

Script di creazione certificati:

OUTPUT_CERT=<path_output_cert>
CONF_CERT=<path_file_cnf>

#############
# CA SERVER #
#############
openssl req -config $CONF_CERT/ca_cert.cnf -extensions v3_ca -x509 -days 1825 -sha512 -nodes -newkey rsa:4096 -subj "/C=IT/ST=Italia/CN=GlobalSign Test RootCA" -keyout $OUTPUT_CERT/ca_server.key -out $OUTPUT_CERT/ca_server.crt

##########
# Server #
##########
# csr
openssl req -config $CONF_CERT/server_req.cnf -nodes -newkey rsa:2048 -subj "/C=IT/ST=Italia/L=Roma/O=My Company Ltd/OU=Divisione IT web/CN=server.web.local/emailAddress=it@web.local" -keyout $OUTPUT_CERT/server.key -out $OUTPUT_CERT/server.csr
# crt
openssl x509 -extfile $CONF_CERT/server_cert.cnf 
-req -in $OUTPUT_CERT/server.csr -days 365 -sha384 -CA $OUTPUT_CERT/ca_server.crt -CAkey $OUTPUT_CERT/ca_server.key -CAcreateserial -out $OUTPUT_CERT/server.crt

#############
# CA Client #
#############
openssl req -config $CONF_CERT/ca_cert.cnf -extensions v3_ca -x509 -days 1825 -sha512 -nodes -newkey rsa:4096 -subj "/C=IT/ST=Italia/CN=Digicert Test RootCA" -keyout $OUTPUT_CERT/ca_client.key -out $OUTPUT_CERT/ca_client.crt

##########
# Client #
##########
# csr
openssl req -config $CONF_CERT/client_req.cnf -nodes -newkey rsa:2048 -subj "/C=IT/ST=Italia/L=Roma/O=Another Company Ltd/OU=User WebApp/CN=John Doe/emailAddress=john.doe@unknown.local" -keyout $OUTPUT_CERT/johndoe.key -out $OUTPUT_CERT/johndoe.csr
# crt 
openssl x509 -extfile $CONF_CERT/client_cert.cnf -req -in $OUTPUT_CERT/johndoe.csr -days 365 -sha384 -CA $OUTPUT_CERT/ca_client.crt -CAkey $OUTPUT_CERT/ca_client.key -CAcreateserial -out $OUTPUT_CERT/johndoe.crt
# p12
openssl pkcs12 -export -inkey $OUTPUT_CERT/johndoe.key -in $OUTPUT_CERT/johndoe.crt -out $OUTPUT_CERT/johndoe.p12

Caso 2. Creazione di CA, Intermediate CA e dei certificati client e server

Gli esempi che seguiranno saranno presentati sullo stile del riassunto perché fondamentalmente molto simili al caso 1. Si aggiunge un punto di intermediazione in più dato dal fatto che la CA delega ad una CA “subalterna” l'incarico di verificare le paternità di coloro i quali richiedono certificati.

Quindi avremo:

  • una root CA, certificato self-signed
  • un'Intermediate CA, validata dalla root CA (csr + crt firmato dalla root CA) n certificati client/server validati dall'Intermediate CA (csr + crt firmato dall'Intermediate CA)

Creazione certificati

OUTPUT_CERT=$HOME/stunnel/build-cert
CONF_CERT=$HOME/stunnel/conf.d

###########
# Root CA #
###########
openssl req -config $CONF_CERT/ca_cert.cnf -extensions v3_ca -x509 -days 1825 -sha512 -nodes -newkey rsa:4096 -subj "/C=IT/ST=Italia/CN=GlobalSign Test RootCA" -keyout $OUTPUT_CERT/rootca.key -out $OUTPUT_CERT/rootca.crt

###################
# INTERMEDIATE CA #
###################
# csr
openssl req -config $CONF_CERT/intermediate_req.cnf -nodes -newkey rsa:2048 -subj "/C=IT/ST=Italia/CN=GlobalSign Test IntermediateCA" -keyout $OUTPUT_CERT/intermediate.key -out $OUTPUT_CERT/intermediate.csr
# crt
openssl x509 -extfile $CONF_CERT/intermediate_cert.cnf -req -in $OUTPUT_CERT/intermediate.csr -days 365 -sha384 -CA $OUTPUT_CERT/rootca.crt -CAkey $OUTPUT_CERT/rootca.key -CAcreateserial -out $OUTPUT_CERT/intermediate.crt

##########
# Server #
##########
# csr
openssl req -config $CONF_CERT/server_req.cnf -nodes -newkey rsa:2048 -subj "/C=IT/ST=Italia/L=Roma/O=My Company Ltd/OU=Divisione IT web/CN=server.web.local/emailAddress=it@web.local" -keyout $OUTPUT_CERT/server.key -out $OUTPUT_CERT/server.csr
# crt
openssl x509 -extfile $CONF_CERT/server_cert.cnf 
-req -in $OUTPUT_CERT/server.csr -CA $OUTPUT_CERT/intermediate.crt -CAkey $OUTPUT_CERT/intermediate.key -CAcreateserial -days 365 -sha384 -out $OUTPUT_CERT/server.crt

##########
# Client #
##########
# csr
openssl req -config $CONF_CERT/client_req.cnf -nodes -newkey rsa:2048 -subj "/C=IT/ST=Italia/L=Roma/O=Another Company Ltd/OU=User WebApp/CN=John Doe/emailAddress=john.doe@unknown.local" -keyout $OUTPUT_CERT/johndoe.key -out $OUTPUT_CERT/johndoe.csr
# crt
openssl x509 -extfile $CONF_CERT/client_cert.cnf -req -in $OUTPUT_CERT/johndoe.csr -days 365 -sha384 -CA $OUTPUT_CERT/intermediate.crt -CAkey $OUTPUT_CERT/intermediate.key -CAcreateserial -out $OUTPUT_CERT/johndoe.crt
# p12
openssl pkcs12 -export -inkey $OUTPUT_CERT/johndoe.key -in $OUTPUT_CERT/legs.crt -out $OUTPUT_CERT/johndoe.p12

#DigitalCertificate #x509 #csr #openssl #ca #cryptography #AsymmetricEncryption #SymmetricEncryption #DigitalSignature

]]> https://noblogo.org/aytin/come-creare-un-certificato-digitale Sun, 05 Mar 2023 21:38:23 +0000 Stunnel: Cos'è e come si configura https://noblogo.org/aytin/stunnel-cose-e-come-si-configura <![CDATA[(pubblicato il 7 gennaio 2023) Stunnel smalliFonte: a href="https://www.stunnel.org"stunnel.org/a/i/small Introduzione Da documentazione, Stunnel agisce come un proxy per aggiungere crittografia TLS a server e/o a client già esistenti. Risulta quindi molto comodo quando si vuole aggiungere, attraverso un tunnel TLS, quella crittografia che manca alle nostre applicazioni per rendere le comunicazioni più sicure. !--more-- Come in ssh, è possibile “tunnellizzare” solo connessioni TCP. Di stunnel esaminerò in particolare la fase di autenticazione attraverso certificato o PSK. Gli scenari possibili, in base alle combinazioni, sono tre: client tls – server in chiaro client in chiaro – server tls client e server in chiaro Nel primo caso, occorre configurare stunnel in server mode, definendo un receiver ssl, a cui il client potrà connettersi. stunel server smalliScenario 1: stunnel server/i/small Nel secondo caso, occorre configurare stunnel in client mode, definendo un sender ssl che il client userà per connettersi al server stunnel client smalliScenario 2: stunnel client/i/small Nel terzo caso, occorre configurare uno stunnel client e uno server stunnel client e server smalliScenario 3: stunnel client e server/i/small Come ulteriore evoluzione per quel che riguarda le tratte in chiaro (e non solo) di client-stunnel client, stunnel client-stunnel server, stunnel server-server, sarebbe buona norma limitarne l’accesso con un firewall. stunnel client e server e firewall smalliStunnel e firewall/i/small Se invece stunnel fosse locale (installato direttamente sul client e/o sul server), la richiesta del client o il listener del servizio, avverrebbero sull’interfaccia di loopback. Altrimenti, in assenza di firewall, sarebbe consigliabile accertare che la rete di collegamento fra i proxy stunnel e i rispettivi client/server, sia almeno di tipo “trusted”. Stunnel consente un certo tuning sulla parte tls, potendo discriminare fra le cipher suites da abilitare, specificare comandi o configurazioni specifiche per openssl. Quando si deve incapsulare una connessione in chiaro in un tunnel ssl bisogna tenere presente gli scenari menzionati prima. Convenzioni Per non perdere generalità, negli esempi che seguiranno, immaginiamo che stunnel non sia locale (anche se spesso lo è). se stunnel in client mode è locale ⇒ accept avverrà sull’interfaccia di loopback, da dove avviene effettivamente la richiesta se stunnel in server mode è locale ⇒ connect avverrà sull’interfaccia di loopback, dove viene erogato effettivamente il servizio Non faremo assunzioni sulla creazione dei certificati. Possono anche essere self-signed. Configurazione stunnel Verranno mostrate le configurazioni relative agli scenari mostrati nel modo più semplice possibile. accept: host e porta che ricevono la richiesta connect: host e porta a cui girare l’accept cert: normalmente conterrebbe il certificato pubblico che stunnel espone per autenticarsi (la parte privata viene specificata con key). Può però anche essere costituito da tutta i certificati della chain fino alla root CA, in formato pem o p12, iniziando dalla chiave privata, proseguendo con la chiave pubblica, fino a tutte le CA della chain. key: chiave privata del certificato client: stabilisce se stunnel funzioni in server mode oppure no Primo scenario Nel primo caso, una configurazione minimale lato server, ha bisogno: host e porta dello stunnel server che riceve il traffico cifrato host e porta del server su cui girare il traffico in chiaro certificato pubblico e chiave privata necessari per la cifratura Stunnel Server: [myService] accept = ipstunnelserver:portsts connect = ipserver:portserver cert = /servercrt.pembr key = /serverkey.pem Secondo scenario Nel secondo caso, una configurazione minimale lato client, ha bisogno: host e porta dello stunnel client da cui partirà la richiesta host e porta del server da cui stunnel client avvierà la sessione tls Stunnel Client: [myService] client = yes accept = ipstunnelclient:portstc connect = ipserver:portserver Terzo Scenario Il terzo caso, è una fusione dei primi due. Sono gli stunnel a gestire il grosso della comunicazione. E nei casi in cui lo stunnel viene installato sulle macchine di servizio, client e server reali usano solo l’interfaccia di loopback. Una configurazione minimale per il client ha bisogno di: host e porta dello stunnel client da cui partirà la richiesta host e porta del server da cui stunnel client avvierà la sessione tls Stunnel Client: [myService] client = yes accept = ipstunnelclient:portstc connect = ipstunnelserver:portserver Una configurazione minimale per il server ha bisogno: host e porta dello stunnel server che riceve il traffico cifrato host e porta del server su cui girare il traffico in chiaro certificato pubblicato e chiave privata necessari per la cifratura Stunnel Server: [myService] accept = ipstunnelserver:portsts connect = ipserver:portserver cert = /servercrt.pem key = /serverkey.pem smallPiccola nota: se client e/o server dovessero supportare chiavi PSK, si potrebbe usare PSK in luogo dei certificati. Ci ritornerò più avanti./small Autenticazione dei client Le impostazioni viste finora, mostrano come incapsulare un traffico in chiaro all’interno di un tunnel tls e si basano sulla sola autenticazione lato server. Per migliorare la configurazione possiamo ricorrere alla mutua autenticazione facendo in modo che anche i client si autentichino. Una mutua autenticazione, con tutte le verifiche del caso, aumenta il grado di sicurezza comunicazione TLS ed è un efficace deterrente contro eventuali attacchi MITM. L’autenticazione sul client si può ottenere sempre con i certificati oppure, più semplicemente, con chiavi PSK. Autenticazione dei client con certificato Ad una configurazione minimale per una mutua autenticazione, lato server, si richiede che i client esibiscano il certificato e i client (che sia stunnel in client mode, un browser o qualunque altra cosa) dovranno essere in grado di esibire i certificati nel momento in cui il server li richiederà. Su stunnel server, alle configurazioni viste in precedenza, si aggiunge requireCert impostato a yes, che richiede ai client l’esibizione di un certificato. Se, durante l’handshake TLS, il client non esibisce un certificato, l’handshake fallisce e la connessione viene rifiutata. Stunnel Server: [myService] … requireCert = yes … È sufficiente questo se i client possono manipolare i propri certificati. Altrimenti, se c’è uno stunnel client che intermedia le richieste dei client effettivi, si deve aggiungere alla sua configurazione la chiave e il certificato del client Stunnel Client: [myService] … cert = /servercrt.pem key = /serverkey.pem … Autenticazione dei client con PSK Per l’autenticazione PSK bisogna disporre della lista di utenti abilitati con relative chiavi esadecimali di almeno 16 bytes (ossia almeno 32 caratteri esadecimali visto che con un byte si rappresentano due esadecimali). La creazione di una chiave esadecimale può essere fatta velocemente con openssl. Supponiamo di creare due utenze per Frodo e Gandalf con chiavi da 20 e 42 bytes. echo -e "frodo:"$(openssl rand -hex 20) frodopsk.txt echo -e "gandalf:"$(openssl rand -hex 42) gandalfpsk.txt Tutte le identità dovranno confluire nel file che, nella configurazione stunnel, sarà indicato da PSKsecrets. Ad es: cat frodopsk.txt gandalfpsk.txt psksecrets.txt … frodo:84196825fab3389624dcc83eb61189e5b21099febrgandalf:5daf128419855993a2d95ba0a337c51b3f373df88e594441f2979eba6461f25676f1f825b0c76df392f2 … E, come detto, nella configurazione dello stunnel server dovrò indicare il file delle identità: Stunnel Server [myServer] accept = ipstunnelserver:portsts connect = ipserver:portserver PSKsecrets = pathidentityfile/psksecrets.txt Se il client supporta PSK, dovrà fornire identità e password. Ad es. facendo un test con openssl: openssl sclient -port porta -pskidentity frodo -psk 84196825fab3389624dcc83eb61189e5b21099fe -tls12 -connect host Altrimenti si configura stunnel client indicando sia l’identità, sia il file individuate da PSKsecrets. Stunnel Client [myClient] client = yes accept = ipstunnelclient:portstc connect = ipstunnelserver:portserver PSKidentity = frodo PSKsecrets = pathidentityfile/psksecrets.txt In alternativa, per non far viaggiare il file delle identità fra tutti i client, possiamo sfruttare a nostro vantaggio il default delle identità. In assenza della direttiva PSKidentity, viene assunta come identità di default la prima riga del file indicato da PSKSecrets. Basta quindi creare un file con la sola identità che mi occorre, ad es. frodopsk.txt frodo:84196825fab3389624dcc83eb61189e5b21099fe e indicare quello in PSKSecrets. La configurazione che segue è equivalente alla precedente. Stunnel Client [myClient] client = yes accept = ipstunnelclient:portstc connect = ipstunnelserver:portserver PSKsecrets = pathidentityfile/frodopsk.txt Ulteriori considerazioni di sicurezza Autenticazione con certificato La richiesta di autenticazione dei client mediante certificato è una buona misura preventiva ma può essere resa migliore. Nelle configurazioni viste finora, stunnel server autorizza l’accesso al servizio solo se il client si presenta con un certificato ma non c’è nulla che vincoli il certificato al servizio. In altre parole, un client in possesso di un qualunque certificato, può accedere alla risorsa. È possibile rafforzare il trusting fra le parti facendo in modo che stunnel autorizzi solo alcuni certificati invece che qualunque. Questo tipo di controllo può essere fatto sia su stunnel sia in client mode che in server mode. verifyChain = yes | no checkEmail = email del certificato checkHost = CN del certificato checkIP = IP del peer che presenta il certificato verifyPeer = yes | no CApath = path CA CAfile = file pem contenente la fullchain del certificato presentato a stunnel verifyChain Impone che si possa verificare la fullchain del certificato presentato. Se uno degli issuer non viene trovato, la connessione fallisce. La fullchain viene indicata attraverso CAfile o CApath. CAfile È il file contenente le CA con cui stunnel valida i certificati che gli vengono presentati. Se stunnel è in server mode, sarà la fullchain relativa ai client. Altrimenti sarà la fullchain relativa al server. CApath È il path in cui si trovano le CA con cui stunnel valida i certificati che gli vengono presentati. Se lo stunnel è in server mode, sarà la fullchain realtiva ai client. Altrimenti sarà la fullchain relativa al server. verifyPeer Se con CAfile e CApath si verifica la fullchain dei certificati presentati a stunnel, con verifyPeer = yes si verifica che questi certificati siano presenti anche nel suo keystore (CAfile o CApath). Permette di “legare” a stunnel i certificati che dovrà validare. checkEmail, checkHost, checkIP Come per verifyPeer, sono direttive che permettono di stringere il legame fra il certificato che viene presentato e stunnel. Verifica che l’email, il CN o l’IP del certificato che viene presentato corrispondano a quelli presenti nella configurazione. In una configurazione lato server posso avere molteplici occorrenze di questi due campi relative ad altrettanti certificati. Il caso in cui ad es. si debbano autenticare n client. Se i certificati sono self-signed, verifyChain perde di significato (coinciderebbe con verifyPeer). La possibilità di generare i certificati attraverso una CA, anche interna, renderebbe il processo più strutturato anche se più complesso (si dovrà trovare un modo per distribuire la CA, se interna). Si tratta di trovare il giusto compromesso fra ampiezza del servizio (quanti utenti coinvolge?) e complessità richiesta. Se si tratta di realizzare un canale sicuro fra due apparati per una comunicazione server-2-server, vanno bene anche i certificati self-signed o un’autenticazione PSK. Altrimenti, soprattutto nel caso in cui l’autenticazione dei client è una fase critica, conviene valutare l’uso di una CA e una validazione il più possibile restrittiva sui client e sul server. Autenticazione PSK A differenza dell’autenticazione con certificato, l’autenticazione con PSK non prevede enhancement di sicurezza ulteriori a meno di specificare opportuni algoritmi di cifratura (cfr. paragrafo successivo). Cifratura Come sempre succede, negli scenari di cifratura asimmetrica orientatia alla connessione, l’autenticazione, per quanto possa essere accurata, costituisce solo uno degli aspetti di cui tenere conto nella fase di messa in sicurezza del servizio. Avere un’autenticazione con certificato generato con tutti i crismi da una CA, è certamente una gran cosa ma mette in sicurezza solo l’aspetto dell’autenticazione, per l’appunto. l transito dei dati è affidato alle suite di cifratura supportati da openssl e, volendo lavorare di fino, bisognerebbe stringere anche su quelli. Altrimenti, paradossalmente, si avrà un’autenticazione robustissima ma con algoritmi colabrodo di cifratura dei dati che, ad attaccanti ben motivati, lascerebbero delle porte spalancate per sferrare attacchi MITM per intercettare direttamente i dati, piuttosto che provare il furto di identità. Ad ogni modo, il default, per ragioni di compatibilità legacy, dei parametri di cifratura (da settare eventualmente su client e sul server) è il seguente: ciphers: HIGH:!aNULL:!SSLv2:!DH:!kDHEPSK ciphersuites: TLSAES256GCMSHA384:TLSAES128GCMSHA256:TLSCHACHA20POLY1305SHA256 dove ciphers raggruppa le suite di cifratura relativi a TLS1.2 in giù e ciphersuites riguarda invece TLS1.3. Configurazione servizio Ulteriori restrizioni possono essere aggiunte a livelllo di sistema: regolando i bit di setuid e setgid se stunnel gira come root delimitando l’esecuzione del processo in una gabbia chroot disabilitando le regonetiation (se supportato dalla versione di openssl in uso) che mitiga in parte attacchi dos di tipo CPU-exhaustion ecc.. Caso reale: tunnelizzare Transmission. Transmission è un client bittorrent che può essere controllato da remoto via rpc attraverso un’interfaccia web o altri client. Transmission, nelle sue varie declinazioni, non incapsula il traffico rpc in una connessione tls. Se si vuole che il dato in transito sia cifrato e che la connessione sia autenticata, si può ricorrere: ad un tunnel ssh; all’intermediazione di un webserver come apache o nginx ; ad uno stunnel server Sugli ultimi due punti si può configurare una mutua autenticazione con certificato (complessa e articolata e, per tanti client, ha un impatto significativo). Scegliamo il 3° caso. Esposizione dell’interfaccia web Scenario: abbiamo una macchina (il nostro serverino di fiducia o un nas) con transmission a bordo, presumibilmente dietro un firewall che natta il suo indirizzo privato (192.168.70.15). Transmission Stunnel smallEsposizione transmission attraverso stunnel server/small Obiettivo: Vogliamo poter raggiungere transmission e vogliamo che i client autentichino la loro connessione prima di accedere al servizio. In base allo scenario, sappiamo che dovremmo configurare un port forwarding dall’AP fino allo stunnel server. Il server transmission rimarrà confinato nella nostra rete locale. Utilizzo di un client esterno Supponiamo di utilizzare diversi client: il browser, transmission-remote-gtk o transmission-remote-gui (transgui), tremotesf (mobile). La prima cosa da fare è configurare un port forwarding sul nostro AP Rulesub1/sub: 9091 ⇒ 192.168.70.10:9091 Dopodichè, configureremo stunnel in server mode davanti a transmission [transmission] accept = 192.168.70.10:9091 connect = 192.168.70.15:9091 cert = path stunnel conf/ssl/server/certs/stunnelcrt.pem key = path stunnel conf/ssl/server/private/stunnelkey.pem requireCert = yes verifyChain = yes verifyPeer = yes CApath = path stunnel conf/ssl/client/certs Alcune note sulla configurazione: devo disporre di un certificato per stunnel devo disporre dei certificati per i client che si connetteranno, le cui fullchain dovranno essere localizzate nel path indicato da CApath A questo punto basta che i web-client puntino all’host pubblico (151.25.77.205) sulla porta 9091 e il gioco è fatto. Per gli altri client come transmission-remote-gtk, transgui o tremotesf, per i quali al massimo posso chiedere di usare TLS (ma non sono riuscito ad usare un’autenticazione lato client), conviene installare stunnel in client mode : [transmission-client] accept = localhost:9091 connect = 151.25.77.205:9091 client = yes cert = path stunnel conf/ssl/client/laptopcrt.pem key = path stunnel conf/ssl/client/laptopkey.pem verifyChain = yes verifyPeer = yes CAPath = path stunnel conf/ssl/server/certs Il client (ad es. sul laptop) si connetterà su localhost:9091 e dovrà disporre anche del certificato del server e della sua fullchain affinchè i check su verifyChain e verifyPeer non falliscano. #ca #DigitalCertificate #AsymmetricEncryption #SymmetricEncryption #cryptography #fullchain #psk #ssh #ssl #stunnel #tls #x509 #openssl]]> (pubblicato il 7 gennaio 2023) Stunnel Fonte: stunnel.org

Introduzione

Da documentazione, Stunnel agisce come un proxy per aggiungere crittografia TLS a server e/o a client già esistenti.

Risulta quindi molto comodo quando si vuole aggiungere, attraverso un tunnel TLS, quella crittografia che manca alle nostre applicazioni per rendere le comunicazioni più sicure. Come in ssh, è possibile “tunnellizzare” solo connessioni TCP.

Di stunnel esaminerò in particolare la fase di autenticazione attraverso certificato o PSK.

Gli scenari possibili, in base alle combinazioni, sono tre:

  • client tls – server in chiaro
  • client in chiaro – server tls
  • client e server in chiaro

Nel primo caso, occorre configurare stunnel in server mode, definendo un receiver ssl, a cui il client potrà connettersi. stunel server Scenario 1: stunnel server

Nel secondo caso, occorre configurare stunnel in client mode, definendo un sender ssl che il client userà per connettersi al server stunnel client Scenario 2: stunnel client

Nel terzo caso, occorre configurare uno stunnel client e uno server stunnel client e server Scenario 3: stunnel client e server

Come ulteriore evoluzione per quel che riguarda le tratte in chiaro (e non solo) di client-stunnel client, stunnel client-stunnel server, stunnel server-server, sarebbe buona norma limitarne l’accesso con un firewall. stunnel client e server e firewall Stunnel e firewall

Se invece stunnel fosse locale (installato direttamente sul client e/o sul server), la richiesta del client o il listener del servizio, avverrebbero sull’interfaccia di loopback. Altrimenti, in assenza di firewall, sarebbe consigliabile accertare che la rete di collegamento fra i proxy stunnel e i rispettivi client/server, sia almeno di tipo “trusted”.

Stunnel consente un certo tuning sulla parte tls, potendo discriminare fra le cipher suites da abilitare, specificare comandi o configurazioni specifiche per openssl. Quando si deve incapsulare una connessione in chiaro in un tunnel ssl bisogna tenere presente gli scenari menzionati prima.

Convenzioni

  • Per non perdere generalità, negli esempi che seguiranno, immaginiamo che stunnel non sia locale (anche se spesso lo è).
    • se stunnel in client mode è locale ⇒ accept avverrà sull’interfaccia di loopback, da dove avviene effettivamente la richiesta
    • se stunnel in server mode è locale ⇒ connect avverrà sull’interfaccia di loopback, dove viene erogato effettivamente il servizio
  • Non faremo assunzioni sulla creazione dei certificati. Possono anche essere self-signed.

Configurazione stunnel

Verranno mostrate le configurazioni relative agli scenari mostrati nel modo più semplice possibile.

  • accept: host e porta che ricevono la richiesta
  • connect: host e porta a cui girare l’accept
  • cert: normalmente conterrebbe il certificato pubblico che stunnel espone per autenticarsi (la parte privata viene specificata con key). Può però anche essere costituito da tutta i certificati della chain fino alla root CA, in formato pem o p12, iniziando dalla chiave privata, proseguendo con la chiave pubblica, fino a tutte le CA della chain.
  • key: chiave privata del certificato
  • client: stabilisce se stunnel funzioni in server mode oppure no

Primo scenario

Nel primo caso, una configurazione minimale lato server, ha bisogno:

  1. host e porta dello stunnel server che riceve il traffico cifrato
  2. host e porta del server su cui girare il traffico in chiaro
  3. certificato pubblico e chiave privata necessari per la cifratura

Stunnel Server:

[myService]
accept = ip_stunnel_server:port_sts
connect = ip_server:port_server
cert = /server_crt.pem<br>
key = /server_key.pem

Secondo scenario

Nel secondo caso, una configurazione minimale lato client, ha bisogno:

  1. host e porta dello stunnel client da cui partirà la richiesta
  2. host e porta del server da cui stunnel client avvierà la sessione tls

Stunnel Client:

[myService]
client = yes
accept = ip_stunnel_client:port_stc
connect = ip_server:port_server

Terzo Scenario

Il terzo caso, è una fusione dei primi due. Sono gli stunnel a gestire il grosso della comunicazione. E nei casi in cui lo stunnel viene installato sulle macchine di servizio, client e server reali usano solo l’interfaccia di loopback.

Una configurazione minimale per il client ha bisogno di:

  1. host e porta dello stunnel client da cui partirà la richiesta
  2. host e porta del server da cui stunnel client avvierà la sessione tls

Stunnel Client:

[myService]
client = yes
accept = ip_stunnel_client:port_stc
connect = ip_stunnel_server:port_server

Una configurazione minimale per il server ha bisogno:

  1. host e porta dello stunnel server che riceve il traffico cifrato
  2. host e porta del server su cui girare il traffico in chiaro certificato pubblicato e chiave privata necessari per la cifratura

Stunnel Server:

[myService]
accept = ip_stunnel_server:port_sts
connect = ip_server:port_server
cert = /server_crt.pem
key = /server_key.pem

Piccola nota: se client e/o server dovessero supportare chiavi PSK, si potrebbe usare PSK in luogo dei certificati. Ci ritornerò più avanti.

Autenticazione dei client

Le impostazioni viste finora, mostrano come incapsulare un traffico in chiaro all’interno di un tunnel tls e si basano sulla sola autenticazione lato server.

Per migliorare la configurazione possiamo ricorrere alla mutua autenticazione facendo in modo che anche i client si autentichino.

Una mutua autenticazione, con tutte le verifiche del caso, aumenta il grado di sicurezza comunicazione TLS ed è un efficace deterrente contro eventuali attacchi MITM. L’autenticazione sul client si può ottenere sempre con i certificati oppure, più semplicemente, con chiavi PSK.

Autenticazione dei client con certificato

Ad una configurazione minimale per una mutua autenticazione, lato server, si richiede che i client esibiscano il certificato e i client (che sia stunnel in client mode, un browser o qualunque altra cosa) dovranno essere in grado di esibire i certificati nel momento in cui il server li richiederà.

Su stunnel server, alle configurazioni viste in precedenza, si aggiunge requireCert impostato a yes, che richiede ai client l’esibizione di un certificato. Se, durante l’handshake TLS, il client non esibisce un certificato, l’handshake fallisce e la connessione viene rifiutata.

Stunnel Server:

[myService]
…
requireCert = yes
…

È sufficiente questo se i client possono manipolare i propri certificati. Altrimenti, se c’è uno stunnel client che intermedia le richieste dei client effettivi, si deve aggiungere alla sua configurazione la chiave e il certificato del client

Stunnel Client:

[myService]
…
cert = /server_crt.pem
key = /server_key.pem
…

Autenticazione dei client con PSK

Per l’autenticazione PSK bisogna disporre della lista di utenti abilitati con relative chiavi esadecimali di almeno 16 bytes (ossia almeno 32 caratteri esadecimali visto che con un byte si rappresentano due esadecimali).

La creazione di una chiave esadecimale può essere fatta velocemente con openssl. Supponiamo di creare due utenze per Frodo e Gandalf con chiavi da 20 e 42 bytes.

echo -e "frodo:"$(openssl rand -hex 20) > frodo_psk.txt
echo -e "gandalf:"$(openssl rand -hex 42) > gandalf_psk.txt

Tutte le identità dovranno confluire nel file che, nella configurazione stunnel, sarà indicato da PSKsecrets. Ad es:

cat frodo_psk.txt gandalf_psk.txt > psksecrets.txt
…
frodo:84196825fab3389624dcc83eb61189e5b21099fe<br>gandalf:5daf128419855993a2d95ba0a337c51b3f373df88e594441f2979eba6461f25676f1f825b0c76df392f2
…

E, come detto, nella configurazione dello stunnel server dovrò indicare il file delle identità:

Stunnel Server

[myServer]
accept = ip_stunnel_server:port_sts
connect = ip_server:port_server
PSKsecrets = <path_identity_file>/psksecrets.txt

Se il client supporta PSK, dovrà fornire identità e password. Ad es. facendo un test con openssl:

openssl s_client -port <porta> -psk_identity frodo -psk 84196825fab3389624dcc83eb61189e5b21099fe -tls1_2 -connect <host>

Altrimenti si configura stunnel client indicando sia l’identità, sia il file individuate da PSKsecrets.

Stunnel Client

[myClient]
client = yes
accept = ip_stunnel_client:port_stc
connect = ip_stunnel_server:port_server
PSKidentity = frodo
PSKsecrets = <path_identity_file>/psksecrets.txt

In alternativa, per non far viaggiare il file delle identità fra tutti i client, possiamo sfruttare a nostro vantaggio il default delle identità.

In assenza della direttiva PSKidentity, viene assunta come identità di default la prima riga del file indicato da PSKSecrets. Basta quindi creare un file con la sola identità che mi occorre, ad es. frodo_psk.txt

frodo:84196825fab3389624dcc83eb61189e5b21099fe

e indicare quello in PSKSecrets. La configurazione che segue è equivalente alla precedente.

Stunnel Client

[myClient]
client = yes
accept = ip_stunnel_client:port_stc
connect = ip_stunnel_server:port_server
PSKsecrets = <path_identity_file>/frodo_psk.txt

Ulteriori considerazioni di sicurezza

Autenticazione con certificato

La richiesta di autenticazione dei client mediante certificato è una buona misura preventiva ma può essere resa migliore.

Nelle configurazioni viste finora, stunnel server autorizza l’accesso al servizio solo se il client si presenta con un certificato ma non c’è nulla che vincoli il certificato al servizio. In altre parole, un client in possesso di un qualunque certificato, può accedere alla risorsa.

È possibile rafforzare il trusting fra le parti facendo in modo che stunnel autorizzi solo alcuni certificati invece che qualunque. Questo tipo di controllo può essere fatto sia su stunnel sia in client mode che in server mode.

  • verifyChain = yes | no
  • checkEmail = email del certificato
  • checkHost = CN del certificato
  • checkIP = IP del peer che presenta il certificato
  • verifyPeer = yes | no
  • CApath = < path CA >
  • CAfile = < file pem contenente la fullchain del certificato presentato a stunnel >

verifyChain Impone che si possa verificare la fullchain del certificato presentato. Se uno degli issuer non viene trovato, la connessione fallisce. La fullchain viene indicata attraverso CAfile o CApath.

CAfile È il file contenente le CA con cui stunnel valida i certificati che gli vengono presentati. Se stunnel è in server mode, sarà la fullchain relativa ai client. Altrimenti sarà la fullchain relativa al server.

CApath È il path in cui si trovano le CA con cui stunnel valida i certificati che gli vengono presentati. Se lo stunnel è in server mode, sarà la fullchain realtiva ai client. Altrimenti sarà la fullchain relativa al server.

verifyPeer Se con CAfile e CApath si verifica la fullchain dei certificati presentati a stunnel, con verifyPeer = yes si verifica che questi certificati siano presenti anche nel suo keystore (CAfile o CApath). Permette di “legare” a stunnel i certificati che dovrà validare.

checkEmail, checkHost, checkIP Come per verifyPeer, sono direttive che permettono di stringere il legame fra il certificato che viene presentato e stunnel. Verifica che l’email, il CN o l’IP del certificato che viene presentato corrispondano a quelli presenti nella configurazione. In una configurazione lato server posso avere molteplici occorrenze di questi due campi relative ad altrettanti certificati. Il caso in cui ad es. si debbano autenticare n client.

Se i certificati sono self-signed, verifyChain perde di significato (coinciderebbe con verifyPeer). La possibilità di generare i certificati attraverso una CA, anche interna, renderebbe il processo più strutturato anche se più complesso (si dovrà trovare un modo per distribuire la CA, se interna). Si tratta di trovare il giusto compromesso fra ampiezza del servizio (quanti utenti coinvolge?) e complessità richiesta.

Se si tratta di realizzare un canale sicuro fra due apparati per una comunicazione server-2-server, vanno bene anche i certificati self-signed o un’autenticazione PSK. Altrimenti, soprattutto nel caso in cui l’autenticazione dei client è una fase critica, conviene valutare l’uso di una CA e una validazione il più possibile restrittiva sui client e sul server.

Autenticazione PSK

A differenza dell’autenticazione con certificato, l’autenticazione con PSK non prevede enhancement di sicurezza ulteriori a meno di specificare opportuni algoritmi di cifratura (cfr. paragrafo successivo).

Cifratura

Come sempre succede, negli scenari di cifratura asimmetrica orientatia alla connessione, l’autenticazione, per quanto possa essere accurata, costituisce solo uno degli aspetti di cui tenere conto nella fase di messa in sicurezza del servizio.

Avere un’autenticazione con certificato generato con tutti i crismi da una CA, è certamente una gran cosa ma mette in sicurezza solo l’aspetto dell’autenticazione, per l’appunto.

l transito dei dati è affidato alle suite di cifratura supportati da openssl e, volendo lavorare di fino, bisognerebbe stringere anche su quelli.

Altrimenti, paradossalmente, si avrà un’autenticazione robustissima ma con algoritmi colabrodo di cifratura dei dati che, ad attaccanti ben motivati, lascerebbero delle porte spalancate per sferrare attacchi MITM per intercettare direttamente i dati, piuttosto che provare il furto di identità.

Ad ogni modo, il default, per ragioni di compatibilità legacy, dei parametri di cifratura (da settare eventualmente su client e sul server) è il seguente:

ciphers: HIGH:!aNULL:!SSLv2:!DH:!kDHEPSK
ciphersuites: TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256

dove ciphers raggruppa le suite di cifratura relativi a TLS1.2 in giù e ciphersuites riguarda invece TLS1.3.

Configurazione servizio

Ulteriori restrizioni possono essere aggiunte a livelllo di sistema:

  1. regolando i bit di setuid e setgid se stunnel gira come root
  2. delimitando l’esecuzione del processo in una gabbia chroot
  3. disabilitando le regonetiation (se supportato dalla versione di openssl in uso) che mitiga in parte attacchi dos di tipo CPU-exhaustion
  4. ecc..

Caso reale: tunnelizzare Transmission.

Transmission è un client bittorrent che può essere controllato da remoto via rpc attraverso un’interfaccia web o altri client.

Transmission, nelle sue varie declinazioni, non incapsula il traffico rpc in una connessione tls.

Se si vuole che il dato in transito sia cifrato e che la connessione sia autenticata, si può ricorrere:

  1. ad un tunnel ssh;
  2. all’intermediazione di un webserver come apache o nginx ;
  3. ad uno stunnel server

Sugli ultimi due punti si può configurare una mutua autenticazione con certificato (complessa e articolata e, per tanti client, ha un impatto significativo). Scegliamo il 3° caso.

Esposizione dell’interfaccia web

Scenario: abbiamo una macchina (il nostro serverino di fiducia o un nas) con transmission a bordo, presumibilmente dietro un firewall che natta il suo indirizzo privato (192.168.70.15).

Transmission Stunnel Esposizione transmission attraverso stunnel server

Obiettivo: Vogliamo poter raggiungere transmission e vogliamo che i client autentichino la loro connessione prima di accedere al servizio. In base allo scenario, sappiamo che dovremmo configurare un port forwarding dall’AP fino allo stunnel server. Il server transmission rimarrà confinato nella nostra rete locale.

Utilizzo di un client esterno

Supponiamo di utilizzare diversi client: il browser, transmission-remote-gtk o transmission-remote-gui (transgui), tremotesf (mobile).

La prima cosa da fare è configurare un port forwarding sul nostro AP

Rule1: 9091 ⇒ 192.168.70.10:9091

Dopodichè, configureremo stunnel in server mode davanti a transmission

[transmission]
accept = 192.168.70.10:9091
connect = 192.168.70.15:9091
cert = <path stunnel conf>/ssl/server/certs/stunnel_crt.pem
key = <path stunnel conf>/ssl/server/private/stunnel_key.pem
requireCert = yes
verifyChain = yes
verifyPeer = yes
CApath = <path stunnel conf>/ssl/client/certs

Alcune note sulla configurazione:

  • devo disporre di un certificato per stunnel
  • devo disporre dei certificati per i client che si connetteranno, le cui fullchain dovranno essere localizzate nel path indicato da CApath

A questo punto basta che i web-client puntino all’host pubblico (151.25.77.205) sulla porta 9091 e il gioco è fatto.

Per gli altri client come transmission-remote-gtk, transgui o tremotesf, per i quali al massimo posso chiedere di usare TLS (ma non sono riuscito ad usare un’autenticazione lato client), conviene installare stunnel in client mode :

[transmission-client]
accept = localhost:9091
connect = 151.25.77.205:9091
client = yes
cert = <path stunnel conf>/ssl/client/laptop_crt.pem
key = <path stunnel conf>/ssl/client/laptop_key.pem
verifyChain = yes
verifyPeer = yes
CAPath = <path stunnel conf>/ssl/server/certs

Il client (ad es. sul laptop) si connetterà su localhost:9091 e dovrà disporre anche del certificato del server e della sua fullchain affinchè i check su verifyChain e verifyPeer non falliscano.

#ca #DigitalCertificate #AsymmetricEncryption #SymmetricEncryption #cryptography #fullchain #psk #ssh #ssl #stunnel #tls #x509 #openssl

]]> https://noblogo.org/aytin/stunnel-cose-e-come-si-configura Sat, 04 Mar 2023 15:16:09 +0000