miércoles, 4 de noviembre de 2015

SSL

Hola a todos hoy vamos a ver lo que es el protocolo SSL,  un poco de historia para saber desde cuando este este protocolo, cuáles son sus variantes, su funcionamiento y donde lo podemos aplicar.

¿Qué es SSL?
SSL significa "Secure Sockets Layer". SSL Definición, Secure Sockets Layer es un protocolo diseñado para permitir que las aplicaciones para transmitir información de ida y de manera segura hacia atrás. Las aplicaciones que utilizan el protocolo Secure Sockets Layer sí saben cómo dar y recibir claves de cifrado con otras aplicaciones, así como la manera de cifrar y descifrar los datos enviados entre los dos.

¿Cómo funciona el SSL? 
Algunas aplicaciones que están configurados para ejecutarse SSL incluyen navegadores web como Internet Explorer y Firefox, los programas de correo como Outlook, Mozilla Thunderbird, Mail.app de Apple, y SFTP (Secure File Transfer Protocol) programas, etc Estos programas son capaces de recibir de forma automática SSL conexiones.
Para establecer una conexión segura SSL, sin embargo, su aplicación debe tener una clave de cifrado que le asigna una autoridad de certificación en la forma de un Certificado. Una vez que haya una única clave de su cuenta, usted puede establecer una conexión segura utilizando el protocolo SSL.

Una breve historia
En los primeros días de la World Wide Web, claves de 40-bit de poco se usaron. Cada bit puede contener un uno o un cero - lo que significaba que eran dos claves diferentes disponibles. Eso es un poco más de un billón claves distintas.
Debido a la velocidad cada vez mayor de computadoras, se hizo evidente que una clave de 40 bits no era lo suficientemente seguro. Posiblemente, con los procesadores de gama alta que vendría en el futuro, los piratas informáticos podría llegar a probar todas las claves hasta encontrar el adecuado, lo que les permite descifrar y robar información privada. Que tomaría algún tiempo, pero era posible.
Las claves se alargaron a 128 bits. Eso es 2 claves, códigos de cifrado o 340.282.366.920.938.463.463.374.607.431.768.211.456 único. (Eso es 340000000000000 billones de billones, para aquellos de ustedes hacer el seguimiento en casa.) Se determinó que si las computadoras siguió avanzando en la velocidad como lo han hecho en el pasado, estos códigos de 128 bits que permanecen seguros durante por lo menos una década más, si no más. Certificados DigiCert no se detienen allí, sin embargo. Los certificados SSL DigiCert también son compatibles con el nuevo estándar de RSA 2048-bit de encriptación.

Versiones SLL

  • SSL 3.0

El protocolo SSL fue desarrollado originalmente por Netscape.6 La versión 1.0 nunca se entregó públicamente; la versión 2.0 se presentó en febrero de 1995 pero "contenía una cantidad de fallas de seguridad que al final llevaron al diseño de la versión SSL 3.0".7 Dicha versión, presentada en 1996, fue un rediseño completo del protocolo producido por Paul Kocher, quien trabajó con los ingenieros de Netscape Phil Karlton y Alan Freier. Las versiones más nuevas de SSL/TLS están basadas en SSL 3.0. El borrador de 1996 de SSL 3.0 fue publicado por la IETF como el histórico RFC 6101. En el mes de octubre de 2014, se generó una nueva vulnerabilidad sobre el protocolo SSL en su versión 3.0, Vulnerabilidad de Poodle.

  • TLS 1.0

TLS 1.0 fue definido en el RFC 2246 en enero de 1999 y es una actualización de SSL versión 3.0. Como dice el RFC, "las diferencias entre este protocolo y SSL 3.0 no son dramáticas, pero son significativas en impedir la interoperabilidad entre TLS 1.0 y SSL 3.0". TLS 1.0 incluye una forma en la cual la implementación puede conectarse en SSL 3.0, debilitando la seguridad.

  • TLS 1.1

TLS 1.1 fue definido en el RFC 4346 en abril de 2006.8 Es una actualización de TLS 1.0. Las diferencias más significativas incluyen:

  • Agrega protección contra ataques de CBC.
    • El vector de inicialización (IV) implícito fue reemplazado por un IV explícito.
    • Cambio en el manejo de los errores de relleno.
  • Soporte para el registro de parámetros de IANA

  • TLS 1.2

