1. 1
UUNNIIVVEERRSSIIDDAADD FFRRAANNCCIISSCCOO GGAAVVIIDDIIAA
FFAACCUULLTTAADD DDEE IINNGGEENNIIEERRIIAA YY SSIISSTTEEMMAASS
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

2. 2
INDICE
INTRODUCCION................................................................................................................................... 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....................................................................................................................... 7
SSL y Consumidores............................................................................................................................. 7
DESCRIPCIÓN DEL PROTOCOLO TLS.................................................................................................... 9
PROTOCOLO TLS.................................................................................................................................. 9
FUNCIONAMIENTO DEL PROTOCOLO TLS........................................................................................... 9
APLICACIONES DEL PROTOCOLO TLS ................................................................................................ 11
MEDIAS DE SEGURIDAD DEL PROTOCOLO TLS.................................................................................. 12
APLICATIVOS...................................................................................................................................... 12
Protocolo SSH.................................................................................................................................... 13
¿Por qué usar SSH? ........................................................................................................................... 14
Matriz de comparación:.................................................................................................................... 15
CONCLUSION..................................................................................................................................... 17
ANEXOS ............................................................................................................................................. 18
Anexo SSL1 ........................................................................................................................................ 18
Anexo SSL2 ........................................................................................................................................ 20
Anexo SSL3 ........................................................................................................................................ 21
Anexo SSL4 ........................................................................................................................................ 22
Protección contra falla sistémica. ..................................................................................................... 24
VERSIONAMIENTO DEL PROTOCOLO TLS.......................................................................................... 24
Bibliografía ........................................................................................................................................ 26

3. 3
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.

4. 4
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.

5. 5
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

6. 6
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.

7. 7
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.

8. 8
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.

9. 9
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.
El Protocolo de mutuo acuerdo, proporciona seguridad en la conexión con tres propiedades
básicas:

10. 10
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)

11. 11
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.

12. 12
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.

13. 13
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.

14. 14
¿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.

15. 15
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).

16. 16
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.

17. 17
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.

18. 18
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).

19. 19
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.

20. 20
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

21. 21
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.

22. 22
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.

23. 23
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.

24. 24
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.

25. 25
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.

26. 26
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