He estado leyendo sobre SSL / TLS y me sorprendió cuando vi la cantidad de implementaciones de SSL / TLS que existen. wikipedia .
Entonces, ¿existe realmente la necesidad de todas estas diferentes implementaciones?
¿No sería más barato, más productivo y más rápido mantener una implementación como OpenSSL?
La competencia es algo bueno, y también lo es la redundancia / diversidad.
Si bien Heartbleed afectó a muchos sistemas y servicios debido a la extensión del OpenSSL, ciertamente no afectó al 100% de los sistemas. La redundancia en el software en general es buena. Si tiene un problema con una pieza de software, puede conmutar a otro o mitigar el riesgo al distribuir sus dependencias de software entre varios proveedores (como lo haría con el hardware).
En segundo lugar, la competencia en los negocios impulsa la eficiencia y la calidad. Lo mismo es cierto para el software. Si aparece una solución más fácil de usar, más eficiente o mejor, entonces podría superar al software establecido o forzar a ese software establecido a mejorar.
Esta pregunta puede extenderse fácilmente a cualquier problema que pueda ser resuelto por una biblioteca, relacionado con la seguridad o no. Esta respuesta se aplica a las bibliotecas que implementan cualquier funcionalidad estandarizada y no es específica de SSL.
No todas las licencias de software son compatibles entre sí. Cuando desee utilizar una biblioteca con licencia GPL, debe licenciar todo su proyecto bajo GPL, lo que podría no encajar en su estrategia comercial. Otras organizaciones podrían rechazar cualquier cosa excepto una licencia específica por razones ideológicas. Esto conduce a múltiples soluciones para el mismo problema, que en la práctica solo difieren según los términos de la licencia.
Incluso cuando un estándar en sí no está patentado, podría haber un cierto método para implementar ese estándar. En ese caso, tiene que usar el método de implementación patentado y pagar la tarifa, mudarse a un país donde la patente no es ejecutable o crear una nueva implementación con un método diferente que funcione en torno a la patente.
A menudo sucede que dos equipos de desarrollo diferentes desarrollan una implementación de la misma tecnología de forma independiente. Cuando ambas soluciones llegan al mercado, ninguna quiere admitir que su solución es inferior, por lo que ambas seguirán promoviendo y manteniendo su solución.
Para asegurarse de que una biblioteca se adapte bien a su programa, preferiblemente debe estar escrito en el mismo lenguaje de programación. Cuando tienes un programa en C, preferirías una biblioteca escrita en C. Cuando usas Java, te gustaría una implementación de Java. Cuando usas C #, preferirías que se implementara en .NET. No es imposible en ninguna de las dos tecnologías interactuar con los componentes escritos en las otras, pero siempre requiere algo de pegamento y cinta adhesiva para hacer que se conecte a la interfaz, lo que podría perjudicar el rendimiento, la legibilidad del código y complicar aún más la compilación de herramientas. / p>
Los diferentes proyectos tienen diferentes prioridades. Algunos quieren la implementación más rápida posible. Algunos necesitan una huella de memoria muy baja. Algunos quieren la implementación con el mejor registro de seguimiento de seguridad (que se puede medir de muchas maneras diferentes). La mejor biblioteca para un proyecto no es necesariamente la mejor para otro. Tener múltiples opciones para elegir puede ser beneficioso.
¿No sería más barato, más productivo y más rápido solo para [...]
¡Ah! Toda la historia de la humanidad.
Existen múltiples implementaciones de SSL por la única y más poderosa razón por la que algunas personas las escribieron. Después de todo, para que una nueva implementación de cualquier cosa exista, basta para que alguna persona solitaria, en algún momento (posiblemente después de una pinta de más), crea que escribir una nueva sería una buena idea. No existe una estructura de gestión general que planifique y dirija los esfuerzos de implementación de todos los desarrolladores en el planeta. En su lugar, hay miles, incluso millones de entidades independientes que siguen sus propios caprichos, que no tienen por qué ser racionales, y mucho menos quepan en algún plan maestro.
Si nos fijamos en los proyectos individuales, podemos ver algunas diferencias técnicas y locales. Estoy usando "técnica" en un sentido amplio aquí; p.ej. GnuTLS se presentó como competidor de OpenSSL Principalmente debido a problemas de licencia. Otros han señalado que una biblioteca de SSL debe, por definición, integrarse en el contexto de otras aplicaciones, lo que también implica una gran variabilidad.
Por ejemplo, una vez, personalmente, escribí una nueva implementación de SSL / TLS en C, que actualmente se implementa en producción: el cliente necesitaba algo que encajara en sus dispositivos integrados (específicamente, en el código de rutina de carga para sus dispositivos incrustados), y no había manera de que OpenSSL pudiera ejecutarse dentro de los 20 kB de ROM + 20 kB de RAM, en un sistema operativo barebone que ni siquiera ofrece una llamada malloc() . Mi código podría; SSL no es un protocolo grande, si elimina algunas de las partes opcionales (por ejemplo, concéntrese en un par de conjuntos de cifrado, no implemente las extensiones que no necesita, y así sucesivamente).
Hay otra razón, que también no está relacionada con la seguridad: para convertirse en un protocolo estándar de Internet, uno tiene que demostrar múltiples implementaciones independientes interoperables de ese protocolo. IOW: necesitamos tener implementaciones múltiples de TLS, porque si no tuviéramos implementaciones múltiples de TLS, no tendríamos TLS!