Tengo problemas con ssldump y wireshark

[WHK]

Hola, estoy haciendo algunas pruebas con ssldump pero no me descifra el contenido original.

Código [Seleccionar] Expandir

# ssldump -k /etc/letsencrypt/live/site/privkey.pem -i eth0 -d -P port 443

Cuando no le doy el puerto 443 me muestra muy bien el contenido via http al puerto 80 pero al 443 que va cifrado no me muestra nada, solamente logs de la negociación del certificado. ¿Qué hice mal?, según la documentación oficial estoy haciendo todo bien.

Le doy la opción -P para que no se ponga en modo promiscuo, solo necesito capturar el tráfico de la red actual no de toda la red y -d para mostrar el contenido de los datos.

La llave del certificado es la misma que está siendo usada en el servidor web

Código [Seleccionar] Expandir

# ll
total 4
lrwxrwxrwx 1 root root 48 abr 28 14:21 cert.pem
lrwxrwxrwx 1 root root 49 abr 28 14:21 chain.pem
lrwxrwxrwx 1 root root 53 abr 28 14:21 fullchain.pem
lrwxrwxrwx 1 root root 51 abr 28 14:21 privkey.pem


[MinusFour]

¿Que mensajes obtienes cuando usas ssl-dump?

[WHK]

Código [Seleccionar] Expandir

[root@xxx ~]# ssldump -k /etc/letsencrypt/live/xxx/privkey.pem -i eth0 -d -P port 443
New TCP connection #1: 199.15.233.162(51212) <-> xxx(443)
1 1  0.0387 (0.0387)  C>S  Handshake
     ClientHello
       Version 3.3
       cipher suites
       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
       TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
       TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
       TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
       TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
       TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
       TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
       TLS_DHE_RSA_WITH_AES_256_CBC_SHA
       TLS_DHE_DSS_WITH_AES_256_CBC_SHA
       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
       TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA
       TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
       TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
       TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
       TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
       TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
       TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
       TLS_RSA_WITH_AES_256_GCM_SHA384
       TLS_RSA_WITH_AES_256_CBC_SHA256
       TLS_RSA_WITH_AES_256_CBC_SHA
       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
       TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
       TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
       TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
       TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
       TLS_DHE_RSA_WITH_AES_128_CBC_SHA
       TLS_DHE_DSS_WITH_AES_128_CBC_SHA
       TLS_DHE_RSA_WITH_SEED_CBC_SHA
       TLS_DHE_DSS_WITH_SEED_CBC_SHA
       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
       TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA
       TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
       TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
       TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
       TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
       TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
       TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
       TLS_RSA_WITH_AES_128_GCM_SHA256
       TLS_RSA_WITH_AES_128_CBC_SHA256
       TLS_RSA_WITH_AES_128_CBC_SHA
       TLS_RSA_WITH_SEED_CBC_SHA
       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
       TLS_RSA_WITH_IDEA_CBC_SHA
       TLS_ECDHE_RSA_WITH_RC4_128_SHA
       TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
       TLS_ECDH_RSA_WITH_RC4_128_SHA
       TLS_ECDH_ECDSA_WITH_RC4_128_SHA
       TLS_RSA_WITH_RC4_128_SHA
       TLS_RSA_WITH_RC4_128_MD5
       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
       TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
       TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
       TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
       TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
       TLS_RSA_WITH_3DES_EDE_CBC_SHA
       TLS_DHE_RSA_WITH_DES_CBC_SHA
       TLS_DHE_DSS_WITH_DES_CBC_SHA
       TLS_RSA_WITH_DES_CBC_SHA
       TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
       TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
       TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
       TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
       TLS_RSA_EXPORT_WITH_RC4_40_MD5
       TLS_EMPTY_RENEGOTIATION_INFO_SCSV
       compression methods
                 NULL
1 2  0.0459 (0.0072)  S>C  Handshake
     ServerHello
       Version 3.3
       session_id[0]=

       cipherSuite         TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
       compressionMethod                   NULL
1 3  0.0459 (0.0000)  S>C  Handshake
     Certificate
1 4  0.0459 (0.0000)  S>C  Handshake
     ServerKeyExchange
Not enough data. Found 327 bytes (expecting 32767)
1 5    0.0459   (0.0000)    S>C    Handshake
       ServerHelloDone
1 6    0.0877   (0.0417)    C>S    Handshake
       ClientKeyExchange
