Seguretat

Lippycat captura i transporta trànsit de xarxa sensible: credencials SIP, fluxos de mitjans RTP, adreces IP internes i dades potencialment regulades. Aquest capítol descriu els controls de seguretat disponibles per protegir aquestes dades durant la transmissió, l’emmagatzematge i als logs. Pressuposa que teniu un desplegament distribuït operatiu, tal com es descriu a la Part III, i que el prepareu per a producció.

TLS per al mode distribuït

Totes les connexions gRPC de l’arquitectura distribuïda —de Hunter a processador, de processador a processador i de TUI a processador— requereixen TLS per defecte. Sense TLS, els paquets capturats viatgen en text pla entre nodes.

Modes de seguretat

Lippycat admet tres modes TLS:

Requisits de certificats segons el tipus de node

Cada tipus de node necessita certificats diferents segons el mode TLS:

Generació de certificats amb OpenSSL

Les versions modernes de Go requereixen noms alternatius del subjecte (SAN) en tots els certificats. Els certificats que només utilitzen el nom comú (CN) es rebutgen. El procediment següent genera una CA, un certificat de servidor per al processador i un certificat de client per als Hunters.

Pas 1: creeu una autoritat de certificació

mkdir -p /etc/lippycat/certs && cd /etc/lippycat/certs

Genereu la clau de la CA i el certificat autosignat:

openssl req -x509 -newkey rsa:4096 -days 3650 -nodes \
  -keyout ca-key.pem -out ca-cert.pem \
  -subj "/C=US/ST=State/L=City/O=YourOrg/CN=Lippycat CA"

Pas 2: genereu el certificat del processador (servidor)

Genereu la clau privada:

openssl genrsa -out server-key.pem 4096

Creeu la sol·licitud de signatura del certificat:

openssl req -new -key server-key.pem -out server-req.pem \
  -subj "/CN=processor.example.com"

Creeu el fitxer d’extensions; els SAN són obligatoris:

cat > server-ext.conf <<EOF
subjectAltName = DNS:processor.example.com,DNS:localhost,IP:127.0.0.1
extendedKeyUsage = serverAuth
EOF

Signeu el certificat amb la CA:

openssl x509 -req -in server-req.pem -days 365 \
  -CA ca-cert.pem -CAkey ca-key.pem -CAcreateserial \
  -out server-cert.pem -extfile server-ext.conf

Substituïu processor.example.com pel nom de host o l’adreça IP que els Hunters utilitzaran per connectar-se. Afegiu diversos SAN si el processador és accessible amb diversos noms:

subjectAltName = DNS:processor.example.com,DNS:processor,IP:10.0.1.100,IP:127.0.0.1

Pas 3: genereu un certificat de Hunter (client)

Per a mTLS, cada Hunter necessita el seu propi certificat:

openssl genrsa -out hunter01-key.pem 4096

openssl req -new -key hunter01-key.pem -out hunter01-req.pem \
  -subj "/CN=hunter-01.example.com"

cat > client-ext.conf <<EOF
extendedKeyUsage = clientAuth
EOF

openssl x509 -req -in hunter01-req.pem -days 365 \
  -CA ca-cert.pem -CAkey ca-key.pem -CAcreateserial \
  -out hunter01-cert.pem -extfile client-ext.conf

Pas 4: establiu els permisos i feu la neteja

chmod 600 *-key.pem

chmod 644 *-cert.pem

rm -f *.conf *-req.pem

Inici dels nodes amb TLS

Un cop disponibles els certificats, inicieu el desplegament distribuït:

Inicieu el processador amb TLS del servidor:

lc process --listen 0.0.0.0:55555 \
  --tls-cert /etc/lippycat/certs/server-cert.pem \
  --tls-key /etc/lippycat/certs/server-key.pem

Inicieu el Hunter i verifiqueu la identitat del processador:

