Este documento compara el protocolo Telnet sin encriptación con SSH, que usa encriptación. Muestra que con Telnet es posible ver la contraseña transmitida, mientras que con SSH el tráfico es cifrado y no se pueden inferir las credenciales. También compara HTTP sin cifrado con HTTPS, que usa TLS para cifrar la sesión y proteger las URLs solicitadas y los datos transmitidos.

1. UNIVERSIDAD NACIONAL DE INGENIERÍA
FACULTAD DE INGENIERÍA ELECTRICA Y ELECTRÓNICA
IMS (IP MULTIMEDIA SUBSYSTEM)
1
Andy JuanSarangoVeliz
NOMBRES Y APELLIDOS ANDY JUAN SARANGO VELIZ
CÓDIGO 20141327K
ESCENARIO
Comparamos una sesión Telnet de texto plano a una conexión SSH encriptada. En ambas
instancias, nos conectamos a un servidor remoto y ejecutamos la misma secuencia de
comandos. Una huella (trace) de la sesión Telnet fue grabada en telnet.cap y una huella de
sesión SSH fue grabada en ssh.cap.
telnet.cap ssh.cap
telnet.cap ssh.cap
TELNET

2. UNIVERSIDAD NACIONAL DE INGENIERÍA
FACULTAD DE INGENIERÍA ELECTRICA Y ELECTRÓNICA
IMS (IP MULTIMEDIA SUBSYSTEM)
2
Andy JuanSarangoVeliz
Usuario para acceder al servidor de Telnet.
Podemosverla contraseñatransmitidaa través
de la red en texto plano.
SSH
Vemos que el tráfico es cifrado y el dump en ASCII del mismo no contiene datos que nos
permitan identificar o inferir la contraseña o claves utilizadas (métodode autenticación que
utilizamos en la comunicación para este caso).
El único
protocolo que
viaja encriptado
es el SSHv1.
No es posible obtener información de usuario y/o contraseña, ya que estos viajan
encriptados.
Protocolo
SSHv1.99
(Servidor)
Protocolo
SSHv1.5 (Cliente)

3. UNIVERSIDAD NACIONAL DE INGENIERÍA
FACULTAD DE INGENIERÍA ELECTRICA Y ELECTRÓNICA
IMS (IP MULTIMEDIA SUBSYSTEM)
3
Andy JuanSarangoVeliz
Llave pública
El servidor envía su llave pública a
través de la red.
La llave es de 267 bytes de longitud. (Llave asimétrica)
HTTP VS HTTPS
HTTP Texto plano.
HTTPS Sesión encriptada usando TLS.
http.cap https.cap
HTTP
SOLICITUD DEL NAVEGADOR DE UN USUARIO FINAL

4. UNIVERSIDAD NACIONAL DE INGENIERÍA
FACULTAD DE INGENIERÍA ELECTRICA Y ELECTRÓNICA
IMS (IP MULTIMEDIA SUBSYSTEM)
4
Andy JuanSarangoVeliz
Este usuario desea acceder al sitio web "www.clarkson.edu", por lo que debe escribir
http://www.clarkson.edu en su navegador y presionar enter. Después de la resolución DNS
habitual para encontrarla direcciónIP de www.clarkson.edu,se iniciaunaconexiónatravés
de TCP al servidorweb(SYN;SYN,ACK;ACK).Lo siguiente que el navegador/cliente enviará
al servidor web es la siguiente solicitud de texto sin formato:
El servidorsabe que el navegador/ cliente haterminadosu tráfico cuando recibe una líneaen
blanco con “carriage return” + “line feed” ( r n).
RESPUESTA DEL SERVIDOR
La respuesta también está en texto plano:
El navegador / cliente ahora sabe que viene el texto / html, y aquí está:
El navegador / cliente sabe que el servidor ha terminado de enviar su html (or data for non-
html) cuando recibe una línea en blanco con “carriage return” + “line feed” ( r n).
HTTPS
 En este caso,todoslos datosintercambiadosenformacifrada.Nohay ningunapistade
las URLs solicitadas o datos actuales devuelto.
 https.capusael ProtocolodeSeguridadde Capade Transporte (TransportLayerSecurity
Protocol – TLS).

5. UNIVERSIDAD NACIONAL DE INGENIERÍA
FACULTAD DE INGENIERÍA ELECTRICA Y ELECTRÓNICA
IMS (IP MULTIMEDIA SUBSYSTEM)
5
Andy JuanSarangoVeliz
El cliente inicia la conexión
encriptada con un registro client
hello.
El cliente y el servidor deben negociar los algoritmos
criptográficos específicos a ser usados.
En este mensaje client hello, el cliente enumera las opciones que admite en orden de
preferencia:

6. UNIVERSIDAD NACIONAL DE INGENIERÍA
FACULTAD DE INGENIERÍA ELECTRICA Y ELECTRÓNICA
IMS (IP MULTIMEDIA SUBSYSTEM)
6
Andy JuanSarangoVeliz
El servidor responde con registros TLS – un server hello, un certificado, un server key
Exchange (intercambio de llave de servidor), y un server hello done.
En el registro server
hello,el servidorindica
que ha escogido usar
una de las opciones
enumeradas por el
cliente:
TLS_DHE_RSA_WITH_
AES_256_CBC_SHA.
El certificado también
contiene una firma
digital.Este certificado
contiene la llave
pública del servidor,
informaciónacercadel
propietario y
localización del
servidor (subject), y la
autoridad de
certificación quien
concedió el certificado
(issuer - emisor)
El cliente responde con3 registros TLS: un client key Exchange,un change cipher spec, y un
encrypted handshake message.
En clientkeyExchange,
el cliente especifica
una llave conocida
como la “premaster
secret”.

7. UNIVERSIDAD NACIONAL DE INGENIERÍA
FACULTAD DE INGENIERÍA ELECTRICA Y ELECTRÓNICA
IMS (IP MULTIMEDIA SUBSYSTEM)
7
Andy JuanSarangoVeliz
El registro change
cipher spec (registro
de especificación de
cambio de cifrado) se
establece para señalar
una transición en el
algoritmo de cifrado
que se utiliza.
El cliente escribe este
registro, y todos los
registrossubsecuentes
serán encriptados en
el nuevo algoritmo.
El servidor también responde con un change cipher spec message (mensaje de cambio de
especificaciones de cifrado) propio, seguido por un encrypted handshake message. Esto
completa la negociación de los atributos de este canal encriptado
HTTP HTTPS
 La URL empieza con http://
 No utiliza conexión segura.
 Envíalosdatosatravésdel puerto80.
 No requiere validación de dominio.
 Funciona a nivel de aplicación.
 Sin encriptación.
 No requiere certificados SSL.
 La URL empieza con https://
 Utiliza conexión segura.
 Envía los datos a través del puerto
443.
 Requiere mínimo la validación de
dominio y, para algunos certificados,
incluso se requiere la validación de
documentos legales.
 Funciona a nivel de transporte.
 Con encriptación.
 Requiere certificados SSL.
Anexo
TRABAJO-COMPLE
MENTARIO-CONCEPTOS-final-2019-II.pdf