Not enough data. Found 64 bytes (expecting 16384)
1 7    0.0877   (0.0000)    C>S    ChangeCipherSpec
1 8    0.0877   (0.0000)    C>S      Handshake
1 9    0.0885   (0.0007)    S>C    Handshake
1 10   0.0885   (0.0000)    S>C    ChangeCipherSpec
1 11   0.0885   (0.0000)    S>C      Handshake
1 12   0.1272   (0.0387)    C>S      application_data
1 13   0.2662   (0.1390)    S>C      application_data
1 14   0.2663   (0.0000)    S>C      application_data
1 15   0.2663   (0.0000)    S>C      application_data
1 16   0.3049   (0.0385)    S>C      application_data
1 17   0.3049   (0.0000)    S>C      application_data
1 18   0.3050   (0.0001)    S>C      application_data
New TCP connection #2: 181-23-73-114.speedy.com.ar(42350) <-> xxx(443)

De todas maneras no es lo que necesito, lo que yo quiero es poder observar las http request tanto en sus url como en su contenido post, por eso he estado viendo wireshark via terminal (tshark), me ha sido mucho mas util, intuitivo y facil de configurar, el problema es que tampoco me resulta la captura en ssl (aunque por lo menos ya tengo un log de errores al que puedo darle un vistazo).

He intentado esto:

tshark -i eth0 -f 'tcp port 443' -Y 'http.request' -T fields -E separator="|" -e http.host -e ip.src -e http.request.method -e http.request.uri -e http.user_agent -o 'ssl.desegment_ssl_records: TRUE' -o 'ssl.desegment_ssl_application_data: TRUE' -o 'ssl.keys_list: zzz,443,http,/etc/letsencrypt/live/xxx/privkey.pem'

Donde dice zzz es la ip pública del servidor y xxx el host, el problema es que el terminal no arroja nada, todo se queda en negro, no captura ningún paquete, pero sin el ssl captura muy bien. Ahora, el log dice lo siguiente:

Código [Seleccionar] Expandir

[root@xxx ~]# cat /var/log/https-post.log
Wireshark SSL debug log

Private key imported: KeyID 22:2a:73:...
ssl_load_key: swapping p and q parameters and recomputing u
ssl_init IPv4 addr 'zzz' (zzz) port '443' filename '/etc/letsencrypt/live/xxx/privkey.pem' password(only for p12 file) ''
ssl_init private key file /etc/letsencrypt/live/xxx/privkey.pem successfully loaded.
association_add TCP port 443 protocol http handle 0x7f0d0ed95bb0

dissect_ssl enter frame #1 (first time)
ssl_session_init: initializing ptr 0x7f0d01269410 size 696
 conversation = 0x7f0d012690e8, ssl_session = 0x7f0d01269410
 record: offset = 0, reported_length_remaining = 2840
dissect_ssl3_record found version 0x0303(TLS 1.2) -> state 0x10
dissect_ssl3_record: content_type 23 Application Data
decrypt_ssl3_record: app_data len 704, ssl state 0x10
association_find: TCP port 443 found 0x7f0d0f88b200
packet_from_server: is from server - TRUE
decrypt_ssl3_record: using server decoder
decrypt_ssl3_record: no decoder available
association_find: TCP port 443 found 0x7f0d0f88b200
 record: offset = 709, reported_length_remaining = 2131
 need_desegmentation: offset = 709, reported_length_remaining = 2131

dissect_ssl enter frame #3 (first time)
 conversation = 0x7f0d012690e8, ssl_session = 0x7f0d01269410
 record: offset = 0, reported_length_remaining = 6917
dissect_ssl3_record: content_type 23 Application Data
decrypt_ssl3_record: app_data len 6912, ssl state 0x10
association_find: TCP port 443 found 0x7f0d0f88b200
packet_from_server: is from server - TRUE
decrypt_ssl3_record: using server decoder
decrypt_ssl3_record: no decoder available
association_find: TCP port 443 found 0x7f0d0f88b200

Busqué en internet por el mensaje:

Código [Seleccionar] Expandir

decrypt_ssl3_record: using server decoder
decrypt_ssl3_record: no decoder available

Y la mayoría de las personas coinciden en que puede ser porque está capturando tráfico que ya fue negociado con el certificado y para decodificar el contenido necesita la primera negociación para que en base a eso pueda unir tanto el certificado del cliente como el del servidor, para verificar esto entre desde un sistema virtual recien instalado pero tampoco me aparece la solicitud en el terminal, definitivamente por algún motivo no funciona ni en ssldump ni en wireshark, será algún problema con el protocolo o tipo de cifrado?

