1
HTTPS y SSH
Redes de comunicaciones III
Juan Pablo Moreno Rico – 20111020059
Nicolás Steven Rivera Rincón - 20142020021
Ingeniería de Sistemas, Universidad Distrital Francisco José De Caldas
Bogotá, Colombia

Resumen—Los protocolos de seguridad en la conexión HTPS y
SSH permiten el acceso seguro de los usuarios a aplicaciones de
servidor mediante la autenticación exhaustiva utilizando varios
métodos y protocolos para ello.
Palabras Claves—HTTPS, SSH, TCP, TLS, autenticación, port
forwarding,
I. INTRODUCCION
La seguridad de las conexiones realizadas a través de internet
se ha convertido en un tema prioritario, los crímenes
informáticos se tipificaron en Colombia por la Ley 1273 de
2009 debido a su rápido crecimiento. Solamente en el año
2015 se registraron más de 7118 denuncias de delitos
informáticos en Colombia siendo el 15% de los delitos
cometidos contra empresas y su crecimiento se proyecta a una
proporción de entre el 50 y 60 por ciento cada año [2]. Pero
este es un problema mundial, presente en mucha mayor
proporción en países desarrollados.
Lo anterior es solo un pequeño dato para justificar la
necesidad de desarrollar mecanismos de protección de los
datos que circulan a través de internet, principalmente los
datos de acceso a las plataformas bancarias mediante la
autenticación. La protección de datos de autenticación en la
web se realiza mediante la combinación de protocolos como
HTTP y certificados de autenticidad como SSL, que aseguran
tanto la autenticidad de los sitios web a los que el usuario
accede, como la identidad del usuario que solicita acceder a
servicios de alta sensibilidad, como son las transacciones
bancarias, entre otros. Así mismo, el acceso a ordenadores de
manera remota ha sido un medio que puede llegar a facilitar el
robo de información por parte de delincuentes por medio de la
interceptación de los mensajes transmitidos entre una terminal
y la otra, previniendo esto, el protocolo de seguridad diseñado
para este tipo de comunicaciones en la red es Secure Shell
mejor conocido por sus siglas como SSH, que realiza una
conexión segura entre las terminales, protegiendo la
información que se transmite entre ellas de ataque de
interceptación que conlleven pérdida.
II. PROTOCOLO HTTPS
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, esto por lo
general no presenta ningún problema ya que por ejemplo si
alguien está realizando una cónsula en una biblioteca virtual
de acceso público como usuario nos es irrelevante que alguien
este monitoreando la información que se transmite entre
nuestro navegador y el servidor web los problemas inician
cuando estamos trabajando con información más sensible
como podría ser nuestras transacciones bancarias, si esta
información viaja como texto plano a través de la red
cualquiera podría leerla y hasta suplantar la identidad del sitio
al que nos conectamos, por estos inconvenientes surge el
protocolo HTTPS ya que cuando se establece una
comunicación con este protocolo los siguientes elementos 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.
La implementación del protocolo HTTPS en un servidor web
depende en gran medida del certificado que se adquiera para
nuestro servidor y de su correcta instalación, aunque existen
certificados que se pueden adquirir de manera gratuita estos
solo validan la información del servidor al que se está
transmitiendo nuestros datos, no se puede incluir una
validación de más campos, a diferencia de certificados de
pago que brindan una certificación extendida con una abanico
de características que le dan confianza a los usuarios y a los
administradores del servidor web.
De cara al usuario HTTPS presenta en la mayoría de
navegadores un indicador visual de que se está estableciendo
una comunicación segura, con una variante entre certificados
gratuitos que tienen la etiqueta Seguro y certificados de pago
que puede incluir el nombre de la compañía al que pertenece
como aparece en la mayoría de páginas web de entidades
bancarias.

III. 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 a diferencia de estos SSH cifra la
sesión de conexión a su vez también puede utilizarse para
funciones de red como la transferencia de archivos, correo
electrónico y tunneling.
SSH se divide en tres protocolos que normalmente se ejecutan
en la parte superior de TCP.
Fig. 1: Grupo de protocolos SSH
Las tareas que cumplen cada uno de estos protocolos son las
siguientes:
 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.
IV. PROTOCOLO DE CAPA DE TRANSPORTE
La autenticación del servidor se produce en la capa de
transporte, el servidor posee un par de claves pública/privada.
2
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.
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.
A. Intercambio de paquetes en la capa de transporte
El envió de paquetes sigue los siguientes pasos des del
establecimiento de la conexión hasta él envió de información:
Fig. 2: Intercambio de paquetes capa de trasporte.