sudo lc hunt voip -i eth0 \
  --processor processor.example.com:55555 \
  --tls-ca /etc/lippycat/certs/ca-cert.pem

Per a producció amb mTLS (descrit a la secció següent), afegiu les opcions d’autenticació del client.

TLS mutu (mTLS)

El TLS del servidor xifra el canal i permet als clients verificar el processador, però qualsevol client pot connectar-s’hi. El TLS mutu afegeix la verificació inversa: el processador verifica la identitat del Hunter mitjançant certificats de client. Aquesta és la configuració recomanada per a producció.

Model de confiança

flowchart TB
    CA["Internal CA<br/>(ca-cert.pem)"]

    CA -->|signs| SC["Server Cert<br/>(processor)"]
    CA -->|signs| HC1["Client Cert<br/>(hunter-01)"]
    CA -->|signs| HC2["Client Cert<br/>(hunter-02)"]
    CA -->|signs| TC["Client Cert<br/>(TUI client)"]

    subgraph Processor
        SC
        CAcopy1["CA cert (for verifying clients)"]
    end

    subgraph Hunters
        HC1
        HC2
        CAcopy2["CA cert (for verifying server)"]
    end

    subgraph "TUI Clients"
        TC
        CAcopy3["CA cert (for verifying server)"]
    end

Tots els certificats estan signats per la mateixa CA. Cada node confia en qualsevol certificat signat per aquesta CA. Per revocar un Hunter, deixeu d’emetre-li certificats i reinicieu el processador: el Hunter revocat ja no pot presentar un certificat de client vàlid.

Activació de mTLS

Inicieu el processador i exigiu certificats de client:

lc process --listen 0.0.0.0:55555 \
  --tls-cert /etc/lippycat/certs/server-cert.pem \
  --tls-key /etc/lippycat/certs/server-key.pem \
  --tls-client-auth \
  --tls-ca /etc/lippycat/certs/ca-cert.pem

Inicieu un Hunter que presenti un certificat de client:

sudo lc hunt voip -i eth0 \
  --processor processor.example.com:55555 \
  --tls-cert /etc/lippycat/certs/hunter01-cert.pem \
  --tls-key /etc/lippycat/certs/hunter01-key.pem \
  --tls-ca /etc/lippycat/certs/ca-cert.pem

Connecteu un client TUI que també presenti un certificat de client:

lc watch remote -P processor.example.com:55555 \
  --tls-cert /etc/lippycat/certs/tui-cert.pem \
  --tls-key /etc/lippycat/certs/tui-key.pem \
  --tls-ca /etc/lippycat/certs/ca-cert.pem

Fitxer de configuració

Per als desplegaments de producció, deseu els paràmetres TLS al fitxer de configuració en lloc de la línia d’ordres. Així, els camins de les claus no apareixen a les llistes de processos ni a l’historial de l’intèrpret d’ordres:

# /etc/lippycat/config.yaml — processor
processor:
  listen_addr: "0.0.0.0:55555"
  tls:
    cert_file: "/etc/lippycat/certs/server-cert.pem"
    key_file: "/etc/lippycat/certs/server-key.pem"
    ca_file: "/etc/lippycat/certs/ca-cert.pem"
    client_auth: true

# /etc/lippycat/config.yaml — hunter
hunter:
  processor_addr: "processor.example.com:55555"
  tls:
    cert_file: "/etc/lippycat/certs/hunter01-cert.pem"
    key_file: "/etc/lippycat/certs/hunter01-key.pem"
    ca_file: "/etc/lippycat/certs/ca-cert.pem"

CA comercials

Si el processador utilitza un certificat d’una CA coneguda (Let’s Encrypt, DigiCert, etc.), els Hunters no necessiten --tls-ca: el magatzem de confiança del sistema ja inclou la CA emissora:

sudo lc hunt voip -i eth0 --processor processor.example.com:55555

Això simplifica el desplegament dels Hunters, però no proporciona autenticació del client. Combineu-ho amb mTLS si necessiteu restringir quins Hunters poden connectar-se.