Código [Seleccionar] Expandir

[root@xxx ~]# openssl x509 -noout -modulus -in /etc/letsencrypt/live/xxx/cert.pem | openssl md5
(stdin)= bbbbbb
[root@xxx ~]# openssl rsa -noout -modulus -in /etc/letsencrypt/live/xxx/privkey.pem | openssl md5
(stdin)= bbbbbb

bbbbbb equivale al mismo valor md5 del certificado y de la llave.

Estoy haciendo estas pruebas en un servidor dedicado con CentOS 7 pero de todas maneras no creo que ese sea el problema ya que los paquetes sin cifrar funcionan muy bien, desde el puerto 80 puedo capturar tdo el tráfico del servidor, pero lo que aun no logro es descifrar el contenido via https.

Lo que quiero lograr es independizarme de los logs del apache por temas de espacio y uso IO/WR del disco, asi puedo monitorear el tráfico sin matar el disco duro tan rápido ya que necesito parsear el contenido y procesar los datos con otros softwares de monitoreo que hacen uso del log del apache en tiempo real, solo quiero utilizar tshark desviando la salida del buffer a la entrada del buffer de estos sistemas haciendo pasar todo el tráfico en la memoria ram haciendo el monitoreo en tiempo real en ves de utilizar el disco, a demás también quiero monitorear el tráfico post pero antes de eso necesito ver bien el tema del ssl.

Fuera de esto también quiero ver la posibilidad de realizar este tipo de monitoreos sin tener que intervenir en el servidor web, bastaría con colocar un servidor en la misma capa de la dmz y darle permisos para realizar capturas en modo promiscuo desde el firewall y loguear sin intervenir ni afectar en la disponibilidad del sitio web ya que si hiciera un reverse proxy el sitio dependería directamente del uptime del host que lo está reversando.

Saludos.

[MinusFour]

Yo creo que tienes este problema:

Case 3: Ephemeral keying
If SSL is using one of the ephemeral keying modes then ssldump cannot
decrypt the data. These modes include essentially all of the DH cipher
suites as well as the RSA_EXPORT cipher suites (though not the
RSA_EXPORT1024) cipher suites. A sure sign of this case is when
the server is sending the ServerKeyExchange message.

[kub0x]

El problema reside en que utilizas ECDHE (Curvas elípticas con Diffie-Hellman efímero), en cristiano, en cada intercambio de clave o TLS Handshake se eligen unos parámetros distintos a los previamente empleados. Todo esto sucede en el ServerKeyExchange donde se eligen los mismos (uno de ellos es la clave privada) y se crea una firma digital (HASH + RSA signature en tu caso), por lo tanto, el atacante es imposible que sepa la clave privada, solo sabe la firma digital de los miembros públicos.

Te doy dos soluciones parciales:

- Antes de que a la víctima (ya se que lo haces en local) le llegue el ServerKeyExchange, eliminas dicho paquetes, generas tu los parámetros sobre el grupo finito y recomputas la firma digital (tienes la clave privada RSA, es trivial) y mandas el paquete a la vícitma. Al final del Handshake tendrías que recomputar los mensajes Finished para el cliente y para el server, ya que ambos han visto mensajes distintos, trivial también porque tienes la clave simétrica de cifrado.

- Eliges otra suite de cifrado, preferiblemente solo cambiar ECDHE por RSA, ya que si eliges ECDH o DH (Diffie-Hellman o DH sobre ECC) los parámetros tienen que ir en el propio certificado, por lo que recomiendo RSA, o sino reconstruir el certificado hardcodeando dichos parámetros (creo que el 99% de la comunidad criptógrafa te mataríamos ).

Saludos!

[WHK]

Vaya, y yo que cambié el método de cifrado por defecto justamente para aumentar la seguridad en el intercambio SSL y ahora resulta que es lo que me está impidiendo hacer la reversa xD, creo que optaré por usar RSA, lo había deshabilitado ya que me aparecía un problema conocido de una vulnerabilidad con el tipo de cifrado en RSA tal como estaba configurado.

Finalmente en el ssl.conf del apache que venia por defecto:

Código [Seleccionar] Expandir

