HTTPS y SSH

Juan Pablo Moreno Rico – 20111020059

Nicolás Steven Rivera Rincón - 20142020021
 Protocolo HTTPS

HTTPS es la combinación de HTTP y SSL para la implementación de una comunicación

segura entre un navegador Web y un servidor Web.

• La conexión HTTP utiliza el puerto 80. Si se

especifica HTTPS, se utiliza el puerto 443.

• HTTPS está documentado en el RFC 2818.

HTTPS: Protocolo seguro de transferencia de hipertexto.

SSL: Secure Sockets Layer / Capa de puertos seguros.
TLS: Transport Layer Security / Seguridad de la capa de transporte.
 ¿Que problema soluciona HTTPS?

Funcionamiento protocolo HTTP:

Normalmente, cuando navegamos
por internet lo hacemos utilizando
el protocolo HTTP, el cual establece
unas directrices acerca de cómo
se va a comunicar nuestro
ordenador (cliente) con un
servidor, en esta comunicación los
datos se transfieren sin ninguna
modificación.
 Como funciona HTTPS
Cuando se utiliza HTTPS, los siguientes elementos de la comunicación son cifrados:

• URL del documento

solicitado.
• Contenido del documento.
• El contenido de los
formularios de explorador.
• Las cookies enviadas desde
el navegador al servidor y
del servidor al navegador.
• Contenido de la cabecera
HTTP.
Inicio de la conexión ‘handshake’ (apretón
de manos)

• El cliente envía un mensaje

ClientHello especificando una lista
de conjunto de cifrados, métodos
de compresión y la versión del
protocolo.
• El cliente recibe un registro
denominado ServerHello, en el
que el servidor elige los
parámetros de conexión a partir
de las opciones ofertadas con
anterioridad por el cliente.
• Cuando los parámetros de la
conexión son conocidos, cliente y
servidor intercambian
certificados.

Descripción general del handshake en SSL o TLS.

Inicio de la conexión ‘handshake’ (apretón
de manos)

• Cliente y servidor negocian una

clave secreta de tipo (simétrica)
común llamada master secret, de
la cual todos los datos de claves
restantes son derivados.
• Para cerrar la comunicación se
requiere que tanto el cliente como
el servidor envíen una alerta de
tipo connection close, no recibir
de vuelta una alerta de cierre de
conexión puede ser evidencia de
una falla de seguridad por lo que
HTTPS debería emitir algún tipo de
advertencia de seguridad en la
comunicación.

Descripción general del handshake en SSL o TLS.

 Certificados HTTPS

La diferencia entre un certificado gratuito y de pago radica en el grado de verificación

antes de ser emitidos.

Certificado gratuito. Certificado de pago o verificación

extendida.
 SECURE SHELL (SSH)

• Es un protocolo para comunicaciones de red

seguras diseñado para ser relativamente
simple y barato de implementar, este facilita
las comunicaciones seguras entre dos
sistemas usando una arquitectura
cliente/servidor.

• Está diseñado para reemplazar los métodos más viejos y menos seguros de inicio
de sesión remoto tales como Telnet o Rsh ya que ha diferencia de estos SSH cifra
la sesión de conexión.
• SSH también puede utilizarse para funciones de red como la transferencia de
archivos, correo electrónico y tunneling.
 Grupo de protocolos SSH

SSH se divide en tres protocolos que normalmente

se ejecutan en la parte superior de TCP.

• Protocolo de autenticación de usuario:

autentica el usuario al servidor.
• Protocolo de conexión: multiplexa varios
canales de comunicaciones lógicas sobre una
sola conexión subyacente de SSH.
• Protocolo de Capa de Transporte: Proporciona
autenticación con el servidor, confidencialidad
e integridad de la información con forward
secrecy (si una clave es vulnerada no
compromete la seguridad de las claves usadas
con anterioridad, opcionalmente puede
brindar compresión.

Grupo de protocolos SSH

 Protocolo de Capa de Transporte
Llaves de Host

La autenticación del servidor se produce en la capa de transporte, el servidor

posee un par de claves pública/privada. Un servidor puede tener varias claves de
host simétricas cifradas con diferentes algoritmos. A su vez varios clientes pueden
compartir la clave de host.
En cualquier caso, la clave de host del servidor se utiliza durante el intercambio de
claves para autenticar la identidad del host. Para que esto sea posible, el cliente
debe tener inicialmente la clave pública de host del servidor. RFC 4251 define dos
alternativas que se pueden utilizar para este proceso:

1. El cliente puede tener una base de datos local que asocia cada nombre de
host (usuario) con la correspondiente clave pública de host. Este método no
requiere infraestructura administrativa de manera centralizada, pero resulta en
un proceso donde la base de datos de usuarios y claves puede ser muy difícil
de mantener.
 Protocolo de Capa de Transporte
2. La asociación name-to-key de host está certificada por una ‘autoridad de
certificación’ (CA). El cliente sólo conoce la clave raíz de CA y verifica la
validez de todas las claves de host por medio del CA. Esta alternativa facilita el
problema de mantenimiento, ya que una sola clave de CA debe estar
almacenada en el cliente. Por otra parte, cada clave de host debe estar
debidamente certificada antes de que sea posible la autorización.
Intercambio de paquetes en la capa de
transporte

En primer lugar, el cliente establece una

conexión TCP con el servidor. Esto se
realiza a través del protocolo TCP y no
forma parte del protocolo de la capa de
transporte. Una vez establecida la
conexión, la información se intercambia
como paquetes en el campo de
información de un segmento TCP.
Formato de los paquetes

• Packet length: Longitud del paquete en bytes, sin

incluir la longitud del paquete y campos MAC.
• Padding length: longitud del campo de relleno
aleatorio.
• Payload: contenido útil del paquete. Antes de la
negociación del algoritmo, esta campo está
descomprimido. Si la compresión se negocia,
entonces en los paquetes siguientes,
este campo se comprime.
• Random padding: Contiene bytes aleatorios de
relleno para que la longitud total del paquete sea
un múltiplo del tamaño del bloque de cifrado.
• Message authentication code (MAC): Si se ha
negociado, este campo contiene el valor MAC. El
valor MAC se calcula
sobre todo el paquete más un número de
secuencia.
Intercambio de paquetes en la capa de
transporte

Intercambio de cadenas de identificación:

Comienza con el cliente enviando un paquete
con una cadena de identificación del formulario:
SSH-protoversion-softwareversion SP comments CR
LF donde SP, CR y LF son caracteres de espacio,
retorno de carro y avance de línea,
respectivamente.

Un ejemplo de una cadena válida es:

SSH-2.0-billsSSH_3.6.3q3 <CR> <LF>

Los servidor responde con su propia cadena de

identificación. Estas cadenas se utilizan en el
intercambio de llaves.
Intercambio de paquetes en la capa de
transporte

Negociación del algoritmo:

Cada lado envía un archivo
SSH_MSG_KEXINIT que contiene listas de
algoritmos soportados en el orden de
preferencia para el remitente.
Los algoritmos incluyen intercambio de
claves, cifrado, algoritmo MAC y algoritmo de
compresión.
Intercambio de paquetes en la capa de
transporte

Intercambio de claves: La norma permite

métodos alternativos de intercambio de
claves, pero en la actualidad, sólo dos
versiones del intercambio de claves Diffie-
Hellman son especificados en el RFC 2409 y
requieren sólo un paquete en cada dirección
para completar el proceso.
Como resultado de estos pasos, las dos partes
comparten ahora una clave maestra K.
Además, el servidor ha sido autenticado en el
cliente, ya que el servidor ha utilizado su
clave para firmar su mitad del intercambio
Diffie-Hellman. Finalmente, el valor de hash H
sirve como un identificador de sesión para
esta conexión.
Intercambio de paquetes en la capa de
transporte

El final del intercambio de claves: esta

señalado por el intercambio de
SSH_MSG_NEWKEYS paquetes. En este punto,
ambas partes pueden empezar a usar las
claves generadas a partir dela clave maestra
K.
Solicitud de servicio: El cliente envía una
SSH_MSG_ SERVICE_REQUEST para solicitar la
autenticación de usuario o el protocolo de
conexión. Posteriormente, todos los datos se
intercambian como la carga útil de un
paquete de capa de transporte SSH,
protegido por cifrado y MAC.
 PROTOCOLO DE AUTENTICACIÓN DE USUARIO
Tipos de mensajes
 Byte SSH_MSG_USERAUTH_REQUEST (50)
 String nombre de usuario
 String nombre del servicio
 String nombre del método
 … campos específicos de acuerdo al método.

 Byte SSH_MSG_USERAUTH_FAILURE (51)

 Lista autenticaciones que pueden proceder
 Bool éxito parcial

 Byte SSH_MSG_USERAUTH_SUCCESS (52).

Intercambio de mensajes de
autenticación
Métodos de autenticación

Public
key Password Host based
Protocolo de conexión
Canales de comunicación

 Byte SSH_MSG_CHANNEL_OPEN
 Stringtipo de canal
 Uint32 canal emisor
 Uint32 tamaño inicial de ventana
 Uint32 máximo tamaño de paquete
 … datos específicos del canal

 Byte SSH_MSG_CHANNEL_OPEN_CONFIRMATION
 Byte SSH_MSG_CHANNEL_OPEN_FAILURE
 Byte SSH_MSG_CHANNEL_DATA
 Byte SSH_MSG_CHANNEL_CLOSE
Intercambio de mensajes en conexión
 Tipos de canales

Session Forwarded tcp ip x11

Direct tcp ip
 Port Forwarding
Local
 Port Forwarding
Remote
 Conclusiones

 El protocolo HTTPS es una opción fiable para proteger nuestra

información cuando viaja atreves de la red, la medida de
protección esta ligada al tipo de certificado que se use en el
servidor web.
 El protocolo de autenticación de usuarios de SSH utiliza varios
métodos, de manera que se asegura la identidad del usuario
autenticado, que luego podrá hacer uso de los canales de
transmisión que son multiplexados por un mismo túnel de conexión
segura por medio del protocolo de conexión de SSH.
 El port forwarding, tanto a nivel local como a nivel remoto, hace un
manejo de puertos TCP en la transmisión de datos que dificulta la
tarea de rastreo de mensajes por parte de atacantes.