UNIVERSIDAD FRANCISCO GAVIDIAUNIVERSIDAD FRANCISCO GAVIDIA

FACULTAD DE INGENIERIA Y SISTEMASFACULTAD DE INGENIERIA Y SISTEMAS

TEMA:

INPLEMENTACION DE PROTOCOLO SSL, TLS, SSH

MATERIA: CRIPTOGRAFÍA Y SEGURIDAD DE REDES

CATEDRATICO: ING. ROBERTO MEJIA.

ALUMNOS: CARNET:

VAQUERO, DANIEL ENRIQUE VV100894

PARADA TORRES, ABNER JOEL TB100511

CHÁVEZ, GILBERTO NICOLÁS CC102005

VIDES ORELLANA, BRYAN STEVEN VO100310

SAN SALVADOR, 7 DE JUNIO DE 2014

1

INDICEINTRODUCCION..................................................................................................................................3

OBJETIVOS GENERAL..........................................................................................................................4

Objetivos Específicos..........................................................................................................................4

Marco Teórico....................................................................................................................................5

Protocolo SSL.....................................................................................................................................5

¿Qué es SSL?......................................................................................................................................5

¿Cómo funciona el SSL?.....................................................................................................................5

Funcionamiento general de SSL.........................................................................................................6

SSL - Una breve historia......................................................................................................................8

SSL y Consumidores...........................................................................................................................8

DESCRIPCIÓN DEL PROTOCOLO TLS.................................................................................................10

PROTOCOLO TLS...............................................................................................................................10

FUNCIONAMIENTO DEL PROTOCOLO TLS........................................................................................10

APLICACIONES DEL PROTOCOLO TLS................................................................................................11

MEDIAS DE SEGURIDAD DEL PROTOCOLO TLS.................................................................................12

APLICATIVOS....................................................................................................................................13

Protocolo SSH...................................................................................................................................14

¿Por qué usar SSH?..........................................................................................................................15

Matriz de comparación:...................................................................................................................15

CONCLUSION....................................................................................................................................17

ANEXOS............................................................................................................................................18

Anexo SSL1.......................................................................................................................................19

Anexo SSL2.......................................................................................................................................21

Anexo SSL3.......................................................................................................................................22

Anexo SSL4.......................................................................................................................................23

Protección contra falla sistémica.....................................................................................................25

VERSIONAMIENTO DEL PROTOCOLO TLS.........................................................................................25

Bibliografía.......................................................................................................................................27

2

INTRODUCCION

En la actualidad se encuentran una diversidad de protocolos los cuales pueden trabajar en diferentes capas, los cuales cumples las diferentes funciones para lo que han sido creados. Hoy hablaremos de tres protocolos de los muchos que existen , entre los tres que nos compete es SSL (Secure Sockets Layer ) que traducido podemos decir “ Capa de Conexión Segura” . Este protocolo fue diseñado para que en la transmisión de diversa información pueda viajar de manera segura utilizando maneras de cifrado y descifrado, de esta manera se percibe por SSL que nos proporcione autenticación y privacidad al momento de conectarnos con el servidor. Durante la primera fase, el cliente y el servidor negocian qué algoritmos criptográficos se van a usar, asi también una serie de fases básicas para la comunicación entre ambos.

Asi también se encuentra el protocolo SSH (Secure Shell) el cual nos facilita las comunicaciones seguras entre sistemas utilizando una arquitectura cliente/servidor que nos permite como usuarios conectarnos remotamente, esta forma de seguridad hace que sea casi imposible que alguien pueda obtener contraseñas no encriptados, ssh desplaza a los antiguos protocolos de conexión remota ya que mucho de ellos no posee una forma de encriptar contraseñas entre los clientes y los servidores. Entre una de las características de SSH podemos mencionar que el cliente tiene la posibilidad de reenviar aplicaciones X11  desde el servidor. Esta técnica, llamada reenvío por X11, proporciona un medio seguro para usar aplicaciones gráficas sobre una red. El protocolo TLS (Transport Layer Security) es una evolución del protocolo SSL (Secure Sockets Layer), es un protocolo en el cual se establece una conexión segura por medio de un canal cifrado entre el cliente y servidor. Así el intercambio de información se realiza en un entorno seguro y libre de ataques.

Normalmente el servidor es el único que es autenticado, garantizando así su identidad, pero el cliente se mantiene sin autenticar, ya que para la autenticación mútua se necesita una infraestructura de claves públicas (o PKI) para los clientes.

Estos protocolos permiten prevenir escuchas (eavesdropping), evitar la falsificación de la identidad del remitente y mantener la integridad del mensaje en una aplicación cliente-servidor.

3

OBJETIVOS GENERAL

Dar a conocer a conocer los protocolos SSL, TLS, SSH y su implementación, dando a conocer su forma de ayudarnos en la seguridad, tecnología, características y beneficios puedan brindar a los usuarios de las diferentes redes.

