↓ Skip to main content
u-random
u-random
  1. Concetti/

SSL/TLS

·5 mins
intermedio
Crypto
Alessio Barnini
Author
Alessio Barnini
Table of Contents
SSL/TLS

Cos'e'
#

Protocollo che cifra le connessioni di rete. SSL e' il predecessore deprecato, TLS e' quello attuale. Quando vedi il lucchetto nel browser, e' TLS che lavora.

TL;DR
#

# Tre problemi da risolvere:
  1. Come verifico che il server sia chi dice di essere?    → catena CA
  2. Come mi scambio una chiave senza trasmetterla?         → Diffie-Hellman
  3. Come cifro i dati in modo veloce?                      → AES simmetrico

# Tre algoritmi in gioco (esempio reale da google.com):
  X25519MLKEM768     → scambio chiavi (DH effimero + post-quantum)
  ECDSA              → firma del certificato (verifica identita')
  AES_256_GCM_SHA384 → cifratura dati + integrita'

Versioni storiche
#

SSL 1.0  → 1994, mai rilasciato
SSL 2.0  → 1995, subito bucato
SSL 3.0  → 1996, usato per anni — vulnerabile a POODLE (2015)
TLS 1.0  → 1999
TLS 1.1  → 2006
TLS 1.2  → 2008, ancora in uso
TLS 1.3  → 2018, quello attuale — ECDHE obbligatorio

SSL e' morto nel 2015. Quando dici "certificato SSL" intendi TLS. Il nome e' rimasto nel linguaggio comune — e nel nome openssl.

Il TLS Handshake
#

sequenceDiagram
    participant B as Browser
    participant S as Server

    B->>S: TCP SYN
    S->>B: TCP SYN-ACK
    B->>S: TCP ACK

    B->>S: Client Hello — versioni TLS e algoritmi supportati
    S->>B: Server Hello — algoritmo scelto + certificato
    B->>B: Verifica catena certificato fino a Root CA
    B->>S: Parametro pubblico DH (A = g^a)
    S->>B: Parametro pubblico DH (B = g^b)
    note over B,S: Entrambi derivano la stessa chiave simmetrica
    note over B,S: Nessuno ha mai mandato la chiave sulla rete
    B->>S: Dati cifrati con AES
    S->>B: Risposta cifrata con AES

Lla cifratura inizia sul computer della vittima, prima che il pacchetto esca.

Browser di Ubuntu
      │
      │ 1. TCP handshake con il server (non cifrato)
      │ 2. TLS handshake (negoziazione algoritmi, scambio chiavi)
      │ 3. Derivazione chiave simmetrica — avviene localmente
      │ 4. Dati cifrati con AES
      │
      ▼
[pacchetto già cifrato] ──► Kali (MITM) ──► internet ──► server

Quello che Kali vede con il MITM ARP su traffico HTTPS:

IP 192.168.64.3 > 216.58.x.x: TCP [SYN]
IP 192.168.64.3 > 216.58.x.x: TLSv1.3 Client Hello
IP 216.58.x.x > 192.168.64.3: TLSv1.3 Server Hello, Certificate
IP 192.168.64.3 > 216.58.x.x: [dati cifrati]
IP 216.58.x.x > 192.168.64.3: [dati cifrati]

Vedi che sta avvenendo una comunicazione HTTPS, con quale server, quanto traffico, quando — ma non il contenuto. I dati sono già cifrati quando lasciano il browser.

Questo è esattamente perché HTTPS esiste: proteggere dal MITM di rete.

La catena CA — come si legge in pratica
#

Output reale di openssl s_client -connect google.com:443:

depth=2 C=US, O=Google Trust Services LLC, CN=GTS Root R1   # Root CA
depth=1 C=US, O=Google Trust Services, CN=WR2               # Intermediate CA
depth=0 CN=*.google.com                                      # Certificato del sito

Certificate chain:
  0  s: CN=*.google.com          i: WR2           # sito firmato da Intermediate
  1  s: WR2                      i: GTS Root R1   # Intermediate firmata da Root
  2  s: GTS Root R1              i: GlobalSign     # Root firmata da GlobalSign

Il pattern: l'i (issuer) di ogni livello e' l's (subject) del livello sopra. E' una catena letterale — se un anello e' rotto, la verifica fallisce.

GlobalSign Root CA  (preinstallata nel tuo OS)
  └── GTS Root R1   (Intermediate — firmata da GlobalSign)
        └── WR2     (Intermediate — firmata da Root R1)
              └── *.google.com  (firmata da WR2)

Se il certificato e' scaduto o revocato:

  • Il browser non va in HTTP — blocca la connessione
  • L'utente vede il warning rosso
  • Niente dati in chiaro — niente connessione

Perfect Forward Secrecy
#

La E in ECDHE sta per Ephemeral — effimero.

Sessione 1: chiavi a1, b1 → chiave simmetrica K1 → scartata
Sessione 2: chiavi a2, b2 → chiave simmetrica K2 → scartata
Sessione 3: chiavi a3, b3 → chiave simmetrica K3 → scartata

Come riconosci PFS nell'output di openssl:

New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
# "New" = chiavi generate ora, mai usate prima

# Se vedessi:
Reused, TLSv1.3, ...
# "Reused" = PFS non funziona, chiavi riciclate

TLS 1.3 rende ECDHE obbligatorio — PFS non e' piu' una scelta.

Post-Quantum Cryptography
#

Output reale di google.com:

Negotiated TLS1.3 group: X25519MLKEM768
X25519         → Diffie-Hellman su curva ellittica (protegge oggi)
MLKEM768       → algoritmo post-quantum su reticoli (protegge dal futuro)
X25519MLKEM768 → ibrido: se uno cede, l'altro tiene

Un computer quantistico puo' rompere X25519. MLKEM768 resiste ai computer quantistici. Usandoli insieme il blast radius di una compromissione e' limitato.

Wildcard vs certificato specifico
#

# Wildcard — copre tutti i sottodomini di primo livello
CN=*.google.com
  copre: mail.google.com, maps.google.com, drive.google.com
  NON copre: google.com, sub.mail.google.com

# Certificato specifico
CN=github.com
  copre: solo github.com

Perche' GitHub preferisce certificati separati:

Wildcard compromesso:
  chiave rubata → tutti i sottodomini esposti

Certificati separati:
  chiave rubata → solo quel dominio esposto
  api.github.com, gist.github.com → salvi

Stesso principio dello sviluppo: blast radius minimo.

Confronto TLS vs SSH
#

                    TLS                      SSH
Scambio chiavi      X25519MLKEM768           curve25519-sha256
Firma server        ECDSA / certificato      ed25519 / known_hosts
Fiducia             CA preinstallata nel OS  TOFU — Trust On First Use
Cifratura dati      AES-256-GCM              chacha20-poly1305
PFS                 ECDHE effimero           curve25519 effimero
Auth client         certificato client       password o challenge-response
Replay protection   —                        challenge casuale per firma

Stessa struttura concettuale, implementazione diversa. Il problema da risolvere e' identico: identita' + canale cifrato + PFS.

Certificato vs Chiavi

Certificato → risponde a: "chi sei?" Chiave simmetrica AES → risponde a: "come cifriamo?"

Scenario Reale Blue Team
#

Un certificato in scadenza non e' solo un problema di UX — e' un alert operativo.

# Controlla scadenza di piu' domini
for domain in google.com github.com; do
  echo -n "$domain: "
  echo | openssl s_client -connect $domain:443 2>/dev/null \
    | openssl x509 -noout -enddate
done

Un certificato scaduto su un server interno che non vedi nel browser puo' indicare un servizio abbandonato — superficie di attacco non monitorata.

Warning

Un certificato valido non significa che il sito e' sicuro. Significa solo che la connessione e' cifrata. Un attaccante puo' avere un certificato valido per un sito di phishing.

Tip

New vs Reused nell'output openssl e' il check rapido per verificare se PFS e' attivo su un servizio che stai ispezionando.

Collegato a
#

Related