¿Cuál es la diferencia entre SSL, TLS y HTTPS?

TLS es el nuevo nombre de SSL. En concreto, el protocolo SSL llegó a la versión 3.0; TLS 1.0 es "SSL 3.1". Las versiones de TLS definidas actualmente son TLS 1.1 y 1.2. Cada nueva versión añade algunas características y modifica algunos detalles internos. A veces decimos "SSL/TLS".

HTTPS es HTTP-dentro-de-SSL/TLS. SSL (TLS) establece un túnel seguro y bidireccional para datos binarios arbitrarios entre dos hosts. HTTP es un protocolo para enviar solicitudes y recibir respuestas, cada una de las cuales consiste en cabeceras detalladas y (posiblemente) algún contenido. HTTP está pensado para funcionar sobre un túnel bidireccional para datos binarios arbitrarios; cuando ese túnel es una conexión SSL/TLS, entonces el conjunto se llama "HTTPS".

Para explicar las siglas:

• "SSL" significa "Secure Sockets Layer". Fue acuñado por los inventores de las primeras versiones del protocolo, Netscape (la empresa fue comprada posteriormente por AOL).
• "TLS]1" significa "Transport Layer Security". El nombre se cambió para evitar cualquier problema legal con Netscape y para que el protocolo pudiera ser "abierto y libre" (y publicado como RFC). También insinúa la idea de que el protocolo funciona sobre cualquier flujo bidireccional de bytes, no sólo sobre los sockets basados en Internet.
• HTTPS]3" se supone que significa "HyperText Transfer Protocol Secure", lo cual es gramaticalmente incorrecto. Nadie, excepto los pedantes terminalmente aburridos, utiliza nunca la traducción; "HTTPS" es mejor pensar en "HTTP con una S que significa SSL". Otros acrónimos de protocolos se han construido de la misma manera, por ejemplo, SMTPS, IMAPS, FTPS... siendo todos ellos un protocolo desnudo que "se aseguró" al ejecutarlo dentro de algún SSL/TLS.

SSL y TLS son protocolos cuyo objetivo es proporcionar privacidad e integridad de los datos entre dos partes (véase RFC 2246), diseñados para ejecutarse sobre un protocolo de comunicación fiable (normalmente TCP). Aunque la especificación de TLS no habla de sockets, el diseño de SSL/TLS se hizo para que las aplicaciones pudieran utilizarlos casi como los sockets TCP tradicionales, por ejemplo SSLSocket en Java extiende Socket (aunque hay pequeñas diferencias en términos de usabilidad). HTTPS es HTTP sobre SSL/TLS, donde la conexión SSL/TLS se establece primero, y luego los datos HTTP normales se intercambian sobre esta conexión SSL/TLS. El uso de SSL o TLS depende de la configuración del navegador y del servidor (normalmente hay una opción para permitir SSLv2, SSLv3 o TLS 1.x). Los detalles de cómo HTTP y SSL/TLS forman HTTPS están en RFC 2818. En cuanto a la diferencia entre SSL y TLS, te pueden interesar estas dos respuestas que escribí para estas preguntas similares en StackOverflow y ServerFault:

• Diferencia entre SSL & TLS [Stackoverflow]
• ¿Cuáles son las diferencias exactas a nivel de protocolo entre SSL y TLS? [Serverfault]

  Podrías considerar TLSv1.0 como SSLv3.1 (de hecho eso'es lo que ocurre dentro de los registros intercambiados). Simplemente es más fácil comparar el TLSv1.0 con TLSv1.1 y TLSv1.2 porque todos han sido editados dentro del IETF y siguen más o menos la misma estructura. SSLv3 ha sido editado por una institución diferente (Netscape), hace que sea un poco más difícil detectar las diferencias.

  Aquí hay algunas diferencias, pero dudo que pueda enumerarlas todas:

  • En el mensaje ClientHello (primer mensaje enviado por el cliente, para iniciar el handshake), la versión es {3,0} para SSLv3, {3,1} para TLSv1.0 y {3,2} para TLSv1.1.
  • El ClientKeyExchange difiere.
  • La MAC/HMAC difiere (TLS utiliza HMAC mientras que SSL utiliza una versión anterior de HMAC). La derivación de la clave es diferente. El cliente puede enviar los datos de la aplicación directamente después de enviar el mensaje SSL/TLS Finished en SSLv3. En TLSv1, debe esperar a que el servidor envíe el mensaje Finished.
  • La lista de suites de cifrado difiere (y algunas de ellas han sido renombradas de SSL* a TLS*, manteniendo el mismo número de identificación).
  • También hay diferencias en cuanto a la nueva extensión de renegociación. Generalmente, cuanto más alta es la versión o SSL/TLS, más seguro es, siempre y cuando elijas bien tus suites de cifrado también (las versiones más altas de TLS también ofrecen el uso de suites de cifrado que se consideran mejores). (SSLv2 se considera inseguro.) Además, SSL no entra en el ámbito del IETF. Por ejemplo, la corrección de la renegociación de TLS tuvo que adaptarse a SSLv3 (aunque las pilas de SSL/TLS tuvieron que actualizarse de todos modos). También puede interesarle esta respuesta:

• ¿Qué sucede en el cable cuando se establece una conexión TLS / LDAP o TLS / HTTP?[Stackoverflow] Tenga en cuenta que algunas personas se oponen a SSL y TLS como la diferencia entre "SSL/TLS en la conexión" y "actualizar a TLS" (después de alguna conversación utilizando el protocolo de aplicación). A pesar de que algunas de estas respuestas son relativamente muy votadas, esto es incorrecto. Este error se propaga por el hecho de que ciertas aplicaciones, como Microsoft Outlook, ofrecen dos opciones de configuración llamadas "SSL" y "TLS" para la configuración de SMTP/IMAP cuando realmente quieren decir "SSL/TLS al conectar" y "actualizar a TLS". (Lo mismo ocurre con la biblioteca JavaMail, creo). Los RFCs que hablan de STARTTLS fueron escritos cuando TLS ya era un RFC oficial, por eso sólo hablan de actualizar la conexión a TLS. En la práctica, si usted modifica la configuración de su cliente de correo para forzarlo a usar SSLv3 en lugar de TLS (no es algo que yo recomendaría en general), es probable que pueda actualizar a SSL/TLS usando STARTTLS con una conexión SSLv3, simplemente porque se trata más del modo de operación que de la versión de SSL/TLS y/o de los conjuntos de cifrado. También existe una variante de HTTP en la que la actualización a SSL/TLS se realiza dentro del protocolo HTTP (similar a STARTTLS en LDAP/SMTP). Esto se describe en RFC 2817. Hasta donde yo sé, esto casi nunca se utiliza (y no es lo que utiliza https:// en los navegadores). La parte más relevante de este RFC es la sección sobre CONNECT para los servidores proxy HTTP (esto es usado por los servidores proxy HTTP para retransmitir las conexiones HTTPS).

SSL VS TLS

Los términos SSL y TLS se utilizan a menudo indistintamente o junto con el otro (TLS/SSL), pero uno es de hecho el predecesor del otro - SSL 3.0 sirvió de base para TLS 1.0 que, como resultado, a veces se denomina SSL 3.1.

¿Qué es más seguro, SSL o TLS?

En términos de seguridad, ambos se consideran igual de seguros

La principal diferencia es que, mientras que las conexiones SSL comienzan con seguridad y pasan directamente a las comunicaciones seguras, las conexiones TLS comienzan primero con un "hola" inseguro al servidor y sólo pasan a las comunicaciones seguras después de que el handshake entre el cliente y el servidor sea exitoso. Si el handshake TLS falla por cualquier razón, la conexión nunca se crea.

(SSL y TLS frente a HTTP)

El protocolo HTTP se utiliza para solicitar y recibir los datos y https en el que el 's' no es más que SSL seguro que hace que la solicitud del protocolo http y recibir la actividad cifrada por lo que ningún atacante hombre medio puede obtener los datos fácilmente.

Si no se utiliza ni SSL ni TLS con HTTP

entonces su conexión con el servidor web es sin cifrar todos los datos serán enviados en texto plano cualquier atacante hombre medio puede obtener y ver que los datos.

por lo que debe ir con SSL o TLS

Bueno, ambos son iguales, pero TLS es más extensible y la esperanza de obtener más apoyo en el futuro y TLS es compatible con versiones anteriores.