¿Por qué SSL / TLS no está integrado en los sistemas operativos modernos?

15

Muchos de los protocolos de red básicos que conforman la infraestructura de Internet están integrados en la mayoría de los principales sistemas operativos. Por ejemplo, TCP, UDP y DNS están integrados en Linux, UNIX y Windows, y están disponibles para el programador a través de las API del sistema de bajo nivel.

Pero cuando se trata de SSL o TLS, uno tiene que recurrir a una biblioteca de terceros como OpenSSL o Mozilla NSS.

SSL es un protocolo relativamente antiguo y es básicamente un estándar industrial tan ubicuo como TCP / IP, ¿por qué no está integrado en la mayoría de los sistemas operativos?     

pregunta Channel72 20.03.2011 - 01:15

7 respuestas

8

Creo que depende principalmente de lo que ves como "el sistema operativo". Si es el kernel, mi respuesta sería: ¿por qué debería? Podría estar equivocado, pero ¿el DNS no es parte de glibc en los sistemas Linux, que es una biblioteca de terceros?

Si no se trata de kernel o espacio de usuario, casi todos los sistemas operativos / plataformas tienen una pila SSL / TLS, algunos pueden tener más de uno.

Incluso se puede ver como una ventaja. Si no hubiera OpenSSL, tendría que adaptarse a la API de Windows, Mac y Linux (y ...). TLS, que no forma parte del sistema operativo, permite escribir aplicaciones TLS multiplataforma. Simplemente elija una biblioteca TLS que admita sus plataformas de destino.

Para mí, el verdadero problema con TLS es que no puedes simplemente "encenderlo". En su lugar, debe administrar un conjunto de certificados de confianza, listas de revocación de certificados, certificados autofirmados, etc. Todo esto requiere mucha interacción del usuario.

Lamentablemente, la seguridad nunca viene gratis. Es un esfuerzo para los programadores y un inconveniente para los usuarios.

    
respondido por el paztulio 20.03.2011 - 02:06
6

Hay un problema legal. Algunos países ponen la criptografía en el mismo grupo de armas. Poner código criptográfico en el kernel hace que sea más difícil exportar cualquiera de los códigos del kernel.

    
respondido por el dan_waterworth 20.03.2011 - 08:50
2

Hay ventajas obvias al integrar TCP en el sistema operativo. TCP requiere una sincronización precisa y una respuesta rápida a los paquetes de red, incluso cuando no se trata de datos de aplicación. Si intentara implementar TCP en el espacio de usuario sobre una API genérica de IP, sería mucho peor. No hay ventajas similares a la integración de SSL en el kernel.

Por otro lado, hay algunas desventajas. Por ejemplo, SSL requiere la manipulación de anillos de claves y listas de certificados y similares. Hacer eso a través de un kernel o una API del sistema operativo sería poco elegante. Entonces, incluso si se incluyera con el sistema operativo, solo sería una biblioteca (como en Windows). Esas bibliotecas ya están disponibles de todos modos, por lo que en última instancia es solo un cambio en el empaquetado.

    
respondido por el David Schwartz 13.08.2011 - 10:06
1

Hay varias razones, pero tal vez la más convincente es que la criptografía es muy, muy difícil de conseguir correctamente . No es prudente implementarlo usted mismo a menos que pueda dedicar recursos importantes para verificar que sea correcto y sólido. La mayoría de las personas que trabajan con software criptográfico no tienen el tiempo, la experiencia o el deseo de atascarse en esto; confían en las bibliotecas de terceros para que sus desarrolladores puedan manejar esa parte del trabajo, mientras que los desarrolladores de aplicaciones pueden volver a hacer lo que quieren hacer.

Los desarrolladores de sistemas operativos no son tan diferentes. A veces hay un interés primordial, por ejemplo, su modelo de negocios o sus abogados requieren que mantenga el código cerrado, por lo que no tiene muchas opciones al respecto: si no puede encontrar a alguien que le permita hacerlo Lo que tienes que hacer, entonces tienes que rodar el tuyo. Otros ya han mencionado cómo Microsoft hace esto. Pero en términos generales, los desarrolladores de sistemas operativos que pueden usar bibliotecas de terceros prefieren hacerlo de esa manera, por las mismas razones que los desarrolladores de aplicaciones.

    
respondido por el The Spooniest 19.09.2013 - 17:11
0

Soy un desarrollador de Windows, así que no puedo hablar por otros sistemas operativos, pero en Windows tenían SSL incorporado durante mucho tiempo. Lo llaman SChannel y, aunque es compatible, es uno de las APIs más crípticas que uno tendría que resolver.

    
respondido por el DXM 20.03.2011 - 06:28
0

SSL es una capa encima de un protocolo de nivel inferior. Por ejemplo, SSL se ejecuta sobre la parte superior de TCP (que está sobre la parte superior de IP).

¿Dónde se detiene el sistema operativo?

Es muy fácil argumentar que el sistema operativo proporciona servicios básicos como redes hasta un punto en el que un cliente del sistema operativo "hace cosas". Y esas cosas pueden ser lo que quieras.

Es bastante improbable que SSL en el kernel lleve a una ganancia masiva de rendimiento, ¿por qué molestarse?

Los kernels de sistemas operativos modernos se ejecutan en millones de líneas de código, lo que agrega más solo agrega complejidad y más tiempo de depuración. Dejar cosas como el protocolo de capa superior fuera del sistema operativo facilita el desarrollo del sistema operativo y, al final, hace poca diferencia en la función o el rendimiento de una aplicación final. (Podría hacer que el trabajo de los desarrolladores para la aplicación final sea un poco más doloroso).

    
respondido por el quickly_now 20.03.2011 - 10:36
0

Hay algo de soporte de Kernel para Crypto y SSL. Esto tiene sentido porque el Kernel puede interactuar más eficientemente con el hardware y también es conveniente proteger las credenciales de cualquier aplicación. Buenos ejemplos son kssl, un Proxy SSL inverso a nivel de Kernel en Solaris o las diversas bibliotecas criptográficas en el kernel (utilizadas por ejemplo para VPN). Un típico motor criptográfico acelerado por hardware también tiene un módulo de kernel (y es accesible a través de PKCS # 11 o interfaces criptográficas específicas del sistema operativo).

Algunas de las razones por las que no lo ves con más frecuencia es que algunos protocolos de aplicación no están adecuadamente en capas (piense en STARTLS) o requieren decisiones de aplicación mientras se toma el protocolo de enlace (piense en el certificado del cliente y la verificación de CRL) o simplemente están en una evolución regular.

    
respondido por el eckes 19.09.2013 - 01:31

Lea otras preguntas en las etiquetas