SSLCipherSuite DEFAULT:!EXP:!SSLv2:!DES:!IDEA:!SEED:+3DES

Puse este orden:

# Disable SSLv3 Support for POODLE Attacks and insecure methods.
# SSLProtocol all -SSLv3 -SSLv2
# SSLHonorCipherOrder on
# SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA EECDH EDH+aRSA !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"

El problema es que si habilito RSA nuevamente volveré a tener alertas de seguridad.

De todas maneras no es que quiera hacer un ataque, lo que quiero es realizar monitoreo ssl a servidores en modo promiscuo sin tener que intervenir el servidor web, el problema es que si hay un servidor que necesite monitorear que tenga el método de cifrado ECDHE antepuesto a los demás quiere decir que será imposible hacer el seguimiento, estaré obligado a hacer un reverse proxy y aumentar la capacidad del hardware a la altura del servidor físico donde se aloja el servidor WEB.

[kub0x]

Vaya, y yo que cambié el método de cifrado por defecto justamente para aumentar la seguridad en el intercambio SSL y ahora resulta que es lo que me está impidiendo hacer la reversa xD, creo que optaré por usar RSA, lo había deshabilitado ya que me aparecía un problema conocido de una vulnerabilidad con el tipo de cifrado en RSA tal como estaba configurado.

Finalmente en el ssl.conf del apache que venia por defecto:

Código [Seleccionar] Expandir

SSLCipherSuite DEFAULT:!EXP:!SSLv2:!DES:!IDEA:!SEED:+3DES

Puse este orden:
El problema es que si habilito RSA nuevamente volveré a tener alertas de seguridad.

De todas maneras no es que quiera hacer un ataque, lo que quiero es realizar monitoreo ssl a servidores en modo promiscuo sin tener que intervenir el servidor web, el problema es que si hay un servidor que necesite monitorear que tenga el método de cifrado ECDHE antepuesto a los demás quiere decir que será imposible hacer el seguimiento, estaré obligado a hacer un reverse proxy y aumentar la capacidad del hardware a la altura del servidor físico donde se aloja el servidor WEB.

Se me ocurre que configurando un proxy TLS intermedio puedes mejorar la seguridad del procedimiento, me explico:

Tu eres el poseedor de la clave privada RSA del certificado, por lo tanto el Server puede negociar una sesión mediante RSA con tu proxy, y después le dices al cliente que utilice ECDHE, y como eres poseedor de la clave privada ECDHE ya puedes descifrar el tráfico entrante/saliente.

Simplemente has de interceptar el ServerHello que va hacia el cliente, cambiar la suite de RSA por ECDHE y recomputar el Finished.

Aunque lo óptimo no sería degradar la suite, sino utilizar ECDHE e invalidar el ClientKeyExchange del cliente, es decir, mandarle tu al server desde el proxy tu propio ClientKeyExchange, por lo tanto tienes que computar dos claves de sesión, una con el cliente y otra con el server, por lo que son dos TLS Handshakes. El problema es que cualquier cambio en el Handshake es detectable por la parte afectada al final del procedimiento (Ver mensajes Finished), por lo que tienes que recomputar dichos mensajes y hacer su MAC correspondiente.

RSA en sí no es vulnerable si se utiliza un tamaño de más de 1024 (2048 está bien), academicamente no se ha llegado a romper una clave de 1024 pero se teoriza que los gobiernos interesados podrían ser capaces de ello, ya que 1024 bit son 2⁸⁰ operaciones con el GNFS (el alg. más óptimo de factoring con números grandes).

Otro gran fallo, y yo creo que es el más a tener en cuenta, es que RSA no ofrece Perfect-Forward Secrecy, por lo que si un tercero recolecta negociaciones de claves simétricas utilizando RSA durante 10 años y consigue romper la clave RSA al de un tiempo, podrá descifrar la clave simétrica AES, TDES que protege la información cifrada, si señores, ese día llegará ya pasó en la primera/segunda mundial que al de un tiempo de acabar la guerra consiguieron descifrar mensajes del enemigo. Al utilizar algs. ephemeral daría igual a no ser que computen el DLP en un tiempo razonable, cosa que hasta que no llegue el cuántico y apliquen Shor's... La pena es que las primeras en caer serán las curvas elípticas, ya que "simulan" la seguridad de RSA/DH con menos tamaño de clave en bits, por lo que se necesitan menos qubits para dicho propósito.

Saludos!