1) 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.
2) 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>
El servidor responde con su propia cadena de
identificación. Estas cadenas se utilizan en el
intercambio de llaves.
3) 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.
4) 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.
5) El final del intercambio de claves: está 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.
V. PROTOCOLO DE AUTENTICACIÓN DE USUARIO
El protocolo de autenticación de usuarios provee los
mecanismos por los cuales el cliente es autenticado ante el
servidor.
A. Tipos de mensajes y formatos
Hay tres tipos de mensajes que siempre se usan en este
protocolo, el primero es la solicitud de autenticación que
realiza el cliente, este mensaje tiene el siguiente formato:
3
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.
Aquí, el nombre de usuario es la identidad que el cliente
reclama, el nombre del servicio corresponde a aquel que el
cliente solicita acceder, en este caso, al protocolo de conexión
de SSH; y el nombre del método hace referencia al método de
autenticación usado en la solicitud.
Si el servidor rechaza la solicitud, responde con un mensaje de
autenticación fallida, que se estructura así:
Byte SSH_MSG_USERAUTH_FAILURE (51)
Lista autenticaciones que pueden proceder
Bool éxito parcial
La lista contiene los nombres de los métodos de autenticación
que con los que puede continuar el cliente, si la autenticación
es aceptada, el servidor envía un mensaje de un único byte:
SSH_MSG_USERAUTH_SUCCESS (52).
B. Intercambio de mensajes
El intercambio de mensajes involucra los siguientes pasos:
1) El cliente envía SSH_MSG_USERAUTH_REQUEST
sin indicar nombre del método.
2) El servidor determina si el nombre de usuario es válido.
Si no, responde con un SSH_MSG_USERAUTH_FAILURE
con valor de éxito parcial en falso. Si el nombre s valido, el
proceso continúa.
3) El servidor envía SSH_MSG_USERAUTH_FAILURE
con la lista de métodos a usar.
4) El cliente elige uno de los métodos recibidos y envía un
SSH_MSG_USERAUTH_REQUEST con el nombre de ese
método y los campos que requiera, en este punto, habría una
secuencia de intercambios para ejecutar dicho método.
5) Si la autenticación es exitosa y hacen falta otros
métodos, el servidor procede con el paso 3, con un valor de
true de éxito parcial. Si la autenticación falla, el servidor
procede con el paso 3 con un valor de éxito parcial de false.
6) Cuando ya se han realizado todos los métodos de
autenticación, el servidor responde con un mensaje de tipo
SSH_MSG_USERAUTH_SUCCESS dando fin al protocolo
de autenticación.

Fig. 3: Intercambio de mensajes en protocolo de autenticación.
C. Métodos de autenticación
El servidor puede requerir uno o más de los siguientes
métodos de autenticación:
1) Llave pública: Los detalles de este método dependen
del algoritmo de llave pública elegido. El cliente envía al
servidor un mensaje con su llave pública, firmado con su
llave privada. Cuando el servidor lo recibe, revisa que esa
llave sea aceptable para autenticación y que la firma sea
correcta.
2) Contraseña: el cliente envía un mensaje con la
contraseña en texto plano, este mensaje s protegido con
encriptación por el protocolo de la capa de transporte.
3) Basado en host: La autenticación es realizada en el host
del cliente en lugar del servidor. En este caso el servidor
SSH verifica la identidad del host cliente en lugar de la del
usuario y acepta lo que este host diga del usuario cuando ya
se ha autenticado.
VI. PROTOCOLO DE CONEXIÓN
El protocolo de conexión de SSH se ejecuta sobre el protocolo
de la capa de transporte y asume que ya hay una conexión
autenticada y segura que es el resultado del protocolo de
autenticación de usuario. A esta autenticación segura se le
llama túnel y la usa el protocolo de conexión para realizar
multiplexación de canales.
A. Mecanismo de canales
Todos los mecanismos de comunicación con SSH utilizan
canales separados. Para cada canal, cada extremo de la
conexión crea una asociación con un número único de canal
que puede ser distinto en cada extremo. El flujo en los canales
se controla con un mecanismo de ventana. No se enviarán
datos por un canal hasta recibir un mensaje que indique
espacio de ventana disponible.
El ciclo de vida de una canal tiene tres fases: apertura del
canal, transferencia de datos y cierre del canal.
4
Cuando alguno de los participantes desea abrir un canal,
separa el número del canal y envía un mensaje con la siguiente
forma:
Byte SSH_MSG_CHANNEL_OPEN
String tipo de canal
Uint32 canal emisor
Uint32 tamaño inicial de ventana
Uint32 máximo tamaño de paquete
… datos específicos del canal
El tipo de canal identifica la aplicación de este canal, el canal
emisor es el número de canal elegido. El tamaño inicial de
ventana indica cuantos bytes pueden enviarse por el canal y el
máximo tamaño de paquete establece un límite para el tamaño
de los paquetes enviados, por ejemplo, para una conexión
interactiva conviene más enviar paquetes pequeños para
obtener una mejor respuesta en conexiones lentas.
Si el lado remoto de la conexión puede abrir el canal responde
con un SSH_MSG_CHANNEL_OPEN_CONFIRMATION
que incluye el número de canal de ambos y los tamaños de
ventana y paquete para el tráfico entrante, de lo contrario
responde con SSH_MSG_CHANNEL_OPEN_FAILURE y un
código que indica la razón de la falla.
Una vez abierto el canal, comienza la transferencia de datos
usando mensajes SSH_MSG_CHANNEL_DATA. Estos
mensajes seguirán enviándose mientras el canal esté abierto.
Cuando alguno decida cerrar el canal, enviará un mensaje
SSH_MSG_CHANNEL_CLOSE con el número de canal a
cerrar.
Fig. 4: Ciclo de vida de los canales de comunicación.
B. Tipos de canales
Se reconocen cuatro tipos de canales en el protocolo de
conexión SSH:
 5