TLS 1.2 fue definido en el RFC 5246 en agosto del 2008. Se basa en una especificación posterior de TLS 1.1. Las mayores diferencias son:


  • la combinación MD5-SHA-1 en la función pseudoaleatoria (PRF) fue reemplazada por SHA-256, con la opción de usar PRFs especificados en la cipher-suite.
  • la combinación MD5-SHA-1 en el mensaje terminado fue reemplazada por SHA-256, sin la opción de usar algoritmos de hash específicos para la cipher-suite. Sin embargo, el tamaño del hash en el mensaje terminado es truncado a 96 bits.
  • la combinación MD5-SHA-1 en el elemento digitalmente firmado fue reemplazada por un hash simple negociado durante el handshake, que por defecto es SHA-1.
  • Mejoras en la habilidad de clientes y servidores para especificar que algoritmos de hash y de firma van a aceptar.
  • Expansión del soporte de cifras de cifrado autenticadas, usadas mayormente para modo Galois/Counter (GCM) y modo CCM del cifrado con Advanced Encryption Standard (o estándar de cifrado avanzado) (AES).
  • Se agregaron definición de Extensiones de TLS y de Ciphersuites de AES.

TLS 1.2 fue después redefinido en el RFC 6176 de marzo de 2011 redactando su retro compatibilidad con SSL y TLS para que dichas sesiones jamás negocien el uso de SSL versión 2.0.


  • TLS 1.3

Hasta mayo de 2015, TLS 1.3 es un borrador, y los detalles no se han fijado todavía.9 10 Se basa en la especificación anterior TLS 1.1 y 1.2. Las principales diferencias con TLS 1.2 incluyen:

  • Retiro de la hora GMT.
  • Fusiona soporte de ECC del RFC 4492 pero sin curvas explícitas.
  • Retira el campo de longitud innecesaria de la entrada de AD a cifras AEAD.
  • Cambiar el nombre de {Cliente, Servidor} KeyExchange a {Cliente, Servidor} KeyShare
  • Añade un HelloRetryRequest explícita para rechazar el del cliente
  • Apretón de manos revisado a fin de proporcionar el modo 1-RTT.
  • Retiro de grupos DHE personalizados.
  • Eliminado el soporte para la compresión.
  • Eliminado el soporte para el intercambio de claves RSA estática y DH.
  • Eliminado el soporte para sistemas de cifrado no AEAD.


Funcionamiento
El protocolo SSL intercambia registros; opcionalmente, cada registro puede ser comprimido, cifrado y empaquetado con un código de autenticación del mensaje (MAC). Cada registro tiene un campo de content_type que especifica el protocolo de nivel superior que se está usando.


¿En qué casos se debe usar un certificado SSL?
Independientemente de la información que se esté transmitiendo (por ejemplo, desde un formulario alojado en su página web hasta su servidor), debería contar con un certificado SSL, ya que estos certificados no sirven simplemente para proteger transacciones de tarjetas de crédito. Cualquier tipo de información personal es confidencial y debe protegerse. Ya se trate de suscripciones a boletines de noticias o accesos a cuentas, debería contarse como mínimo con un certificado SSL para proteger los datos recogidos y enviados.

  • Para proteger las transacciones online con tarjetas de crédito.
  • Para ofrecer protección online para los accesos al sistema, la información confidencial transmitida a través de formularios web o determinadas áreas protegidas de páginas web.
  • Para proteger el correo web y las aplicaciones como el acceso web a Outlook o los servidores Exchange y Office Communications.
  • Para proteger los procesos de trabajo y la virtualización de aplicaciones como plataformas Citrix Delivery o las plataformas de cloud computing.
  • Para proteger la conexión entre un cliente de correo como Microsoft Outlook y un servidor de correo como Microsoft Exchange.
  • Para proteger la transferencia de archivos sobre https y servicios de FTP, como podrían ser las actualizaciones de nuevas páginas por parte de un propietario de una página web o la transmisión de archivos pesados.
  • Para proteger los accesos y la actividad en paneles de control como Parallels o cPanel entre otros.
  • Para proteger el tráfico en una intranet como es el caso de las redes internas, la función compartir archivos, las extranets o las conexiones a bases de datos.
  • Para proteger los accesos a redes y cualquier otro tráfico de red con VPNs de SSL como podrían ser los servidores de acceso VPN o las aplicaciones como Citrix Access Gateway.


No hay comentarios:

Publicar un comentario