Cicle de vida dels certificats

Supervisió de la caducitat

Comproveu les dates de validesa dels certificats i configureu-ne la supervisió automatitzada:

Comproveu les dates d’un certificat:

openssl x509 -in /etc/lippycat/certs/server-cert.pem -noout -dates

Verifiqueu que hi hagi SAN, tal com exigeix Go:

openssl x509 -in /etc/lippycat/certs/server-cert.pem -noout -text \
  | grep -A1 "Subject Alternative Name"

Afegiu una tasca cron o una comprovació de supervisió per avisar abans que caduquin els certificats:

# /etc/cron.daily/check-lippycat-certs
#!/bin/bash
CERT="/etc/lippycat/certs/server-cert.pem"
DAYS_LEFT=$(( ($(date -d "$(openssl x509 -in "$CERT" -noout -enddate \
  | cut -d= -f2)" +%s) - $(date +%s)) / 86400 ))

if [ "$DAYS_LEFT" -lt 30 ]; then
    echo "lippycat server certificate expires in $DAYS_LEFT days" | \
      mail -s "Certificate Expiry Warning" ops@example.com
fi

Rotació dels certificats

Per rotar els certificats sense interrompre les connexions:

1. Genereu un certificat nou signat per la mateixa CA.
2. Actualitzeu el fitxer de configuració amb els camins nous.
3. Recarregueu el servei de manera controlada:

Genereu la clau de substitució:

openssl genrsa -out server-key-new.pem 4096

Creeu-ne la sol·licitud de signatura:

openssl req -new -key server-key-new.pem -out server-req-new.pem \
  -subj "/CN=processor.example.com"

Signeu el certificat de substitució:

openssl x509 -req -in server-req-new.pem -days 365 \
  -CA ca-cert.pem -CAkey ca-key.pem -CAcreateserial \
  -out server-cert-new.pem -extfile server-ext.conf

Col·loqueu el certificat nou al seu lloc:

mv server-cert-new.pem server-cert.pem

mv server-key-new.pem server-key.pem

Recarregueu el servei:

systemctl reload lippycat-processor

Verifiqueu el certificat de substitució:

openssl s_client -connect processor:55555 -showcerts </dev/null 2>/dev/null \
  | openssl x509 -noout -dates

Els Hunters es reconnectaran automàticament amb el nou certificat del servidor, sempre que estigui signat per la mateixa CA.

Revocació d’un certificat

Actualment, Lippycat no implementa comprovacions CRL ni OCSP. Per revocar un certificat compromès:

1. Retireu el certificat compromès del node.
2. Reinicieu el processador per desconnectar el Hunter afectat.
3. Genereu un certificat nou per al node de substitució.
4. Si la clau de la CA s’ha compromès, regenereu tota la CA i torneu a emetre tots els certificats.

Mode de producció

Establir la variable d’entorn LIPPYCAT_PRODUCTION bloqueja el funcionament insegur:

export LIPPYCAT_PRODUCTION=true

Amb aquesta variable establerta, qualsevol intent d’utilitzar --insecure es rebutja en iniciar-se:

FATAL: --insecure flag is not allowed in production mode (LIPPYCAT_PRODUCTION=true)

Això evita que els operadors desactivin TLS accidentalment en producció. Establiu-la al fitxer d’unitat systemd de cada node:

# /etc/systemd/system/lippycat-processor.service
[Service]
Environment="LIPPYCAT_PRODUCTION=true"
ExecStart=/usr/local/bin/lc process --listen :55555 --config /etc/lippycat/config.yaml

Sense --insecure i sense certificats TLS, els nodes es neguen a iniciar-se: no hi ha cap retorn silenciós al text pla.

Mode insegur

Per al desenvolupament i les proves locals, --insecure desactiva TLS completament. Totes dues parts de la connexió han d’utilitzar aquesta opció:

lc process --listen :55555 --insecure

sudo lc hunt voip -i eth0 --processor localhost:55555 --insecure

En iniciar-se, es mostra un avís destacat:

═══════════════════════════════════════════════════════════════
  SECURITY WARNING: TLS ENCRYPTION DISABLED
  Packet data will be transmitted in CLEARTEXT
  This mode should ONLY be used in trusted networks
  TLS is enabled by default — remove --insecure for production
═══════════════════════════════════════════════════════════════

Rendiment de TLS

TLS afegeix una sobrecàrrega mínima en maquinari modern amb suport AES-NI:

No hi ha cap motiu de rendiment per desactivar TLS.

Autenticació amb clau d’API

Els processadors i els nodes Tap poden exigir claus d’API per a les API gRPC de gestió i streaming. Aquesta és una capa d’autenticació alternativa per a desplegaments on distribuir certificats de client és poc pràctic, tot i que cal continuar utilitzant TLS per protegir la clau durant la transmissió.

Activeu l’autenticació amb clau d’API amb --api-key-auth i definiu les claus al fitxer de configuració:

security:
  api_keys:
    enabled: true
    keys:
      - name: "ops-tui"
        key: "lc_live_generated_secret"
        role: "viewer"
        description: "Read-only remote TUI access"

Els clients envien la clau com a metadades gRPC amb el nom x-api-key. En mode de producció, lippycat exigeix mTLS o autenticació amb clau d’API quan el TLS mutu no està activat.

Desxifrat del trànsit TLS capturat

Les seccions anteriors descrivien TLS per a les connexions gRPC del mateix lippycat. Aquesta secció tracta un altre cas d’ús: desxifrar el trànsit xifrat amb TLS que lippycat ha capturat: HTTPS, SMTPS, IMAPS i altres protocols encapsulats en TLS que circulen per la xarxa supervisada.

Com funciona

El desxifrat de TLS requereix claus de sessió exportades per l’aplicació client o servidor mitjançant el mecanisme SSLKEYLOGFILE. Aquestes claus es desen en el format NSS Key Log Format, un estàndard de facto admès per Wireshark, navegadors i moltes aplicacions de servidor.

Com que el TLS modern utilitza secret perfecte cap endavant (Diffie-Hellman efímer), les claus s’han de capturar durant l’execució, en la negociació TLS. No és possible desxifrar posteriorment només amb la clau privada del servidor.

Suport de les aplicacions

La majoria d’aplicacions modernes admeten el registre de claus:

Ús de la CLI

Indiqueu a lippycat un fitxer de registre de claus generat per l’aplicació de destinació:

Per a una captura en directe independent:

sudo lc sniff http -i eth0 --tls-keylog /tmp/sslkeys.log

Per a una captura en directe en mode Tap:

sudo lc tap http -i eth0 --tls-keylog /tmp/sslkeys.log

Per injectar claus en temps real mitjançant una canonada amb nom, creeu la canonada:

mkfifo /tmp/sslkeys.pipe

Inicieu Tap amb la canonada:

sudo lc tap http -i eth0 --tls-keylog-pipe /tmp/sslkeys.pipe &

Inicieu l’aplicació de destinació amb la mateixa canonada:

SSLKEYLOGFILE=/tmp/sslkeys.pipe ./myserver

Transmissió distribuïda de claus

En mode distribuït, els Hunters transmeten automàticament les claus de sessió TLS al processador juntament amb els paquets capturats:

flowchart LR
    subgraph Hunter
        HK["--tls-keylog /tmp/keys.log"]
    end

    subgraph Processor
        PW["Writes paired files:<br/>session.pcap + session.keys"]
    end

    Hunter -->|"gRPC (TLS-encrypted)<br/>packets + session keys"| Processor

Feu la captura amb el registre de claus al Hunter:

