Sé que TLS es esencialmente una versión más nueva de SSL, y que generalmente admite la transición de una conexión no segura a segura (comúnmente a través de un comando STARTTLS).
Lo que no entiendo es por qué TLS es importante para un profesional de TI, y por qué si tuviera la opción, elegiría uno sobre el otro. ¿TLS es realmente solo una versión más nueva, y si es así, es un protocolo compatible?
Como profesional de TI: ¿cuándo uso cuál? ¿Cuándo no uso cuál?
Respuesta corta:
SSL es el precursor de TLS. SSL era un protocolo propietario desarrollado por Netscape Communications, luego estandarizado dentro de IETF y renombrado como TLS. En resumen, las versiones van en este orden: SSLv2, SSLv3, TLSv1.0, TLSv1.1 y TLSv1.2.
Contrariamente a una creencia relativamente extendida, no se trata de tener que ejecutar un servicio en un puerto distinto con SSL y poder hacerlo en el mismo puerto que la variante de texto sin formato con TLS. Tanto SSL como TLS se pueden usar para los dos enfoques. Se trata de la diferencia entre SSL / TLS en la conexión (a veces denominado "SSL / TLS implícito") y SSL / TLS después de que se emitió un comando a nivel de protocolo, por lo general STARTTLS(a veces denominado "SSL / TLS explícito") . La palabra clave STARTTLSes "INICIAR", no TLS. Es un mensaje, a nivel de protocolo de aplicación, para indicar que debe haber un cambio a SSL / TLS, si no se ha iniciado antes de cualquier intercambio de protocolo de aplicación.
El uso de cualquiera de los modos debe ser equivalente, siempre que el cliente esté configurado para esperar SSL / TLS de una forma u otra, para no ser degradado a una conexión de texto sin formato.
Respuesta más larga:
Que yo sepa, SSLv1 nunca abandonó los laboratorios. SSLv2 y SSLv3 fueron protocolos desarrollados por Netscape. SSLv2 se ha considerado inseguro por un tiempo, ya que es propenso a ataques de degradación. SSLv3 usa internamente (3,0)como su número de versión (dentro del ClientHellomensaje).
TLS es el resultado de la estandarización como un protocolo más abierto dentro de IETF. (Creo que he leído en alguna parte, tal vez en el libro de E. Rescorla, que el nombre había sido elegido de tal manera que todos los participantes estaban igualmente descontentos con él, para no favorecer a una compañía en particular: esta es una práctica bastante común en los estándares cuerpo.) Aquellos interesados en cómo se hizo la transición pueden leer las Preguntas frecuentes sobre la lista SSL-Talk ; existen varias copias de este documento, pero la mayoría de los enlaces (a ) están desactualizados.netscape.com
TLS utiliza mensajes muy similares (lo suficientemente diferentes como para hacer que los protocolos sean incompatibles, aunque es posible negociar una versión común ). Los TLS 1.0 , 1.1 y 1.2 ClientHello mensajes utilizan (3,1), (3,2), (3,3)para indicar el número de versión, que muestra claramente la continuación de SSL.
Hay más detalles sobre las diferencias de protocolo en esta respuesta .
¿Cuándo uso cuál? ¿Cuándo no uso cuál?
Use la versión más alta que pueda si es posible. En la práctica, como proveedor de servicios, esto requerirá que sus usuarios tengan clientes que admitan estas versiones. Como de costumbre, siempre es un ejercicio de evaluación de riesgos (preferiblemente respaldado con un caso de negocios, si corresponde). Dicho esto, corte SSLv2 de todos modos.
Además, tenga en cuenta que la seguridad proporcionada por SSL / TLS no se trata solo de la versión que usa, también se trata de la configuración adecuada: sin duda es preferible usar SSLv3 con un conjunto de cifrado fuerte que TLSv1.0 con un con un débil (o conjunto de cifrado anónimo / cifrado nulo). Algunas suites de cifrado, consideradas demasiado débiles, han sido explícitamente prohibidas por las nuevas versiones de TLS. Las tablas en el proveedor Java 7 SunJSSE (y sus notas a pie de página) pueden ser de interés si desea más detalles.
Sería preferible usar TLS 1.1 al menos, pero desafortunadamente no todos los clientes los admiten (por ejemplo, Java 6). Cuando se utiliza una versión anterior a la 1.1, vale la pena considerar mitigar la vulnerabilidad de BEAST .
En general, recomendaría el libro de Eric Rescorla - SSL y TLS: Diseño y construcción de sistemas seguros, Addison-Wesley, 2001 ISBN 0-201-61598-3 a las personas que realmente quieren más detalles.
Hay un mito que dice que TLS le permite usar el mismo puerto, mientras que SSL no puede. Eso no es cierto (y dejaré la unificación de puertos para esta discusión). Desafortunadamente, este mito parece haberse propagado a los usuarios por el hecho de que algunas aplicaciones como MS Outlook a veces ofrecen una opción entre SSL y TLS en sus opciones de configuración cuando en realidad significan una elección entre SSL / TLS implícito y explícito. (Hay expertos en SSL / TLS en Microsoft, pero parece que no estuvieron involucrados en la interfaz de usuario de Outlook).
Creo que la razón por la que ocurre esta confusión es por el STARTTLSmodo. Algunas personas parecen haber entendido esto como STARTTLS= TLS, pero este no es el caso. La palabra clave STARTTLSes "INICIAR", no TLS. Por qué esto no se llamó STARTSSLo STARTSSLORTLSes porque estas extensiones se especificaron dentro de IETF, que solo usaba nombres usados en sus especificaciones (suponiendo que el nombre TLS eventualmente sería el único en pie, supongo).
Hoy en día, la mayoría de los servidores HTTPS pueden manejar TLS, pero hace unos años, la mayoría de las personas usaban SSLv3 para HTTPS. HTTPS (estrictamente hablando, estandarizado como HTTP sobre TLS ) normalmente establece la conexión SSL / TLS tras la conexión TCP, y luego intercambia mensajes HTTP sobre la capa SSL / TLS. Hay una excepción a esto cuando se usa un proxy HTTP en el medio. En este caso, el cliente se conecta al proxy HTTP en claro (generalmente en el puerto 3128), luego emite el CONNECTcomando HTTP y, siempre que la respuesta haya sido exitosa, inicia el protocolo de enlace SSL / TLS enviando unClientHellomensaje. Todo esto sucede en el mismo puerto en lo que respecta a la conexión entre el navegador y el proxy (obviamente no entre el proxy y el servidor de destino: ni siquiera es la misma máquina). Esto funciona bien con SSLv3. Muchos de nosotros en situaciones detrás de un proxy habremos usado esto contra servidores que no admitían al menos TLS 1.0.
Este está claramente fuera de especificaciones, pero en la práctica, a menudo funciona. Hablando estrictamente, las especificaciones hablan sobre cambiar a TLS (no SSL) después de usar el comando STARTTLS. En la práctica, SSL a menudo también funciona (al igual que la especificación "HTTP sobre TLS" también abarca el uso de SSL en lugar de TLS también). Puedes probarlo tú mismo. Suponiendo que tiene un servidor SMTP o IMAP que admite STARTTLS, use Thunderbird, vaya a las preferencias, opciones avanzadas, editor de configuración y apague security.enable_tls. Muchos servidores seguirán aceptando la conexión, simplemente porque sus implementaciones delegan la capa SSL / TLS a una biblioteca SSL / TLS que generalmente podrá manejar SSL y TLS de la misma manera, a menos que esté configurado para no hacerlo. Como dice el FAQ de OpenLDAP , "Si bien el mecanismo está diseñado para usarse con TLSv1, la mayoría de las implementaciones recurrirán a SSLv3 (y SSLv2) si es necesario. ". Si no está seguro, consulte con una herramienta como Wireshark.
Muchos clientes pueden usar TLS 1.0 (al menos) para protocolos donde la variante segura está en un puerto diferente. Obviamente, hay varios navegadores y servidores web que admiten TLS 1.0 (o superior) para HTTPS. Del mismo modo, SMTPS, IMAPS, POPS y LDAPS también pueden usar TLS. No se limitan a SSL.
¿Cuándo uso cuál? ¿Cuándo no uso cuál?
Entre SSL / TLS explícito e implícito, realmente no importa. Lo que importa es que su cliente sepa qué esperar y esté configurado adecuadamente para hacerlo. Más importante aún, debe configurarse para rechazar conexiones de texto sin formato cuando se espera una conexión SSL / TLS, ya sea implícita o explícita .
La principal diferencia entre SSL / TLS explícito e implícito estará en la claridad de la configuración.
Por ejemplo, para LDAP, si el cliente es un servidor Apache Httpd (desafortunadamente mod_ldap, su documentación también etiqueta erróneamente la diferencia entre SSL y TLS), puede usar SSL / TLS implícito usando una ldaps://URL (por ejemplo AuthLDAPURL ldaps://127.0.0.1/dc=example,dc=com?uid?one) o usar SSL / explícito TLS mediante el uso de un parámetro adicional (por ejemplo AuthLDAPURL ldap://127.0.0.1/dc=example,dc=com?uid?one TLS).
No hay quizás en términos generales un riesgo ligeramente menor cuando se especifica el protocolo de seguridad en el esquema de URL ( https, ldaps, ...) que cuando se espera el cliente para configurar un ajuste adicional para habilitar SSL / TLS, porque pueden olvidar. Esto es discutible. También puede haber problemas en la corrección de la implementación de uno versus otro (por ejemplo, creo que el cliente LDAP de Java no admite la verificación del nombre de host cuando se usa ldaps://, cuando debería, mientras que es compatible con ldap://+ StartTLS).
En caso de duda, y para ser compatible con más clientes si es posible, no parece hacer daño ofrecer ambos servicios cuando el servidor lo admite (su servidor solo escuchará en dos puertos al mismo tiempo). Muchas implementaciones de servidores para protocolos que se pueden usar con cualquiera de los modos admitirán ambas.
Es responsabilidad del cliente no dejarse degradar a una conexión de texto sin formato. Como administrador del servidor, técnicamente no hay nada que pueda hacer de su lado para evitar ataques de degradación (aparte de requerir un certificado de cliente tal vez). El cliente debe verificar que SSL / TLS esté habilitado, ya sea mediante conexión o después de un STARTTLScomando similar. En la misma forma que un navegador no debe dejarse ser redirigido a partir https://de http://, un cliente para un protocolo que el apoyo STARTTLS
debe asegurarse de que la respuesta fue positiva y el protocolo SSL / TLS conexión se habilitó antes de seguir adelante. Un atacante MITM activo podría degradar fácilmente cualquiera de las conexiones.
Por ejemplo, las versiones anteriores de Thunderbird tenían una mala opción para esto llamada "Usar TLS, si está disponible" , lo que esencialmente implicaba que si un atacante MITM podía alterar los mensajes del servidor para que no anunciara soporte para STARTTLS, el cliente silenciosamente se dejaría degradar a una conexión de texto sin formato. (Esta opción insegura ya no está disponible en Thunderbird).
TLS es un protocolo más nuevo que SSL (pero AFAIK, es compatible con SSL v3). Por lo general, solo debe preocuparse por una diferencia:
Un protocolo SSL generalmente tiene un puerto separado, por ejemplo, 80 para HTTP y 443 para HTTPS (HTTP / SSL). Cuando se conecta al puerto SSL, toda la sesión se cifra.
TLS es más nuevo que SSL, y no requiere un puerto separado; en cambio, debe ser negociado por el cliente. Por ejemplo, puede ejecutar IMAP en el puerto 143, y si tanto el servidor de correo como el cliente admiten TLS, el cliente enviará un
STARTTLScomando y solo entonces habilitará el cifrado. De esta manera, no necesita un puerto solo de SSL por separado, mientras se mantiene compatible con aplicaciones sin SSL.Resumen:
SSL : un poco más antiguo. Puertos separados para conexiones simples y encriptadas. Todo el tráfico en el puerto SSL siempre está encriptado.
TLS : puerto único para conexiones simples y encriptadas. El cifrado solo se habilita después de que el cliente emite un
STARTTLScomando.fuente
STARTTLSen algunos protocolos permita cambiar a TLS en la misma conexión no es una diferencia entre SSL y TLS. Técnicamente, podría cambiar a SSLv3 de la misma manera.TLS es simplemente una versión más nueva de SSL. Use TLS cuando tenga la opción. Más, como de costumbre, en Wikipedia .
fuente
De este artículo de Indiana University Knowledge Base :
fuente
TLS es la versión más nueva de SSL. Aunque en algunos lugares estas palabras pueden significar algo más que solo protocolos, por lo tanto, aclare su pregunta.
fuente