OpenSSL::SSL::SSLError SSL_accept returned=1 errno=0 state=unknown state: tlsv1 alert protocol version
Esa es una respuesta común de OpenSSL cuando se interrumpe el flujo de TCP debajo del protocolo de enlace. Dice que está haciendo un pentesting en el momento en que esto sucede, esto tiene connotaciones de seguridad de red, pero no las que uno probablemente adivinaría al principio. Esta respuesta es una suposición basada en ver ese error varias veces.
Cuando la sesión está inactiva, no envía paquetes keepalive (es decir, no envía ACK adicionales). Dicha sesión TCP "muerta" será cortada por un firewall con estado, sin importar si el firewall considera que la conexión es válida (o inofensiva) o no. Dado que usted está haciendo una prueba piloto, me imagino que está trabajando dentro de una red donde hay varios cortafuegos instalados.
¿Por qué haría esto un firewall con estado?
Hoy en día, los firewalls sin estado son bastante históricos * por lo tanto, todos los firewalls son con estado, mantienen el estado (y el historial) de cada conexión que pasa a través del firewall. Lo realizan no solo para NAT, sino también para cualquier tráfico que pase a través del firewall. Dicho servidor de seguridad con estado es vulnerable a un ataque DoS al dejar demasiadas conexiones colgantes y llenar su memoria. Para evitar que un firewall con estado tenga un tiempo de espera en el que se descarta la conexión (no hay tráfico durante el tiempo de espera).
Cuando despiertas tu sesión SSL, envía un ACK. Pero el cortafuegos había dejado de lado esa conexión de su memoria y no tiene ni idea de la existencia de la sesión TCP, por lo que responde con RST. El RST provoca un error state=unknown desde el nivel SSL.
El sistema en el otro lado del firewall puede ser consciente de su conexión, y respondería si el ACK lo hubiera alcanzado. Pero el firewall no lo dejará pasar.
¿Qué puedes hacer al respecto?
No mucho. Podría ejecutar un proxy con estado en su propia máquina que mantendría el envío de keepalive de TCP en un lado (el exterior), pero no requeriría keepalives en el otro lado (el interior, loopback).
Sin embargo, si usted, por ejemplo, pone toda la máquina en suspensión, entonces el proxy de estado no enviará ACK adicionales de todos modos para evitar su propósito (y hará que la depuración de la conexión sea aún más difícil de lo que es solo con los firewalls). / p>
* Un firewall sin estado es vulnerable a ataques triviales (bypass), como la fragmentación de IP del paquete SYN inicial.