Objetivos Específicos

Implementación de los protocolos SSL, TLS y SSH.

Brindar la información de sus características y el por que utilizarlas.

4

Marco Teórico

Protocolo SSL

¿Qué es SSL?

SSL significa "Secure Sockets Layer". SSL Definición, Secure Sockets Layer (en español capa de conexión segura) 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.

SSL proporciona autenticación y privacidad de la información entre extremos sobre Internet mediante el uso de criptografía. Habitualmente, sólo el servidor es autenticado (es decir, se garantiza su identidad) mientras que el cliente se mantiene sin autenticar.

SSL implica una serie de fases básicas:

Negociar entre las partes el algoritmo que se usará en la comunicación

Intercambio de claves públicas y autenticación basada en certificados digitales

Cifrado del tráfico basado en cifrado simétrico

Durante la primera fase, el cliente y el servidor negocian qué algoritmos criptográficos se van a usar. Las implementaciones actuales proporcionan las siguientes opciones: Para criptografía de clave pública: RSA, Diffie-Hellman, DSA (Digital Signature Algorithm) o Fortezza.

Para cifrado simétrico: RC2, RC4, IDEA (International Data Encryption Algorithm), DES (Data Encryption Standard), Triple DES y AES (Advanced Encryption Standard).

Con funciones hash: MD5 o de la familia SHA.

El cifrado protege los datos durante la transmisión

5

Los servidores y los navegadores web confían en el protocolo Secure Sockets Layer (SSL) para ayudar a los usuarios a proteger sus datos durante la transferencia mediante la creación

de un canal cifrado para comunicaciones privadas por medio de Internet pública. Cada

certificado SSL consta de un par de claves y de información de identificación verificada. Cuando un navegador web (o cliente) señala un sitio web seguro, el servidor comparte su clave pública con el cliente para establecer un método de cifrado y una clave de sesión única. El cliente confirma que reconoce al emisor del certificado SSL y que confía en él. Este proceso se conoce como el "protocolo de enlace de SSL" y da comienzo a una sesión segura que protege la privacidad y la integridad de los mensajes.

El cifrado seguro de 128 bits puede calcular 288 veces más combinaciones que el cifrado de

40 bits. Esto significa que es un billón de veces más seguro.A las velocidades informáticas actuales, un hacker con tiempo, herramientas y motivación para atacar utilizando la fuerza bruta necesitaría un billón de años para ingresar ilegalmente en una sesión protegida por un certificado habilitado para SGC: A fin de habilitar cifrado seguro para la mayoría de los visitantes del sitio, elija un certificado SSL que permita un cifrado mínimo de 128 bits para el 99,9% de los visitantes del sitio web.

Funcionamiento general de SSL.

SSL funciona de forma transparente para ti, lo que en realidad ocurre cuando intentas acceder a un sitio seguro se asemeja al siguiente diagrama.

6

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 40 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 2128 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.) 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 no se detienen allí, sin embargo. Los certificados SSL también son compatibles con el nuevo estándar de RSA 2048-bit de encriptación.

SSL y Consumidores

Navegadores automáticamente notificar a los usuarios cuando las conexiones son seguras. Su potencial de clientes de comercio electrónico se utiliza para asegurar las compras, y no va a

enviar su información privada si se encuentran con Problemas de SSL

Sin el cifrado SSL, la mayor parte de sus clientes simplemente comprar en otro lado. Usted no

puede ofrecer una autenticación segura a sus clientes sin una Certificado SSL.

Problemas SSL

Para los usuarios de Web General y los administradores del sitio

Los usuarios en general Web con problemas de certificados SSL

Los certificados digitales proporcionan seguridad a los sitios web mediante la encriptación de datos sensibles y verfying la identidad de los sitios web que están protegidos.

Ofrecemos estos certificados como un servicio a propietarios de sitios web para garantizar la seguridad de las comunicaciones en línea.

Mensajes SSL problema y las advertencias se exhiben en un intento de proteger a los usuarios web de posibles situaciones comprometedoras. Sin embargo, un mensaje de error SSL también puede indicar un problema que es totalmente inocuo en la naturaleza. En este segundo caso, existe a menudo un problema, ya sea con el sitio web que se está conectando, o incluso, posiblemente, una mala configuración de su propio fin.

7

