Fallo de negociación con saludos de cliente idénticos

Question

Fallo de negociación con saludos de cliente idénticos

#1 de John Deters (1 votos)

4

Estoy al final de mi ingenio investigando una falla en el apretón de manos que estoy recibiendo.

Tenemos dos clientes separados que usan .Net + Server 2012 R2. Ambos intentan un protocolo de enlace TLS con la misma IP de destino. Wireshark muestra al cliente hola como idéntico para ambos lados, pero solo uno tiene éxito. Para el fallido, el servidor responde con un error de intercambio (código de error 40) inmediatamente después del saludo del cliente.

He hecho una comparación de diferencias del volcado hexadecimal de los saludos del cliente y las únicas diferencias notables son la marca de tiempo y el azar.

Éxito:

Error:

¿Cuál podría ser el problema en este punto? ¿Podría ser incluso un problema de TLS si no hay diferencias en el cliente? No he podido encontrar ningún recurso que pueda explicar esto.

Incluso las ideas sobre qué investigar serán útiles.

EDITAR: Si otros se encuentran con esto, el problema fue el software de seguridad de red BlueCoat. Creamos una regla de omisión para nuestro servidor cliente y el protocolo de enlace ahora es exitoso.

tls

pregunta Iron Cody 29.03.2017 - 21:48

fuente

1 respuesta

Lea otras preguntas en las etiquetas tls

Generar lista de palabras usando reglas no predeterminadas (John The Ripper) Detener DNSSpoof después de iniciar sesión

score 1 · Accepted Answer

Esta podría ser la acción de un Sistema de detección de intrusiones en la red, como snort , que ha encontrado algún motivo para negarse a permitir que uno de los sistemas para conectar.

Los sistemas NIDS funcionan detectando todos los paquetes en la red, identificando aquellos que pueden estar asociados con comportamientos sospechosos (como una exploración de puertos) y luego respondiendo de alguna manera. De forma predeterminada, la mayoría de los NIDS solo escribirán una alerta en el registro si ven algo. Pero es posible que su equipo de red se haya vuelto más agresivo, momento en el que pueden haber habilitado la "interrupción activa".

Digamos que el cuadro de falla se usó para hacer un escaneo de red, y su NIDS lo atrapó. Registraría esa dirección IP, y cada vez que ve un paquete en la red asociada con esa dirección IP, le envía un paquete RST falsificado que parece provenir de la dirección IP del servidor. Eso evitaría que la máquina se conecte al servidor, lo que sin duda detendría un ataque.

Recomiendo contratar al equipo de seguridad de la red de su organización y ver si tienen algún registro de la dirección IP de la máquina defectuosa que está siendo detectada por su NIDS.