Passa al contenuto principale

Appendice D. Note di implementazione (Implementation Notes)

Questa appendice fornisce consigli pratici e best practice per l'implementazione di TLS 1.2.

D.1. Generazione e seeding di numeri casuali (Random Number Generation and Seeding)​

La sicurezza di TLS dipende fortemente dalla qualità della generazione di numeri casuali. Le implementazioni DEVONO utilizzare generatori di numeri pseudocasuali crittograficamente sicuri (CSPRNG).

D.1.1. Requisiti per la generazione di numeri casuali​

  • Fonte di entropia: Utilizzare fonti di entropia di qualità crittografica fornite dal sistema operativo (come /dev/urandom sui sistemi Unix)
  • Seeding: Assicurarsi che il PRNG sia correttamente inizializzato prima dell'uso
  • Reseeding: Reinizializzare periodicamente per mantenere il pool di entropia
  • Evitare fonti deboli: Non utilizzare valori prevedibili come timestamp, ID di processo come unica fonte di entropia

D.1.2. Raccomandazioni per l'implementazione​

/* Cattiva pratica - Non fare questo */
srand(time(NULL));
random_value = rand();

/* Buona pratica - Utilizzare il CSPRNG fornito dal sistema */
#ifdef _WIN32
    CryptGenRandom(...);  /* Windows */
#else
    /* Unix/Linux */
    int fd = open("/dev/urandom", O_RDONLY);
    read(fd, random_buffer, length);
    close(fd);
#endif

D.2. Certificati e autenticazione (Certificates and Authentication)​

D.2.1. Verifica del certificato​

Le implementazioni DEVONO verificare correttamente la catena di certificati:

  1. Verifica della catena di certificati:

    • Verificare la firma di ciascun certificato
    • Assicurarsi che la catena di certificati raggiunga una CA radice attendibile
    • Controllare il periodo di validità dei certificati

  2. Verifica del nome host:

    • Verificare il Common Name (CN) o il Subject Alternative Name (SAN) nel certificato
    • Supportare i certificati wildcard (come *.example.com)

  3. Controllo della revoca:

    • Le implementazioni DOVREBBERO controllare lo stato di revoca del certificato
    • Supportare CRL (Certificate Revocation List) e/o OCSP (Online Certificate Status Protocol)

D.2.2. Selezione del certificato​

I server dovrebbero:

  • Supportare più certificati (RSA, ECDSA, ecc.)
  • Selezionare il certificato migliore in base alle capacità del client
  • Bilanciare prestazioni e sicurezza

D.3. Suite di cifratura (Cipher Suites)​

D.3.1. Selezione della suite di cifratura​

Le implementazioni DOVREBBERO:

  • Abilitare di default suite di cifratura forti
  • Disabilitare suite di cifratura con debolezze note (RC4, DES, cifrari di grado export)
  • Ordinare l'elenco delle suite di cifratura per priorità

D.3.2. Configurazione consigliata​

Ordine di priorità (dal più alto al più basso):

  1. Suite di cifratura AEAD (modalità GCM)
  2. Suite che forniscono forward secrecy (DHE/ECDHE)
  3. AES-256 rispetto ad AES-128
  4. MAC SHA-256 o più forte
  5. Evitare la modalità CBC (se possibile)

Esempio di configurazione:

1. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
2. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
3. TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
4. TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
5. TLS_RSA_WITH_AES_256_CBC_SHA256
6. TLS_RSA_WITH_AES_128_CBC_SHA256

D.4. Trabocchetti di implementazione (Implementation Pitfalls)​

D.4.1. Attacchi temporali​

Problema: Le differenze di temporizzazione nel confronto delle password e nella validazione del padding possono far trapelare informazioni.

Soluzione: Utilizzare il confronto a tempo costante:

/* Confronto non sicuro */
int compare(const unsigned char *a, const unsigned char *b, size_t len) {
    for (size_t i = 0; i < len; i++) {
        if (a[i] != b[i])
            return 0;  /* Uscita anticipata - trapela informazioni temporali */
    }
    return 1;
}

/* Confronto a tempo costante */
int constant_time_compare(const unsigned char *a, const unsigned char *b, 
                         size_t len) {
    unsigned char result = 0;
    for (size_t i = 0; i < len; i++) {
        result |= a[i] ^ b[i];
    }
    return result == 0;
}

D.4.2. Attacchi padding oracle​

Problema: Gli errori di validazione del padding in modalità CBC possono essere sfruttati.

Soluzione:

  • Utilizzare la validazione del padding a tempo costante
  • Restituire lo stesso errore per tutti i fallimenti di decrittazione
  • Considerare l'uso della modalità AEAD (GCM) per evitare questo problema

D.4.3. Attacchi di rollback della versione​

Problema: Gli aggressori possono tentare di forzare l'uso di versioni di protocollo più deboli.

Soluzione:

  • Includere la versione negoziata nel messaggio Finished
  • Verificare la coerenza dei campi di versione
  • Implementare la protezione SCSV (Signaling Cipher Suite Value)

D.4.4. Attacchi di rinegoziazione​

Problema: La rinegoziazione può essere utilizzata per iniettare comandi o eseguire altri attacchi.

Soluzione:

  • Implementare RFC 5746 (Renegotiation Indication Extension)
  • Disabilitare la rinegoziazione durante operazioni sensibili
  • Gestire correttamente i cambiamenti del certificato client

D.4.5. Attacchi di compressione (CRIME)​

Problema: La compressione TLS può far trapelare informazioni segrete.

Soluzione:

  • Disabilitare la compressione a livello TLS
  • Se è necessaria la compressione, implementarla a livello di applicazione
  • Evitare di comprimere dati contenenti segreti

D.4.6. Gestione del buffer​

Problema: Una gestione impropria del buffer può portare a overflow o perdite di informazioni.

Soluzione:

  • Controllare sempre i campi di lunghezza
  • Utilizzare funzioni di memoria sicure (come memcpy_s)
  • Azzerare i dati sensibili dopo la liberazione
/* Cancellare i dati sensibili */
void secure_zero(void *ptr, size_t len) {
    volatile unsigned char *p = ptr;
    while (len--)
        *p++ = 0;
}

/* Cancellare la chiave dopo l'uso */
unsigned char key[32];
/* ... utilizzare la chiave ... */
secure_zero(key, sizeof(key));

D.4.7. Gestione degli errori​

Problema: Messaggi di errore dettagliati possono far trapelare dettagli di implementazione.

Soluzione:

  • Restituire errori generici alle entità esterne
  • Gli errori dettagliati dovrebbero essere registrati solo internamente
  • Evitare di far trapelare informazioni temporali

D.5. Ottimizzazione delle prestazioni​

D.5.1. Ripresa della sessione​

  • Implementare il caching delle sessioni o i ticket di sessione
  • Ridurre il numero di handshake completi
  • Bilanciare sicurezza e prestazioni

D.5.2. Operazioni bulk​

  • Elaborare in batch le operazioni di crittografia/decrittografia
  • Utilizzare l'accelerazione hardware (AES-NI, PCLMULQDQ, ecc.)
  • Considerare l'uso di I/O asincrono

D.5.3. Pool di connessioni​

  • Riutilizzare le connessioni TLS
  • Implementare la gestione del pool di connessioni
  • Impostare valori di timeout ragionevoli

Nota: Per raccomandazioni complete sull'implementazione e spiegazioni dettagliate, si prega di fare riferimento al testo completo dell'appendice D della RFC 5246.

Ultimo aggiornamento il