Si alguna vez encuentra un aviso relacionado con SSL (como un seguridad desajuste certificado (Ver Anexo SSL1), Certificado no seguro (Ver Anexo SSL2) o elementos de seguridad y no seguros (Ver Anexo SSL3), (Ver más abajo), es posible que desee mantener a raya al entrar sus datos de acceso o tarjeta de crédito hasta que pueda asegurarse de que no se encuentran en una situación en línea comprometer.

Proteger contra el fraude SSL (Ver Anexo SSL4),

Para resolver un problema que usted pueda tener, lo primero que desea es comprobar que la hora del equipo y la fecha sean exactas. Porque esto en la máquina podría provocar errores de seguridad en muchos sitios seguros de que usted tenga acceso.

Además, si usted recientemente ha permitido a la nueva configuración de seguridad en un sitio web, pruebe a desactivar los ajustes y ver si los mensajes de advertencia desaparecer. Si bien esto no es fijo, se le puede dar un punto a trabajar a partir de la comunicación con el titular del sitio web para ayudarles a saber cómo solucionar los problemas.

Una de las mejores cosas que puede hacer si usted encuentra un error es encontrar una fuente de terceros para un número de teléfono de la organización cuya página web se encuentra y tratar de llamar a la organización para hacerles saber sobre el tema.

Si usted tiene un problema con el sitio web de una gran empresa que puede ser difícil de alcanzar por teléfono, asegúrese de que el ejercicio de la discreción y no introduzca información personal en un sitio web que lanza un mensaje de error SSL.

8

DESCRIPCIÓN DEL PROTOCOLO TLS

El protocolo SSL/TSL se basa en tres fases básicas:

Negociación: Los dos extremos de la comunicación (cliente y servidor) negocian que algoritmos criptográficos utilizarán para autenticarse y cifrar la información. Actualmente existen diferentes opciones:

Autenticación y Claves: Los extremos se autentican mediante certificados digitales e intercambian las claves para el cifrado, según la negociación.

Transmisión Segura: los extremos pueden iniciar el tráfico de información cifrada y autentica.

PROTOCOLO TLS

Alguno de los objetivos que posee TLS son:

Seguridad criptográfica. El protocolo se debe emplear para establecer una conexión segura entre dos partes.

Interoperabilidad. Aplicaciones distintas deben poder intercambiar parámetros criptográficos sin necesidad de que ninguna de las dos conozca el código de la otra.

Extensibilidad. El protocolo permite la incorporación de nuevos algoritmos criptográficos.

Eficiencia. Los algoritmos criptográficos son costosos computacionalmente, por lo que el protocolo incluye un esquema de cache de sesiones para reducir el número de sesiones que deben inicializarse desde cero (usando criptografía de clave pública).

FUNCIONAMIENTO DEL PROTOCOLO TLS

El protocolo está dividido en dos niveles:

Protocolo de registro TLS (TLS Record Protocol).

Protocolo de mutuo acuerdo TLS (TLS Handshake Protocol).

El de más bajo nivel es el Protocolo de Registro, que se implementa sobre un protocolo de transporte fiable como el TCP. El protocolo proporciona seguridad en la conexión con dos propiedades fundamentales:

La conexión es privada. Para encriptar los datos se usan algoritmos de cifrado simétrico. Las claves se generan para cada conexión y se basan en un secreto negociado por otro protocolo (como el de mutuo acuerdo). El protocolo también se puede usar sin encriptación.

La conexión es fiable. El transporte de mensajes incluye una verificación de integridad.

9

El Protocolo de mutuo acuerdo, proporciona seguridad en la conexión con tres propiedades básicas:

La identidad del interlocutor puede ser autentificada usando criptografía de clave pública. Esta autentificación puede ser opcional, pero generalmente es necesaria al menos para uno de los interlocutores.

La negociación de un secreto compartido es segura.

La negociación es fiable, nadie puede modificar la negociación sin ser detectado por los interlocutores.

Esquema de operación del protocolo de mutuo acuerdo (TLS Handshake Protocol)

10

APLICACIONES DEL PROTOCOLO TLS

El protocolo SSL/TLS tiene multitud de aplicaciones en uso actualmente. La mayoría de ellas son versiones seguras de programas que emplean protocolos que no lo son. Hay versiones seguras de servidores y clientes de protocolos como el http, nntp, ldap, imap, pop3, etc.

El protocolo SSL/TLS se ejecuta en una capa entre los protocolos de aplicación como:

HTTP sobre SSL/TLS es HTTPS, ofreciendo seguridad a páginas WWW para aplicaciones de comercio electronic, utilizando certificados de clave pública para verificar la identidad de los extremos. Visa, MasterCard, American Express y muchas de las principales instituciones financieras han aprobado SSL para el comercio sobre Internet.

SSH utiliza SSL/TLS por debajo.

SMTP y NNTP pueden operar también de manera segura sobre SSL/TLS.

POP3 i IMAP4 sobre SSL/TLS son POP3S i IMAPS.

Existen múltiples productos clientes y servidores que pueden proporcionar SSL de forma nativa, pero también existen muchos que aún no lo permiten. una solución podría ser usar una aplicación SSL independiente como Stunnel para conseguir el cifrado, pero IETF recomendó en 1997 que los protocolos de aplicación ofrecieran una forma de actualizar a TLS a partir de una conexión sin cifrado (plaintext) en vez de usar un puerto diferente para cifrar las comunicaciones, evitando el uso de envolturas (wrappers) como Stunnel.

SSL también puede ser usado para tunelar una red completa y crear una red privada virtual (VPN), como en el caso de OpenVPN.

Implementaciones del Protocolo TLS

Existen diferentes implementaciones, como por ejemplo:

OpenSSL: es una implementación de código abierto, la más utilizada. Es un proyecto desarrollado por la comunidad Open Source para libre descarga y está basado en SSLeay, que ayuda al sistema a implementar el SSL/TLS ofreciéndole un robusto paquete de herramientas de administración y librerías de criptografía que pueden ser usadas para OpenSSH y navegadores web (acceso seguro a HTTPS).

GnuTLS: es una implementación de código abierto con licencia compatible con GPL.

Estandares y Definiciones RFC del Protocolo TLS

La primera definición de TLS apareció en el RFC 2246: "The TLS Protocol Version 1.0" (El protocolo TLS versión 1.0) y está basada en la versión 3.0 de SSL, siendo prácticamente equivalentes.

11

MEDIAS DE SEGURIDAD DEL PROTOCOLO TLS

Numera todos los registros y usa el número de secuencia en MAC.

Usa un resumen de mensaje mejorado con una clave (de forma que solo con dicha clave se pueda comprobar el MAC).

Protección contra varios ataques conocidos (incluyendo ataques man-in-the-middle), como los que implican un degradado del protocolo a versiones previas (por tanto, menos seguras), o conjuntos de cifrados más débiles.

El mensaje que finaliza el protocolo handshake (Finished) envía un hash de todos los datos intercambiados y vistos por ambas partes.

La función pseudo aleatoria divide los datos de entrada en 2 mitades y las procesa con algoritmos hash diferentes (MD5 y SHA), después realiza sobre ellos una operación XOR. De esta forma se protege a sí mismo de la eventualidad de que alguno de estos algoritmos se tornen vulnerables en el futuro.

APLICATIVOS

Para el funcionamiento del protocolo TLS / SSL, a continuación se determinara el aplicativo, para configurar el protocolo de seguridad en servidores Windows, Linux y mediante software; permitiendo crear certificados por el lado del servidor y cliente, realizando una conexión segura en la web.

Sistema Operativo Windows

El Terminal Server utiliza cifrado RDP nativo y no autentica el servidor, para utilizar el protocolo TLS en la autenticación de servidores y el cifrado de las comunicaciones, es preciso configurar correctamente el cliente y el servidor.

Deben ejecutarse en Windows Server 2003 con SP1.

Es preciso obtener un certificado para el servidor Terminal Server.

12

Protocolo SSH

SSH™ (o Secure SHell) es un protocolo que facilita las comunicaciones seguras entre dos sistemas usando una arquitectura cliente/servidor y que permite a los usuarios conectarse a un host remotamente. A diferencia de otros protocolos de comunicación remota tales como FTP o Telnet, SSH encripta la sesión de conexión, haciendo imposible que alguien pueda obtener contraseñas no encriptadas.

SSH está diseñado para reemplazar los métodos más viejos y menos seguros para registrarse remotamente en otro sistema a través de la shell de comando, tales como telneto rsh. Un programa relacionado, el scp, reemplaza otros programas diseñados para copiar archivos entre hosts como rcp. Ya que estas aplicaciones antiguas no encriptan contraseñas entre el cliente y el servidor, evite usarlas mientras le sea posible. El uso de métodos seguros para registrarse remotamente a otros sistemas reduce los riesgos de seguridad tanto para el sistema cliente como para el sistema remoto.

Características de SSH

El protocolo SSH proporciona los siguientes tipos de protección:

Después de la conexión inicial, el cliente puede verificar que se está conectando al mismo servidor al que se conectó anteriormente.

El cliente transmite su información de autenticación al servidor usando una encriptación robusta de 128 bits.

Todos los datos enviados y recibidos durante la sesión se transfieren por medio de encriptación de 128 bits, lo cual los hacen extremamente difícil de descifrar y leer.

El cliente tiene la posibilidad de reenviar aplicaciones X11  desde el servidor. Esta técnica, llamada reenvío por X11, proporciona un medio seguro para usar aplicaciones gráficas sobre una red.

Ya que el protocolo SSH encripta todo lo que envía y recibe, se puede usar para asegurar protocolos inseguros. El servidor SSH puede convertirse en un conducto para convertir en seguros los protocolos inseguros mediante el uso de una técnica llamada reenvío por puerto, como por ejemplo POP, incrementando la seguridad del sistema en general y de los datos.

Red Hat Enterprise Linux contiene el paquete general de OpenSSH (openssh) así como también los paquetes del servidor OpenSSH (openssh-server) y del cliente (openssh-clients). Consulte el capítulo titulado OpenSSH en el Manual de administración del sistema de Red Hat Enterprise Linux para obtener instrucciones sobre la instalación y el desarrollo de OpenSSH. Observe que los paquetes OpenSSH requieren el paquete OpenSSL (openssl). OpenSSL instala varias bibliotecas criptográficas importantes, permitiendo que OpenSSH pueda proporcionar comunicaciones encriptadas.

13

¿Por qué usar SSH?

Los usuario nefarios tienen a su disposición una variedad de herramientas que les permiten interceptar y redirigir el tráfico de la red para ganar acceso al sistema. En términos generales, estas amenazas se pueden catalogar del siguiente modo:

Intercepción de la comunicación entre dos sistemas — En este escenario, existe un tercero en algún lugar de la red entre entidades en comunicación que hace una copia de la información que pasa entre ellas. La parte interceptora puede interceptar y conservar la información, o puede modificar la información y luego enviarla al recipiente al cual estaba destinada.

Este ataque se puede montar a través del uso de un paquete sniffer — una utilidad de red muy común.

Personificación de un determinado host — Con esta estrategia, un sistema interceptor finge ser el recipiente a quien está destinado un mensaje. Si funciona la estrategia, el sistema del usuario no se da cuenta del engaño y continúa la comunicación con el host incorrecto.

Esto se produce con técnicas como el envenenamiento del DNS [2] o spoofing de IP (engaño de direcciones IP) [3].

Ambas técnicas interceptan información potencialmente confidencial y si esta intercepción se realiza con propósitos hostiles, el resultado puede ser catastrófico.

Si se utiliza SSH para inicios de sesión de shell remota y para copiar archivos, se pueden disminuir estas amenazas a la seguridad notablemente. Esto es porque el cliente SSH y el servidor usan firmas digitales para verificar su identidad. Adicionalmente, toda la comunicación entre los sistemas cliente y servidor es encriptada. No servirán de nada los intentos de falsificar la identidad de cualquiera de los dos lados de la comunicación ya que cada paquete está cifrado por medio de una llave conocida sólo por el sistema local y el remoto.

14

Matriz de comparación:

SSH:

• Autenticación de servidor obligatoria

• Autenticación del cliente: muchas opciones

• Autenticación basada en claves SSH

• Proporciona una lógica de multiplexación del canal de datos

SSL / TLS:

• La autenticación del servidor es opcional (aunque por lo general elegido)

• La autenticación del cliente: sólo claves públicas

• Autenticación basada en certificados X.509

• No proporciona lógica de multiplexación del canal de datos

SSL SSH

+-------------+ +-----------------+

| Nothing | | RFC4254 | multiplexación de conexión

+-------------+ +-----------------+

| Nothing | | RFC4252 | La autenticación de usuarios

+-------------+ +-----------------+

| RFC5246 | | RFC4253 | Transporte de datos cifrados

+-------------+ +-----------------+

SSL y SSH ambos proporcionan los elementos criptográficos para construir un túnel para el transporte de datos confidenciales con integridad comprobada. Por esa parte, utilizan técnicas similares, y pueden sufrir el mismo tipo de ataques, por lo que debe dar seguridad similar (es decir, una buena seguridad) suponiendo que ambos son adecuadamente implementadas. Que tanto existir es una especie de NIH síndrome: los desarrolladores SSH deberían haber reutilizado SSL para la parte del túnel (el protocolo SSL es lo suficientemente flexible como para dar cabida a muchas variaciones, incluyendo no usar certificados).

15

Se diferencian en las cosas que están alrededor del túnel. SSL utiliza tradicionalmente certificados X.509 para el anuncio de las claves públicas de servidor y cliente; SSH tiene su propio formato. También, SSH viene con un conjunto de protocolos para lo que sucede en el interior del túnel (multiplexación varias transferencias, realizar la autenticación basada en contraseñas dentro del túnel, gestión de terminales ...), mientras que no hay tal cosa en SSL, o, más exactamente, cuando estas cosas se utilizan en SSL no son considerados como parte de SSL (por ejemplo, cuando se realiza la autenticación HTTP basado en contraseña en un túnel SSL, se dice que es parte de "HTTPS", pero realmente funciona de una forma similar a lo que sucede con SSH).

Conceptualmente, se puede tomar SSH y vuelva a colocar la parte del túnel con la de SSL. También puede tomar HTTPS y reemplazar la cosa SSL con SSH-con-data-transporte y un gancho para extraer la clave pública del servidor de su certificado. No existe una imposibilidad científica y, si se hace correctamente, la seguridad seguirá siendo la misma. Sin embargo, no existe un conjunto generalizado de convenciones o las herramientas existentes para ello.

16

CONCLUSION

De acuerdo a la investigación que se realizo sobre los tres protocolos antes mencionados (SSL.TSL,SSH) Podríamos concluir que no existe el mejor protocolo ya que todos ellos posee ventajas y sus respectivas desventajas. Con el fin de cual de ellos utilizar se necesita entender cada uno de ellos y conocer la estructura que desees proteger basándonos en la información de la compañía que nos encontramos. Una vez que podamos entender estos conceptos sabremos con del estos protocolos será el conveniente para nuestra demanda de seguridad y para los diferentes usuarios.

El protocolo TLS está basado en SSL y son muy similares en su forma de operar, encriptando la comunicación entre el servidor y cliente mediante el uso de algoritmos.

La seguridad es un aspecto fundamental para muchas aplicaciones cliente-servidor, siendo un ejemplo muy importante, por su gran proyección en los últimos tiempos, el negocio electrónico. Mediante el uso de SSL/TLS se ha conseguido aumentar el grado de seguridad en dichas conexiones cliente-servidor, teniendo presente que la idea de "seguridad total" es una utopía.

La aplicación y el uso del protocolo TLS junto con otras técnicas de encriptación como IPSec, cifrado RPC, etc, nos ayudan a mantener la confidencialidad e integridad de los datos durante la comunicación, protegiendo así datos confidenciales como números de tarjetas de crédito en las diferentes transacciones de comercio electrónico, envío de información privada, en una intranet o a través de Internet, de una organización, etc.

Aunque no hay que olvidar que los ataques pueden ser múltiples y cada vez más sofisticados, lo que obliga a una permanente investigación de mejora de los diferentes protocolos de seguridad, se puede decir que un uso correcto de estos protocolos nos proporciona hoy en día un nivel de seguridad "bastante aceptable".

No olvidemos que la seguridad que nos brinda SSH es una seguridad muy confiada entre el cliente y servidor al momento de poder hacer una solicitud independientemente de los dispositivos que podamos tener es por esa razón que nos mantiene con muchas atribuciones para la seguridad que podamos dar a nuestra información confidencial dentro de la empresa.

17

ANEXOS

Anexo SSL1

Error de Certificados Nombre de Desajustes

Errores de Seguridad del Certificado: no coinciden los nombres en el navegador web

“Hay un problema con el certificado de seguridad de este sitio web. El certificado de seguridad

de este sitio web no lo emitió una entidad emisora de certificados de confianza. ” Internet Explorer 6

“La dirección del sitio web no coincide con la dirección del certificado de seguridad.”  Internet Explorer 7 y después

“Esta conexión no está verificada”

[haga clic en Detalles Técnicos]El certificado solo es válido para (www.dominiodelcertificado.com)El certificado caduca el (fecha/de/caducción hh:mm).(Código de Error: ssl_error_bad_cert_domain)Mozilla Firefox

"Probablemente no sea el sitio que buscas."Has intentado acceder a (su.dominio.com), pero, en su lugar, has accedido a un servidor que se identifica como (otro.dominio.com). Esto se puede deber a una configuración incorrecta del servidor o a otra causa más grave. Es posible que un atacante en tu red esté intentando obligarte a visitar una versión falsa (y potencialmente peligrosa) de (su.dominio.com), por lo

que no debes continuar.“ Google Chrome

Esta advertencia se presenta con un navegador web para acceder a un sitio web que tiene un certificado de seguridad instalado (para el cifrado de datos) que se emitió a un dominio distinto al que se accede.

El nombre común para que se expida un certificado ssl (pj, www.ejemplo.com) debe coincidir exactamente con el nombre que aparece en la barra de url. Cualquier diferencia que hará que el navegador web para poner fin a la navegación y lanzar un error de coincidencia de nombre. Este error puede ocurrir incluso si el certificado correcto está instalado correctamente si se conecta a través de la dirección ip o un nombre interno cuando se expidió el certificado con el nombre de dominio completo (o viceversa).

18

También es posible que un certificado de firma se instalará en lugar de un certificado de seguridad específica del servidor emitido por una autoridad de certificación o que el nombre de dominio fue escrito mal / mal escrito en la solicitud.

Si su sitio web está garantizado por un certificado con el nombre www.ejemplo.com recibirá un error de nombre si se conecta mediante cualquiera de los siguientes nombres:

ejemplo.com

ejemplo.local

208.77.188.166

10.1.1.7

A pesar de que las direcciones, sobre todo, podría llegar a un sitio con un certificado válido, usted podría obtener un error de nombre si se conecta a un nombre que no sea el que se expidió el certificado.

19

Anexo SSL2 

Certificados SSL - Error Certificados No Confiado

Los errores de seguridad del certificado: certificado no es confiable en el Explorador Web

"Hay un problema con el certificado de seguridad de este sitio web. El certificado de seguridad de este sitio web no lo emitió una entidad emisora de certificados de confianza.      - Internet Explorer 6

"El certificado de seguridad del sitio web no procede de un origen de confianza."      - Internet Explorer 7 y después

"www.sudominio.com usa un certificado de seguridad no válido(código de error: sec_error_unknown_issuer)"      - Firefox

Esta advertencia se presenta en un navegador web trata de acceder a un sitio web que tiene un certificado de seguridad instalado (con SSL / TLS de cifrado de datos), que no puede ser verificada por el navegador web.

Los navegadores se programan con una lista de proveedores de certificados SSL/TLS de confianza. En algunos sitios el proveedor de certificados SSL no se puede encontrar en esa lista, y el navegador advierte de que la entidad emisora de tales certificados no es de confianza. En versiones anteriores de navegadores web como Internet Explorer esta advertencia era muy genérico, Firefox 3 también se debe distinguir entre un certificado expedido por el propio servidor (un "auto-firmado" certificado) y otros certificados emitidos por una organización de confianza.

SSL Certificados - Errores de Certificados de Seguridad

20

Anexo SSL3

SSL Certificados - Errores de Certificados de Seguridad

Errores de seguridad del certificado: Los productos seguros y no seguros

"Esta página contiene elementos seguros y no seguras. ¿Desea descargar los elementos no seguros?".      - Internet Explorer 6.7

Este error se produce en Internet Explorer cuando el contenido (p.ej., una imagen o Javascript) en un sitio web seguro que se carga a través de una conexión no segura. Al ver el código fuente de la página, usted se dará cuenta de que el contenido de la página se está

cargando a través src=http:// en lugar de src=https://.

Cuando los usuarios con Internet Explorer visitan a la página web que tiene contenido comunicado por un canal seguro y un canal no seguro recibirán la advertencia:"Esta página contiene elementos seguros y no seguros. ¿Desea mostrar los elementos no seguros?"

Usuarios de Firefox reciban esta advertencia cuando tratan de ver una página de contenido mixto."Ha solicitado una página cifrada que contiene alguna información sin cifrar. La información que vea o introduzca en esta página podría ser leída fácilmente por terceras personas."

Similarmente cuando personas utilizando el navegador Chrome tratan de ver una página de contenido mixto recibirán el siguiente mensaje si hacen clic en el icono de SSL (la imagen del candado)."Tu conexión a (sitio web) está cifrada con codificación de 128 bits. Sin Embargo, esta página incluye otros recursos que no son seguros. Las demás personas pueden ver estos recursos mientras se encuentran en tránsito, y un atacante puede modificarlos para cambiar el funcionamiento de la página."

Para resolver el problema, tendrá que reemplazar las referencias http en su sitio web para que

los objetos se cargan en lugar de a través de https (o en otras palabras cambiar src="http://..."

a decir src="https://...") Cualquier contenido que no se puede cargar de forma segura no se debe cargar a ese sitio web si usted no desea que los usuarios experimenten esta advertencia.

21

Anexo SSL4

Protéjase Contra los Certificados SSL Fraudulentos

¿Qué hacer para protegerse contra un ataque malintencionado de certificados SSL

¿Navegadores web, y los consumidores informados proteger contra el fraude SSL.

Los certificados SSL para proteger los usuarios de Internet de dos maneras. En primer lugar, SSL encripta la información sensible como nombres de usuario, contraseñas o números de tarjetas de crédito. Certificados de segunda, SSL verificar la identidad de los sitios web.

Si bien este segundo punto puede ocurrir en diferentes grados dependiendo de la compra de un certificado de administración web o el proveedor certificado que él o ella utiliza, todos los certificados SSL al menos confirmar que el sitio web que está en (por ejemplo, www.EjemploBanco.com) es en hecho www.EjemploBanco.com, a diferencia de un sitio Web

falso posando como www.EjemploBanco.com.

¿Qué es lo peor que podría pasar?

Al igual que con cualquier aspecto de la seguridad informática, siempre y cuando exista un fuerte incentivo (económico, político, etc) para tratar de jugar con el sistema, habrá jugadores maliciosos en el juego que a tratar de encontrar vulnerabilidades o agujeros en un lugar seguro del sistema.

Muchos de los posibles ataques en contra de un certificado SSL son insostenibles porque la tecnología de la piratería no ha alcanzado a la tecnología de seguridad (por ejemplo, un

intento de la fuerza bruta para "crack" un certificado SSL para tomar años), o son relativamente fáciles de proteger.

Los navegadores modernos web están configurados para detectar los problemas comunes de certificados y advertir a los usuarios antes de que siquiera se les permite pasar a un sitio web que tiene los problemas potenciales.

22

Con los problemas de seguridad SSL, al igual que muchos temas de la seguridad en línea, los usuarios actuando en contra de las advertencias, el uso de navegadores o sistemas operativos obsoletos, y actuando en contra de las mejores prácticas (por ejemplo, hacer clic en enlaces en correos electrónicos spam) son los principales problemas que el usuario aumentar vulnerabilidad.

Infracciones más cierto en el sistema, cuando se producen, se suelen resolver en un plazo pequeño a través de actualizaciones automáticas o parches ampliamente disponibles.

La ausencia total de confianza.

Muchos ataques de gama baja se pueden orientar a los consumidores y se basan en tácticas como la mala dirección (teniendo un usuario login.EjemploBanco.hidden-domain.com lugar de login.EjemploBanco.com). Sin embargo, hay un escenario desde el que no cuentan con seguridad integrada completamente disponibles pueden proteger a un consumidor - la falla de una pieza de confianza del sistema de autenticación.

La razón de un sistema de certificación basado en las obras es que se basa en autoridades de certificación para afirmar que cualquier persona que obtiene un certificado de EjemploBanco.com realmente posee EjemploBanco.com. Si un usuario malintencionado iba a

obtener un certificado auténtico de un sitio web, sería posible falsificar totalmente la

interacción en línea con tal perfección que los usuarios nunca se sabe que cada acción estaba siendo vigilado, controlado, catalogado, y posiblemente robados.

El ejemplo del banco parece obvia. Sin embargo, si tenemos en cuenta qué tipo de organización puede tener los recursos necesarios para introducirse en un entorno seguro y totalmente comprometer un sistema de emisión del certificado que es auditado regularmente por motivos de seguridad, los pensamientos se conviertan de típico robo de tarjetas de crédito y hacia un Estado-nación interesada en espiar a las actividades online de sus ciudadanos.

Sitios como Twitter, Facebook, Gmail, etc. parece más apto para los objetivos de este segundo tipo de atacante.

23

Protección contra falla sistémica.

Aunque a lo mejor de nuestro conocimiento de la situación descrita no ha ocurrido nunca a una autoridad de gran confianza de certificados (CA), las organizaciones menos seguros se han visto comprometidos en diversos grados.

Al menos en un caso de negligencia grave por parte de una CA, sus raíces fueron sacadas inmediatamente de todos los navegadores en el descubrimiento de la violación. Una CA sin raíces, en esencia, ya no es una CA. Cualquiera que acceda a un sitio "seguro" con sus

certificados a ver señales evidentes de advertencia, como en la imagen de arriba.

En cuanto a lo que un usuario puede hacer, lo más importante es siempre asegurarse de que las actualizaciones automáticas están activadas y manuales se realizan con regularidad para asegurarse de que se ponga al día el sistema operativo y software de navegación puede ayudar a proteger de cualquier ataque que se han detectado.

Aprenda a reconocer los signos visuales de confianza relacionadas con los certificados SSL,

tales como el icono del candado SSL y la EV barra de confianza verde.

Los administradores de sistemas pueden ayudar a proteger a sus usuarios mediante la implementación de estándares avanzados de seguridad SSL, tales como los certificados SSL con EV, y el mantenimiento de software de servidor de hasta la fecha.

VERSIONAMIENTO DEL PROTOCOLO TLS

RFC 2712: Aparecen las familias de cifrados de 40 bits definidas, para advertir que ya han sido asignadas.

RFC 2817: Explica cómo usar el mecanismo de actualización en HTTP/1.1 para iniciar TLS sobre una conexión TCP existente, permitiendo al tráfico seguro e inseguro HTTP compartir el mismo puerto.

RFC 2818: Diferencia el tráfico seguro e inseguro HTTP usando un puerto de servidor diferente.

RFC 3268: Añade la familia de cifrado AES.

RFC 3546: Añade un mecanismo para negociar extensiones de protocolos durante la inicialización de sesión y define algunas extensiones.

RFC 4279: Añade tres conjuntos de nuevas familias de cifrados para que el protocolo TLS permita la autenticación basada en claves previamente compartidas.

24

El protocolo TLS ha evolucionado desde la versión 1.0 hasta la actual versión que es la 1.1. Esta última versión es muy parecida a la versión anterior (TLS 1.0), pero la principal diferencia es la modificación del formato para cifrado RSA anterior al uso de 'master secret', que es parte del mensaje de intercambio de claves del cliente. En TLS 1.0 se usaba la versión 1.5 del estándar RSA para criptografía de clave pública (PCK#1), pasando a usar ahora la versión 2.1. Con este cambio se consigue protección ante ataques descubiertos por Daniel Bleichenbacher que podían lanzarse contra servidores TLS 1.0, usando PKCS#1 versión 1.5. También se incluyen recomendaciones para evitar ataques remotos programados. TLS 1.1 está actualmente implementado en el navegador Opera y en GnuTLS.

25

Bibliografía

http://www.digicert.com/es/

http://es.wikipedia.org

http://aprenderinternet.about.com

https://www.symantec.com/es/es/

http://revista.seguridad.unam.mx

http://technet.microsoft.com/es-es/library/cc759573.aspx

http://es.tech-faq.com/tls-transport-layer-security.shtml

http://www.wikilearning.com/articulo/protocolos_seguros_para_el_web

26