sudo lc hunt http -i eth0 \
  --processor central:55555 \
  --tls-keylog /tmp/sslkeys.log \
  --tls-ca ca.crt

Al processador, deseu les claus juntament amb els PCAP:

lc process --listen :55555 \
  --tls-keylog-dir /var/capture/keys \
  --tls-cert server.crt --tls-key server.key

Anàlisi fora de línia

Torneu a analitzar les captures desades amb el registre de claus associat:

Per a l’anàlisi amb la CLI:

lc sniff http -r /var/capture/session.pcap --tls-keylog /var/capture/keys/session.keys

Per a l’anàlisi amb la TUI:

lc watch file /var/capture/session.pcap --tls-keylog /var/capture/keys/session.keys

Integració amb Wireshark

Els fitxers de registre de claus de Lippycat són plenament compatibles amb Wireshark:

1. Obriu el fitxer PCAP a Wireshark.
2. Aneu a Edit > Preferences > Protocols > TLS.
3. Establiu (Pre)-Master-Secret log filename al fitxer de registre de claus.
4. Feu clic a Apply: ara el contingut desxifrat és visible.

Per a captures distribuïdes, el processador escriu fitxers associats que podeu passar directament a Wireshark:

/var/capture/session.pcap        # Encrypted traffic
/var/capture/keys/session.keys   # Session keys

Limitacions

• Cal un registre de claus: el secret perfecte cap endavant impedeix desxifrar sense claus de sessió.
• No es pot desxifrar només amb una clau privada: l’intercanvi de claus RSA (no efímer) és rar i obsolet.
• El moment és important: les claus han d’arribar abans o poc després de la negociació TLS.
• Accés a la mateixa màquina: el node que captura ha de poder llegir el fitxer de registre de claus.

Protecció dels fitxers de registre de claus

Els fitxers de registre de claus contenen secrets de sessió que poden desxifrar tot el trànsit capturat associat. Tracteu-los amb la mateixa cura que les claus privades:

chmod 600 /var/capture/keys/*.keys

chown lippycat:lippycat /var/capture/keys/

En mode distribuït, les claus estan protegides durant la transmissió pel canal TLS gRPC entre Hunter i processador.

Funcions de protecció de dades

A més del xifrat del transport, lippycat inclou diverses funcions per protegir les dades sensibles emmagatzemades i als logs.

Depuració de Call-ID

Els Call-ID de SIP sovint contenen identificadors d’usuari, noms de domini o tokens de sessió. Escriure’ls als fitxers de log pot provocar vulneracions de privadesa. La depuració de Call-ID utilitza hash SHA-256 per generar identificadors coherents però anonimitzats:

Original:   john.doe@company.com-session-12345
Sanitized:  john.d...a1b2c3d4

La forma depurada és determinista: el mateix Call-ID genera sempre el mateix hash, de manera que encara podeu correlacionar entrades de log entre components.

# /etc/lippycat/config.yaml
voip:
  security:
    sanitize_call_ids: true
    call_id_hash_length: 8       # Hash prefix length (4-16 bytes)
    call_id_max_log_length: 16   # Call-IDs longer than this are sanitized

Activeu-ho en tots els entorns. L’impacte en el rendiment és negligible (<1 microsegon per Call-ID).

Xifrat de PCAP

Els fitxers PCAP contenen totes les dades útils dels paquets: credencials SIP, mitjans RTP i dades d’autenticació. Lippycat pot xifrar els fitxers PCAP emmagatzemats amb AES-256-GCM i derivació de claus PBKDF2.

voip:
  security:
    enable_pcap_encryption: true
  encryption:
    enabled: true
    key_file: "/etc/lippycat/keys/pcap.key"
    algorithm: "aes-256-gcm"
    pbkdf2_iterations: 100000     # Minimum 10,000; 100,000+ recommended

Si el fitxer de clau no existeix, lippycat el genera automàticament amb permisos 0600. Per a producció, genereu i gestioneu la clau manualment:

Genereu una clau de xifrat de 256 bits:

openssl rand -out /etc/lippycat/keys/pcap.key 32

chmod 600 /etc/lippycat/keys/pcap.key

chown lippycat:lippycat /etc/lippycat/keys/pcap.key

Rotació de claus: atureu lippycat, canvieu el nom de la clau antiga i reinicieu-lo. Es genera una clau nova automàticament. Conserveu la clau antiga si necessiteu desxifrar fitxers escrits anteriorment.

Rendiment: AES-256-GCM afegeix aproximadament un 5-10% de sobrecàrrega de CPU i ~1-2% de sobrecàrrega d’emmagatzematge (nonce i etiqueta d’autenticació per bloc). L’acceleració AES-NI de maquinari ho redueix considerablement.

Permisos dels fitxers PCAP

Tots els fitxers PCAP es creen amb permisos 0600 (només el propietari pot llegir i escriure). Això s’aplica als PCAP unificats, als PCAP per trucada i als PCAP amb rotació automàtica. No cal configurar-ho: és el comportament per defecte.

Prepareu el directori de sortida amb restriccions equivalents:

sudo mkdir -p /var/lib/lippycat/pcaps

sudo chmod 700 /var/lib/lippycat/pcaps

sudo chown lippycat:lippycat /var/lib/lippycat/pcaps

Fins i tot amb el xifrat PCAP activat, els permisos dels fitxers proporcionen defensa en profunditat perquè impedeixen l’accés no autoritzat als fitxers xifrats.

Validació dels límits de Content-Length

Els missatges SIP inclouen una capçalera Content-Length. Sense validació, un missatge maliciós o malformat que especifiqui un valor enorme pot esgotar la memòria. Lippycat valida els valors de Content-Length durant l’anàlisi dels missatges TCP SIP amb diverses capes de protecció:

• Longitud de cadena limitada a 10 caràcters (evita el desbordament d’enters durant l’anàlisi)
• Valor màxim configurable (1 MB per defecte)
• Mida màxima total del missatge configurable (2 MB per defecte)

voip:
  security:
    max_content_length: 1048576     # 1 MB — reasonable for production
    max_message_size: 2097152       # 2 MB — reasonable for production

Per als entorns d’alta seguretat, reduïu aquests límits:

voip:
  security:
    max_content_length: 65536       # 64 KB
    max_message_size: 131072        # 128 KB

Les infraccions es registren com a avisos amb el valor causant i la font, de manera que podeu detectar intents d’escaneig o atac.

Seguretat de les interfícies virtuals

Tal com es descriu al Capítol 4, lippycat pot crear interfícies virtuals TAP/TUN per transmetre paquets filtrats a eines posteriors com Wireshark o Snort. Això requereix privilegis elevats.

Configuració amb privilegis mínims

L’enfocament recomanat utilitza les capacitats de fitxer de Linux per concedir només la capacitat CAP_NET_ADMIN:

Concediu la capacitat mínima necessària:

sudo setcap cap_net_admin+ep /usr/local/bin/lc

Verifiqueu la capacitat:

getcap /usr/local/bin/lc

La sortida esperada és /usr/local/bin/lc = cap_net_admin+ep.

Ara el comandament es pot executar sense sudo:

lc sniff voip -i eth0 --virtual-interface

Renúncia als privilegis

Quan és inevitable executar-se com a root, lippycat pot passar a un usuari sense privilegis després de crear la interfície:

sudo lc sniff voip -i eth0 \
  --virtual-interface \
  --vif-drop-privileges lippycat

El procés crea la interfície com a root i després passa a l’UID/GID de l’usuari lippycat. El bucle d’injecció de paquets s’executa sense privilegis.

Aïllament amb espais de noms de xarxa

Per a desplegaments de producció amb requisits de seguretat estrictes, executeu la interfície virtual en un espai de noms de xarxa aïllat:

Creeu l’espai de noms:

sudo ip netns add lippycat-isolated

Executeu amb aïllament de l’espai de noms:

sudo lc sniff voip -i eth0 \
  --virtual-interface \
  --vif-netns lippycat-isolated

Només les eines de l’espai de noms poden veure la interfície:

sudo ip netns exec lippycat-isolated wireshark -i lc0

La interfície és invisible per a la pila de xarxa del host, cosa que impedeix captures no autoritzades.

Desplegament en contenidors

Per a Docker o Kubernetes, concediu CAP_NET_ADMIN sense executar tot el contenidor com a root:

Per a Docker:

docker run --cap-add=NET_ADMIN lippycat:latest

# Kubernetes
securityContext:
  capabilities:
    add:
    - NET_ADMIN
  runAsNonRoot: true
  runAsUser: 1000

Llista de comprovació de seguretat

Abans de posar un desplegament en producció, verifiqueu els punts següents:

Transport:

• TLS activat en totes les connexions gRPC (sense opcions --insecure)
• LIPPYCAT_PRODUCTION=true establert als fitxers d’unitat systemd
• mTLS activat amb --tls-client-auth al processador
• Els certificats inclouen SAN (no només CN)
• Supervisió de la caducitat dels certificats preparada

Dades emmagatzemades:

• Els directoris de sortida PCAP tenen permisos 0700
• Xifrat PCAP activat per als desplegaments sensibles
• Clau de xifrat desada en un sistema de fitxers segur amb permisos 0600
• Fitxers de registre de claus (--tls-keylog) protegits amb permisos 0600

Aplicació:

• Depuració de Call-ID activada a la configuració
• Límits de Content-Length configurats adequadament
• Les interfícies virtuals utilitzen capacitats de fitxer (no root)
• Les claus privades no s’han incorporat al control de versions

Operacions:

• Els fitxers de configuració tenen permisos 0600 (contenen camins de claus)
• Procediment de rotació de certificats documentat i provat
• Accés als fitxers de registre de claus auditat

Notes sobre compliment normatiu

Aquestes funcions de seguretat donen suport als marcs habituals de compliment normatiu:

Resolució de problemes

“certificate relies on legacy Common Name field, use SANs instead”

El certificat es va generar sense noms alternatius del subjecte. Torneu-lo a generar amb una extensió subjectAltName, tal com es mostra a Generació de certificats amb OpenSSL.

Verifiqueu que un certificat existent contingui SAN:

openssl x509 -in server-cert.pem -noout -text | grep -A1 "Subject Alternative Name"

“TLS is disabled but –insecure flag not set”

No s’han proporcionat certificats TLS i no s’ha establert --insecure. Proporcioneu certificats o permeteu explícitament el mode insegur per a les proves.

“No client certificate provided”

El processador exigeix mTLS (--tls-client-auth), però el Hunter no ha presentat cap certificat de client. Afegiu --tls-cert i --tls-key al Hunter.

“Failed to verify certificate”

La validació del certificat ha fallat. Causes habituals:

Comproveu si el certificat ha caducat:

openssl x509 -in cert.pem -noout -enddate

Comproveu si el nom de host coincideix amb els SAN:

openssl x509 -in cert.pem -noout -text | grep -A2 "Subject Alternative Name"

Verifiqueu la cadena de certificats:

openssl verify -CAfile ca-cert.pem server-cert.pem

El desxifrat TLS no funciona

1. Verifiqueu que el fitxer de registre de claus existeixi i contingui entrades.
2. Comproveu que les claus es van capturar durant la negociació TLS (les claus no es poden generar posteriorment).
3. En mode distribuït, confirmeu que el Hunter tingui --tls-keylog establert i que el processador tingui --tls-keylog-dir configurat.
4. Per a Wireshark, assegureu-vos que el format de registre de claus comenci amb CLIENT_RANDOM o CLIENT_HANDSHAKE_TRAFFIC_SECRET.