1) Sesión: la ejecución remota de un programa, típicamente
una consola de comandos, transferencia de archivos o correo
electrónico o algún sistema pre construido. Una vez el canal
de sesión es abierto, le siguen una serie de solicitudes para
iniciar el programa remoto.
2) X11: hace referencia a un sistema de interfaz gráfica de
usuario para computadores en red, permite la ejecución de
aplicaciones en un servidor de red mostrándose en un
computador de escritorio.
3) TCPIP remitido: puertos remotos remitidos (port
forwarding).
4) TCPIP directo: puertos remitidos locales.
algoritmos de encriptación diferentes brindando una mayor
seguridad.
El protocolo de autenticación de usuarios de SSH utiliza
varios métodos, de manera que se asegure 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.

C. Puertos remitidos (port forwarding)

REFERENCIAS
Esta es de las principales características de SSH, permite
convertir una conexión TCP insegura en una conexión SSH [1] Stallings, W., Network security essentials. Cuarta edición. Prentice Hall,
2011.
segura. También llamado tunneling. Un puerto es la [2] http://www.eltiempo.com/archivo/documento/CMS-16493604
identificación de un usuario de TCP, cualquier aplicación que Recuperado el 08/10/2017
requiera TCP tiene un número de puerto, así, el que un flujo [3] HTTPS and SSL tutorial.
de tráfico llegue a la aplicación correspondiente de debe al Disponible en: https://www.youtube.com/watch?v=_p-LNLv49Ug
número de puerto que usa para ello. Para asegurar esta
conexión, SSH establece una conexión TCP entre el cliente
SSH y el servidor con los números de puertos TCP
correspondientes, se establece un túnel sobre esta conexión
TCP de manera que el tráfico del cliente es tomado por la
entidad local SSH y esta lo envía a través del túnel a la
respectiva entidad SSH del servidor, que finalmente lo remite
a la aplicación del servidor correspondiente.
Hay dos tipos de remisión de puertos: local y remota. La
remisión local permite al cliente tomar el tráfico de una
conexión TCP insegura para enviarlo a través de un túnel SSH
que está configurado en puertos específicos. En el otro
extremo, el servidor SSH envía el tráfico entrante al puerto de
destino indicado por la aplicación del cliente.
En la remisión remota, el cliente SSH del usuario actúa del
lado del servidor. El cliente recibe el tráfico con un número de
puerto específico, lo ubica en el puerto correcto y lo envía al
destino elegido por el usuario. Un ejemplo típico es el acceso
a un servidor remoto desde un computador en casa, ya que el
servidor se encuentra detrás de un firewall no es posible
acceder con una solicitud SSH desde el computador en casa,
sin embargo, en el servidor se puede configurar un túnel por el
que se realice la conexión.

VII. 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 está ligada al tipo de certificado que se use en el
servidor web.

El protocolo SSH brinda gran seguridad al poder tener claves

encriptados con diferentes algoritmos y poder entablar una
negociación entre usuario y servidor por cada conexión para
elegir un tipo de encriptación que se usara en la comunicación,
lo que permite que muchas conexiones trabajen con