¿Puede un intruso terminar una conexión TCP si se ha utilizado SSL / TLS para proteger los datos en el segmento TCP?

Esto es totalmente factible, con la advertencia de que necesita saber el número de secuencia correcto requerido por la pila de TCP de destino. (para poder hacerlo para todas las conexiones a un servidor, debe estar en el servidor mismo o en una puerta de enlace a ese servidor).

Nota: cuanto más lejos esté de la pila objetivo, más probable es que tenga problemas de tiempo con la inyección. (Suponiendo que es una inyección de paquetes y no un paquete completo)

También sé por experiencia que tales interceptaciones se rompen rápidamente con una pequeña actualización de seguridad en la pila de destino :(

¿Rst y fin estarán relativamente protegidos, por lo que vale la pena ver simplemente el ajuste del tamaño de la ventana del TCP en cero? (solo un pensamiento, ha pasado mucho tiempo [¡una década ahora!] desde que jugué con estas cosas)

  

..pero me gustaría saber CÓMO las partes comunicantes sabrían que la conexión se termina de forma incorrecta y por qué solo se interrumpe.

El punto central de tcp es proporcionar conexiones confiables, si cancelas la conexión, entonces la pila en cada lado sabe. Solo se interrumpe porque cuando la conexión se corta, la mayoría de los sistemas reintentarán la conexión, por lo general sin siquiera avisar al usuario.

Mi respuesta inicial está debajo ("No ...") en una cita en bloque, pero necesito corregirlo porque creo que mi respuesta es incorrecta. TCP no garantiza la inmunidad de replay y / o ataques de man-in-the-middle . De hecho, este tipo de interrupción se conoce comúnmente como ataque de reinicio de TCP . El problema es que TCP no tiene autenticación de mensajes integrada y TCP no puede garantizar la autenticidad de los paquetes, para lograrlo, uno necesita confiar en Transport Layer Security (TLS) en HTTPS. Si una aplicación puede detectar un paquete fuera de orden o un FIN ilegítimo, este es un servicio auxiliar y no está especificado por el estándar TCP. Ahora abajo está mi evaluación inicial incorrecta:

No, un atacante no puede terminar con éxito una conexión TCP con la inyección de un paquete 'FIN', ya que TCP es un protocolo mutuamente contingente que requiere que ambas partes estén de acuerdo (es decir, un lado inicia un cambio de estado mediante el envío de una declaración de intención). luego espera recibir el acuse de recibo de esa intención, y luego tramitará el cambio de estado) a la transacción para que esa transacción sea ejecutada. Esto corresponde a la respuesta dada en Brent Baccala (editor) * Conectado: una enciclopedia de Internet, * Tercera edición donde encontramos lo siguiente:

Caso 2: TCP recibe un FIN de la red Si un FIN no solicitado llega de la red, el TCP receptor puede ACK y le dice al usuario que la conexión se está cerrando. El usuario responderá con un CERRAR, sobre el cual el TCP puede enviar un FIN al otro TCP después de enviar cualquier dato restante. El TCP luego espera hasta que se confirma su propia FIN, con lo cual borra la conexión. Si no se recibe un ACK, después de que el usuario agote el tiempo de espera, se interrumpe la conexión y se le dice al usuario.

[Conectado: una enciclopedia de Internet Cierre de conexión TCP] [5] Entonces, incluso si el número de secuencia del paquete es correcto, un "FIN" inesperado no termina las comunicaciones entre las dos computadoras de acuerdo con la descripción del protocolo TCP. No lo olvidemos: el receptor no solo emitirá una respuesta para que el remitente reconozca el "FIN", sino que reciba dos paquetes en conflicto con el mismo número de secuencia, y, a menos que el receptor esté en un punto de anticipación del "FIN", se eliminará y la comunicación continuará o se reiniciará en el último estado acordado por ambas terminales.