¿Por qué no se pueden rediseñar los protocolos orientados a la conexión para evitar vulnerabilidades?

Hay libros sobre el diseño de protocolos de red robustos y seguros. Un montón de libros. Solo hay cuatro trampas.

Primero, un protocolo es tan bueno como la implementación. Es por eso que constantemente se les dice a las personas que no escriban su propio software criptográfico.

En segundo lugar, los protocolos seguros y robustos generalmente serán más pesados ​​que los protocolos convencionales. En otras palabras, consumirán más ancho de banda, tardarán más en procesarse, tomarán más memoria y, en general, harán que la vida sea dolorosa.

Tercero, tales protocolos son generalmente más complicados para escribir software. Tienes que escribir el software correcto, para empezar, y muchos programadores no saben cómo hacerlo. Los protocolos estándar son mucho más indulgentes, por lo que no son robustos ni seguros.

Finalmente, todos los sistemas operativos en estos días vienen con un conjunto de protocolos básicos, y muchos entornos de desarrollo vienen con bibliotecas que proporcionan protocolos comunes de alto nivel. El FSP no falló porque era peor que el FTP, en muchos sentidos fue superior. Fracasó porque el número de personas conscientes de ello era minúsculo y el número dispuesto a invertir tiempo y esfuerzo aprendiendo un protocolo que esencialmente nadie usó fue, bueno, esencialmente cero. Superar ese obstáculo, el costo en tiempo y esfuerzo para ingresar al mercado de protocolos, es fenomenalmente difícil. Incluso compañías como Sun y SGI carecían de los recursos para tener algún impacto.

Me imagino que mucha gente aquí usa SSH. Sospecho que menos utilizan la variante de alto rendimiento. Nadie ha encontrado que sea menos seguro, es mucho más rápido, es totalmente interoperable, pero requiere una inversión de esfuerzo. Las ganancias generalmente no son suficientes para compensar el costo, incluso para un costo tan bajo. Y no es solo el costo de obtenerlo, es el costo de descubrir que existe y el costo de descubrir si es confiable. Sabes que la versión vainilla es sin tener que mirar.

Me registré y rastreé cientos de paquetes en Freshmeat nee Freecode, porque el costo del descubrimiento se estaba volviendo estúpido. Algunos, aunque ciertamente no todos, de esos paquetes comenzaron a aparecer en las distribuciones de Linux cuando los registré en Freshmeat. Es egoísta suponer que todo eso se debió a mi trabajo (aunque no perjudica a nadie e incluso puede ser cierto en algunos casos), pero también es irrelevante. Con el servicio descontinuado y aparentemente un clon, el conocimiento de nuevos desarrollos fuera de la corriente principal llevará años en propagarse. Si se propaga en absoluto.

La pregunta original no especifica qué protocolos consideran tan vulnerables que necesitan rediseñarse, pero voy a suponer que se refieren a protocolos comunes como los del IETF que se encuentran en la parte superior de TCP.

Los más utilizados se están rediseñando . Por ejemplo, HTTP ha pasado por una serie de iteraciones, cada nueva versión agrega capas adicionales de cifrado y autenticación, lo que reduce la vulnerabilidad. Ahora hay un nuevo trabajo para mejorarlo nuevamente.

Por otro lado, puede mirar protocolos muy antiguos como FTP, BootP y Telnet y decir con razón que son viejos, decrépitos y totalmente inseguros. Tendría razón, pero todos esos protocolos han sido reemplazados por otros más nuevos y más seguros, cuando fue necesario.

Los protocolos antiguos se mantienen por varias razones,

1) Primero se debe a que no todos los dispositivos viejos se tiran inmediatamente. Tengo equipos de redes e informática de la década de 1980 que todavía funcionan hoy porque el soporte para protocolos antiguos todavía está integrado en las redes modernas. ¿Deberían esos dispositivos antiguos estar directamente conectados a Internet salvaje? Probablemente no. ¿Puedo encenderlos de manera segura y usarlos en una red privada en casa o en un museo? Si.

1a) Incluso si se reemplaza un protocolo antiguo, debe considerar el costo de abandonar por completo el antiguo. Si HTTP fuera completamente reemplazado por algún protocolo totalmente seguro, ¿vamos a requerir que cada teléfono, computadora portátil, servidor, tableta y reloj inteligente sea actualizado o desechado de inmediato? No. Se incorporará por fases durante un largo período de tiempo, para permitir que los dispositivos más antiguos se actualicen o se eliminen gradualmente.

2) Costo. Los protocolos más seguros utilizan muchos más recursos para realizar el trabajo, generalmente agregando paquetes adicionales en la red y / o agregando cómputo en los puntos finales. Algunas situaciones no requieren ese nivel de seguridad y, por lo tanto, no requieren ese nivel de recursos. Agregar más capacidad de red y capacidad computacional aumenta el costo y, por lo tanto, los diseñadores lo omiten cuando se enfrentan a graves restricciones de costos o creen que se encuentran en una situación que no necesita ese nivel de seguridad.

2c) Se podría ver un caso extremo de reducción de costos en redes y dispositivos de datos automotrices (dispositivos de bus CAN). Los fabricantes de automóviles han trabajado continuamente durante muchos años para reducir el costo hasta el punto de que literalmente no tienen seguridad en absoluto en estos sistemas, y no tienen una capacidad informática excesiva en los dispositivos para agregarlo. Ahora están comenzando a pagar el precio (todos los artículos de noticias de explotación de automóviles son una señal temprana de esto). Además, los técnicos automotrices generalmente han ignorado décadas de investigación realizada por los técnicos informáticos en protocolos y seguridad.

3) Referencia. Los protocolos antiguos proporcionan una referencia histórica. Puede no parecer importante, pero lo es. La mayoría de los protocolos nuevos se construyen sobre los antiguos, por lo que debe mantener los protocolos antiguos como base para los nuevos. Los protocolos antiguos también son más simples, en algunos casos, por lo que se convierten en buenas herramientas de aprendizaje para que los estudiantes comprendan o implementen a medida que aprenden sobre la creación de redes.