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

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 API de 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 de la industria tan ubicuo como TCP / IP, entonces, ¿por qué no está integrado en la mayoría de los sistemas operativos?

Creo que depende principalmente de lo que ves como "el sistema operativo". Si es el núcleo, mi respuesta sería: ¿por qué debería hacerlo? Puede que me equivoque, pero ¿el DNS no forma 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 podrían tener más de uno.

Incluso puede verse como una ventaja. Si no hubiera OpenSSL, tendría que adaptarse a la API de Windows, Mac y Linux (y ...). TLS no es parte del sistema operativo y permite escribir aplicaciones TLS multiplataforma. Simplemente elija una biblioteca TLS, que sea compatible con 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 es gratis. Es un esfuerzo para los programadores y un inconveniente para los usuarios.

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

Hay beneficios obvios al incorporar TCP en el sistema operativo. TCP requiere sincronización de precisión y respuesta rápida a los paquetes de red, incluso cuando no hay datos de la aplicación involucrados. Si intentara implementar TCP en el espacio de usuario sobre una API IP genérica, sería mucho peor. No hay ventajas similares a la integración de SSL en el núcleo.

Por otro lado, hay algunas desventajas. Por ejemplo, SSL requiere manipular llaveros y listas de certificados y similares. Hacerlo a través de un kernel o API del sistema operativo sería poco elegante. Entonces, incluso si viniera con el sistema operativo, sería solo una biblioteca (al igual que en Windows). Esas bibliotecas ya están disponibles de todos modos, por lo que, en última instancia, es solo un cambio en el empaque.

Hay una serie de razones, pero quizás el más convincente es que la criptografía es muy, muy difícil de conseguir realmente la derecha . No es prudente implementarlo usted mismo a menos que pueda dedicar recursos importantes a 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 negocio 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.

Soy 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 una de las API más crípticas que uno tendría que descubrir.

SSL es una capa sobre la parte superior 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 la creación de redes hasta el punto en que un cliente del sistema operativo "hace cosas". Y esas cosas pueden ser lo que quieras.

Es poco probable que SSL en el kernel conduzca a una ganancia masiva de rendimiento, entonces, ¿por qué molestarse?

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

Hay algún soporte de Kernel para Crypto y SSL. Esto tiene sentido porque el Kernel puede interactuar de manera más eficiente 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 núcleo en Solaris o las diversas bibliotecas de cifrado en el núcleo (utilizadas, por ejemplo, para VPN). Un motor criptográfico acelerado por hardware típico 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 ve con más frecuencia es que algunos protocolos de aplicación no están correctamente organizados (piense en STARTLS) o requieran decisiones de aplicación durante el apretón de manos (piense en el certificado del cliente y la comprobación de CRL) o simplemente estén en una evolución regular.