Módulo 2: Seguridad en Redes

Unidad 1: Autenticación, clave pública y privada

Repasá

Unidad 2. Seguridad IP

Repasá

Para saber más ...

Referencias
LECCIÓN 1 de 6

Unidad 1: Autenticación, clave pública y privada

2.1.1 Kerberos y autenticación

Kerberos es un protocolo de seguridad muy difundido en distintos entornos informáticos y sistemas operativos como, por ejemplo, Linux,
Windows y MacOS. El protocolo Kerberos fue desarrollado en el Instituto Tecnológico de Massachusetts (MIT) con el objeto de proteger los
servicios de red brindados por el proyecto Athena.

Athena fue un proyecto desarrollado entre el MIT (Massachusetts Institute of Tecnology) dos empresas de informática: DEC (Digital
Equipment Corporation e IBM (International Bussiness Machines Corporation). El principal objetivo de este proyecto era fomentar el
desarrollo de herramientas de aprendizaje con la utilización de computadoras, para que puedan ser utilizadas en múltiples establecimientos
educativos, principalmente universidades.

El proyecto también buscaba crear una base de conocimiento para tomar decisiones sobre la computación en el área educativa, así como crear
un entorno de computadores (red) que soporta distintos tipos de hardware. Adicionalmente, busca fomentar el intercambio de ideas, códigos,
experiencias y conocimiento mediante el MIT.

El proyecto Kerberos recibe su nombre de un personaje de la mitología griega. Hay varias versiones del protocolo. Las primeras versiones,
especí camente de la 1 a la 3, fueron desarrolladas dentro del MIT. Steve Miller y Cli ord Neuman, los principales diseñadores de la versión 4
de Kerberos, publicaron esa versión al nal de la década de 1980. La versión 5 fue diseñada por John Kohl y Cli ord Neuman.

En los entornos de red abierta, como es el caso de internet, una computadora no es con able para identi car a los usuarios de los servicios
en red que se utilizan en ella. En este sentido, Kerberos es un método con able, ya que ofrece una autenticación de usuario y, en paralelo,
garantiza integridad y privacidad.

Como vimos en lecturas anteriores, la autenticación es la función mediante la cual se garantiza que ambas entidades, tanto la del emisor
como la del receptor, son verdaderas.

Cuando hablamos de que el servicio asegura integridad, decimos que es capaz de garantizar que los datos son válidos al momento de la
transferencia. Cuando nos referimos al cifrado, nos estamos re riendo a la privacidad al momento de realizar la comunicación.

La nalidad de Kerberos es el inicio de sesión entre equipos –normalmente, cliente-servidor– y el establecimiento una comunicación segura,
garantizando la autorización para realizar las tareas que sean permitidas por los administradores. Durante esta comunicación entre
computadoras, se intercambian datos, se trans eren archivos o se ejecutan comandos.

Otra característica de Kerberos es que es un sistema único de inicio de sesión. Esto quiere decir que, una vez autenticados, el resto de las
operaciones que realizamos mientras dure la sesión está garantizado por el inicio de sesión que hicimos al principio. En otras palabras, una
vez establecida la autenticación entre un cliente y un servidor, no es necesario autenticarse nuevamente ante cada comando o acción que
ejecutemos.

Para comenzar la explicación del funcionamiento de Kerberos, debemos empezar diciendo que es un sistema de autenticación basado en
tickets. Los tickets son un conjunto de información que contiene datos como la identi cación del usuario (ID) o a qué tipo de servicios puede
acceder con este ticket.
En sitios web y en diversos autores, podemos encontrar que el ticket también es llamado TGT (ticket granting-ticket) o simplemente ticket de
acceso. El usuario se autentica con el servidor (key distribution center o KDC, por su sigla en inglés) o centro de distribución de claves. El KDC
chequea si el usuario está autorizado, si su clave coincide con la que él tiene almacenada y genera un ticket con la información sobre quién es
el usuario y qué tipo de permisos tiene garantizados. Una vez autenticado, el usuario obtiene un ticket, y luego utiliza este ticket para
autenticarse con un servidor.

Como mencionamos previamente, el usuario presenta una sola vez su ticket y puede hacerlo en varios servicios de forma simultánea con este
ingreso único; por ejemplo, una web, una base de datos y una app. Esto quiere decir que, si el usuario, mediante su ticket, tiene permisos para
utilizar esos tres servicios, una vez que presentó su ticket, automáticamente se autentica y puede usar todas las aplicaciones, sin tener que
volver a repetir el proceso o pedir un nuevo ticket.

Es importante destacar que Kerberos está basado en criptografía asimétrica, de modo que requiere un tercero en el que ambas partes confíen
para la comunicación establecida. En este caso ese rol de tercera parte es cumplido por el KDC.

En todo este proceso de otorgamiento de tickets y autenticación, existe un servicio llamado AS (authentication server o servidor de
autenticación). Es el servicio de AS el responsable de todas las peticiones de los clientes.

Normalmente, se ejecuta en el mismo servidor KDC. El proceso por el cual se generan, otorgan y se aseguran los tickets se conoce como TGS
o ticket granting services. También es importante tener en cuenta que los tickets tienen una caducidad y, luego de que estos expiran, no sirven
para autenticarnos. En este caso será necesario iniciar nuevamente el proceso de solicitud.

Figura 1: Proceso de autenticación Kerberos

Fuente: elaboración propia.

El usuario inicia sesión en su PC, se autentica ingresando sus credenciales.

 Una vez autenticado el servidor de KDC, luego de veri car el usuario y saber sobre qué servicios tiene garantizado su acceso, el sistema le
devuelve un ticket o TGT mediante el proceso de TGS.

Cuando el usuario quiere utilizar cualquier servicio que está hosteado en el servidor (que confía en el KDC), por ejemplo, una página web,
utiliza el ticket emitido por el KDC para autenticarse al servidor.

En el caso de que el usuario quiera utilizar otro servicio, por ejemplo, una base de datos que también está en este servidor, utiliza el mismo
ticket o TGT. Este ticket es utilizado para autenticar al usuario de modo transparente.

Figura 2: Ticket Kerberos

Fuente: elaboración propia.

En este ejemplo, mediante el comando klist, en una PC con Windows 10 podemos listar los tickets de Kerberos que están activos. Los campos
que podemos ver en el ticket son los siguientes:

Client: nombre del usuario que recibió en el ticket, en este caso, T30989@dominio.

Server: servidor KDC responsable por el ticket.

KerbTicket Encryption Type: tipo de encriptación utilizada en el ticket.

Start Time: fecha de pedido del ticket y comienzo de su validez.

End Time: fecha de caducidad del ticket.

2.1.2 Pretty Good Privacy (PGP)

PGP o Pretty Good Privacy es un software de cifrado, rma y autenticación creado por Phil Zimmerman. Este sistema permite cifrar cualquier
tipo de información, como archivos, discos, correos electrónicos, etcétera. Entre todas las opciones disponibles de PGP, la más utilizada es la
opción que permite rmar digitalmente los correos electrónicos.

Como vimos en lecturas anteriores, el objeto de esta funcionalidad es veri car que el mensaje no fue modi cado durante el proceso de envío,
transmisión o en ninguno de los puntos intermedios entre que el mensaje es enviado por el emisor y es leído por el receptor.
Entre las versiones del software más utilizadas, está la versión de PGP desarrollada por la Organización Free Software Foundation. Esta
versión recibió el nombre GNU Privacy Guard o GPG o GNUPG. Además de proporcionar el software para cifrado y descifrado de mensajes,
ponen a disposición de los usuarios las librerías y el código fuente para que los desarrolladores las utilicen para mejorar el software. Podés
encontrar más información sobre este proyecto en la sección Para saber más.

También existen alternativas para utilizar PGP en distintos sistemas operativos. Por ejemplo, para Windows está disponible GPG4Win y para
MacOS se puede utilizar la GPG Suite, que tiene un plugin para utilizar con el mail.

Cómo funciona el cifrado PGP:

Creamos una pareja nueva de claves. Entre los datos necesarios para crearlas, debemos elegir la longitud de la clave y una contraseña para
proteger nuestra clave privada.

La longitud de la clave nos garantiza una menor posibilidad de ataque de diccionario o de fuerza bruta. También es importante considerar que,
cuanto más extensa sea la clave, más tiempo será el necesario para realizar las operaciones de generación y encriptación. En PGP lo
recomendado es utilizar una clave de longitud de 4096 bits.

Cuando tenemos el par de claves, podemos distribuir nuestra llave pública. El emisor del mensaje utilizará nuestra llave pública para la
encriptación de los mensajes.

Solamente con nuestra clave privada, podemos descifrar este mensaje.

En el caso de que nosotros, los dueños del par de claves, enviemos un mensaje, lo encriptamos con nuestra clave privada.

El receptor o cualquier persona que tenga nuestra clave pública tiene la posibilidad técnica de veri car la autenticidad del mensaje.

Figura 3: Cómo funciona el cifrado PGP

 Fuente: Xaedes, Jfreax y Acdx, 2018, https://bit.ly/2Mh5dFg

Figura 4: Opciones disponibles en OpenPGP

 Fuente: Captura de pantalla de computador personal.

Seguramente, notaste que hay muchas referencias entre la bibliografía o las lecturas adicionales al IETF. El Internet Engineering Task Force
(IETF) o Grupo de Trabajo de Ingeniería en Internet es una comunidad abierta que se ocupa del desarrollo y la arquitectura que se utiliza en
Internet. Entre sus tareas, podemos enumerar la creación, publicación y desarrollo de normas y estándares utilizados en la red. Como toda
organización que trabaja en la creación de estándares, su misión está documentada y disponible.

Si estás interesado en conocer más sobre la tarea que desarrolla el IETF, podés consultar los enlaces en la sección Para saber más.

2.1.3 S/MIME
El término S/MIME se re ere a secure multipurpose mail extensión (en español: extensiones multipropósito de correo de internet seguro). Es
un proceso de seguridad que se utiliza en el intercambio de correos electrónicos. Está formado por convenciones y estándares para transferir
archivos en internet. Este es un estándar de criptografía de clave pública y formado de correo electrónico.

El estándar lo desarrolló en 1999 RSA Data Security, que es una compañía dedicada a la criptografía y al desarrollo de software para seguridad.
S/MIME se convirtió en estándar luego de que fuera veri cado y rati cado por la IETF. Según “Secure/Multipurpose Internet Mail Extensions
(S/MIME) Versión 3.2. Message Speci cation” (IETF, 2010), donde están las especi caciones de S/MIME:

S/MIME proporciona una manera segura y consistente de enviar y recibir datos seguros en formato MIME. Basado en el estándar MIME,
S/MIME proporciona los siguientes servicios de seguridad criptográ ca para mensajería electrónica:

Autenticación.

Integridad de los mensajes.

No repudios en el origen (utilizando rmas digitales).

Con dencialidad de los datos (mediante encriptación).

Compresión de mensajes, como servicio adicional.

Cuando hablamos de no repudio, nos referimos a que, mediante la rma digital de los mensajes, S/MIME nos garantiza que el emisor del
mensaje es realmente quien nos lo envía.

S/MIME se basa en el estándar MIME, cuya principal función es normalizar el formato de los archivos que se adjuntan a un correo
electrónico. Es importante aclarar que el uso de estos estándares es totalmente transparente para el usuario. S/MIME es utilizado por casi
todos los clientes de correo electrónico, en casi todos los sistemas operativos y, lógicamente, todos ellos pueden interactuar entre sí.

Finalmente, debemos tener en cuenta que el estándar está basado en un cifrado de clave pública. En este caso, como vimos con otros
sistemas de cifrado, quien es responsable de la generación de estas rmas digitales es una entidad en la que confían ambas partes de la
comunicación, emisor y receptor.

De este modo, existen empresas privadas que venden soluciones basadas en S/MIME para cifrado y rmado de correos electrónicos. Por
ejemplo, la rma Global Sign ofrece una solución llamada e-mail seguro. Más información en el enlace a continuación:
https://www.globalsign.com/es/email-seguro/

Cómo funciona S/MIME:

Cuando utilizamos S/MIME, la clave de inicio de sesión se inserta en el encabezado del mensaje, de modo que cifra el mensaje con la clave
pública del destinatario. Recordemos, como vimos en lecturas anteriores, que solamente el destinatario, mediante su clave privada, es quien
puede abrir este mensaje cifrado.

Adicionalmente al cifrado, el mensaje es rmado con la clave privada del remitente. La rma digital garantiza al destinatario que la identidad
del remitente sea veraz.

Es importante que recordemos que las rmas son emitidas por una entidad en la que ambas partes, emisor y receptor, confían.

Figura 5: Opciones S/MIME en Outlook

Fuente: Captura de pantalla de computador personal.

 Fuente: Captura de pantalla de computador personal.

Como mencionamos anteriormente, durante la lectura todos los correos electrónicos que recibimos o enviamos se utiliza el estándar MIME.

Figura 6: Encabezado de un mensaje enviado desde Gmail

Fuente: Captura de pantalla de computador personal.

En el apartado Para saber más, encontrarás un enlace con más información.

C O NT I NU E
LECCIÓN 2 de 6

Repasá

Caso práctico. Unidad 1

En la empresa utilizan un sistema de validación que tiene como método de autenticación Kerberos. Como usuario

necesitás autenticarte en cinco servicios distintos. En caso de que tuvieras que explicar cómo sería la autenticación,

¿cuál sería la opción correcta?

Debe gestionar cinco tickets distintos para todas las operaciones.

No es necesario que genere ningún ticket porque el sistema lo autentica de forma automática.

Debe gestionar un solo ticket, que será su ciente para todos los servicios.

SUBMIT

Respondé si el siguiente enunciado es verdadero o falso: “Durante la ejecución de los servicios en Kerberos, el usuario

realiza el inicio de sesión. La autenticación inicial le servirá para todas las operaciones sin necesidad de ingresar cada

vez”.

Verdadero

Falso

SUBMIT
En la empresa te piden que escojas un sistema de seguridad y autenticación para los servidores que administrás. ¿En

qué características estaría basada tu elección?

En que la veracidad de emisor y receptor están garantizadas.

En que es posible transmitir datos, transferir archivos y ejecutar comandos de forma segura.

En que, con un inicio único de sesión, se pueden garantizar todas las actividades.

Todas las anteriores.

SUBMIT

C O NT I NU E
LECCIÓN 3 de 6

Unidad 2. Seguridad IP

2.2.1 Arquitectura IP
Como vimos en lecturas anteriores y seguramente viste en otras materias, en redes un protocolo es una serie de normas que se utilizan para
establecer una estandarización; en este caso, en las comunicaciones que viajan a través de esta red.

Una analogía sencilla: supongamos que todas las computadoras del mundo “hablan” diferentes idiomas, pero, al momento de “hablar” entre
ellas cuando están conectadas a una red muy grande –en este caso, internet–, acuerdan hablar un idioma común para comunicarse e
integrarse.

Cuando las computadoras se conectan a internet o a una red, utilizan un protocolo para poder comunicarse entre ellas y cualquier otro
dispositivo que esté conectado a esta red. IP quiere decir internet protocol o protocolo de internet.

El protocolo IP fue desarrollado en los años 70 con el surgimiento de las primeras redes de computadoras; entre ellas, ARPANET (por
Advanced Research Projects Agency Network), considerada la precursora de internet. Si te interesa conocer un poco acerca de la historia de
esta red, te recomendamos el video sobre ARPANET, cuyo enlace podrás encontrar en el apartado Para saber más, ya que este año se cumplen
50 años desde su desarrollo.

Volviendo al protocolo IP, normalmente se utiliza junto con el protocolo de control de transporte (TCP), y es por eso que recibe el nombre de
TCP/IP. Actualmente, casi todas las aplicaciones y hardware que utilizamos que se conectan a internet o a otras redes usan TCP/IP: nuestras
computadoras, teléfonos celulares, televisores, aires acondicionados, etcétera.

Para comenzar con la explicación del protocolo, es importante recordar el modelo OSI (open system interconnection). En el apartado Para saber
más, te dejamos un resumen para ampliar más información. Para el intercambio de datos entre equipos, se deben realizar muchos
procedimientos, los cuales se agrupan en capas y realizan procedimientos relacionados en una misma capa.

Como recordarás, las capas tienen jerarquía, es decir, cada capa está construida sobre la anterior. En el caso de TCP/IP, también están
divididas en niveles independientes según su función.

La arquitectura por niveles, en el caso de TCP/IP, está dividida en 4 niveles conocido como modelo DARPA (Defense Advanced Research
Projects Agency o Agencia de Proyectos de Investigación Avanzados de Defensa). En alguna bibliografía y en muchos esquemas que veas, es
posible que encuentres gra cado un quinto nivel, que es el nivel de hardware o nivel físico. En el caso del esquema que acompaña la lectura,
consideramos importante presentarlo a modo de referencia.

Las cuatro capas o niveles que tiene el modelo son: aplicación, transporte, internet e interfaz de red.

Capa de aplicación:
–
es la capa que brinda a las aplicaciones la posibilidad de utilizar los servicios de las capas inferiores. Otra de las funciones es la de las de niciones de los
protocolos que usan las aplicaciones.
Capa de transporte:
–
capa responsable de la comunicación entre los dispositivos conectados en distintas redes.

Capa de internet:
–
es la que determina el mejor camino a través de la red. Esta capa es responsable de las funciones de direccionamiento, enrutamiento y empaquetado. Estos
conceptos los desarrollaremos más adelante.

Interfaz de red:
–
es la capa responsable de controlar los dispositivos y el hardware que se conectan a la red. Es la que se ocupa de los paquetes TCP/IP en la red. Se utiliza para
conectar distintos tipos de redes.

En esta arquitectura de capas o niveles, además, existen protocolos que funcionan dentro de cada una de estas capas. Solamente, vamos a
enumerar algunos y conocer dentro de qué capa funcionan en el siguiente esquema.

Figura 7: Modelo DARPA

Fuente: Captura de pantalla de computador personal.

Figura 8: Las cuatro capas del modelo DARPA

Fuente: elaboración propia.

Como ya viste en otras materias, la mayoría de las redes usa el protocolo IP versión 4 (IPV4), que utiliza direcciones de cuatro bytes (32 bits).
Debido a la gran cantidad de dispositivos conectados a internet, este direccionamiento no es su ciente. Por eso fue necesario mejorarlo.
Entonces, la versión 6 (IPV6) utiliza direcciones de 16 bytes (128 bits).

Figura 9: Direcciones IPV4

Fuente: Universidad de Málaga, s. f., https://bit.ly/1yJnoAP

En la sección Para saber más, encontrarás información adicional sobre este tema.

2.2.2 Encapsulamiento IP
Cuando utilizamos TCP/IP, la información que transmitimos viaja por la red en segmentos creados por TCP. Este proceso de fraccionar la
información se conoce como segmentación.

Otro proceso que ocurre durante esta transmisión se conoce como encapsulamiento, que se trata de “envolver” los datos con la información
que el protocolo necesita para ser transmitida por la red. La información se mueve hacia abajo en las capas del modelo OSI y cada una de ellas
añade información adicional. Esta información se llama encabezado o header, en inglés.

Los segmentos creados durante la segmentación por TCP son encapsulados por IP y se llaman PDU (protocol data unit o unidad de datos del
protocolo). Los PDU de IP son los que facilitan que los segmentos TCP que fueron creados por las aplicaciones sean transmitidos por la red.

Entre sus tareas, el proceso de encapsulamiento agrega información a los datos generados por la capa de aplicación, en la medida en que
estos van pasando por el stack de protocolos. Durante el proceso de encapsulamiento, cada capa encapsula las PDU que recibe de la capa
superior.

En cada una de las etapas de este proceso, la PDU cambia de nombre por cada una de las capas para re ejar que se trata de una nueva. Tal
como lo comenta el autor Luis R en su blog, el proceso de encapsulamiento funciona del siguiente modo:

Los datos de usuario son enviados a la capa de aplicación.

La capa de aplicación añade el encabezado (layer 7 Header) a los datos. El encabezado y los datos originales pasan a la capa de presentación.

La capa de presentación recibe los datos que llegan de la capa superior, incluyendo el encabezado agregado, y los trata solo como datos, añade
su encabezado a los datos y los pasa a la capa de sesión.

La capa de sesión recibe los datos, añade su encabezado y lo pasa a la capa de transporte.

La capa de transporte recibe los datos, añade su encabezado y pasa los datos a la capa inferior.

La capa de red añade su encabezado y pasa los datos a la capa de enlace de datos.

La capa de enlace de datos añade el encabezado y un tráiler (cola) a los datos. A esto lo usa el receptor para detectar que los datos enviados
están o no en error. Esto envuelve los datos, que son pasados a la capa física.

La capa física, entonces, transmite los bits hacia el medio de red. (Luis R, 2008)

Figura 10: Encapsulamiento IP

 Fuente: elaboración propia

Desencapsulamiento
Este es el nombre que recibe el proceso inverso, es decir, cuando el dispositivo recibe los bits, que en este caso hacen el proceso inverso: de
abajo hacia arriba.

Revisa el tráiler de la capa de enlace de datos para ver si existe algún tipo de error.

Si los datos tienen error, pueden ser descartados y la capa de enlace de datos puede pedir su retransmisión.

Si no existe error, la capa de enlace de datos lee el header, que tiene la información de control (encabezado de capa 2 o L2 header, en inglés).

Se quita el header y el tráiler, y el resto de la información se envía a la capa superior.

En el apartado Para saber más, podrás encontrar más información sobre el encapsulado de datos.

2.2.3 SSL y TLS

Secure sockets layer (SSL, por su sigla en inglés) o la capa de sockets seguros es una tecnología que se utiliza para asegurar una conexión de
internet. Adicionalmente, protege la información que estamos trans riendo entre 2 equipos.

Normalmente, estos 2 equipos son un servidor y un cliente, pero también puede ser una comunicación entre servidores. El protocolo transport
layer security (TLS) o seguridad de la capa de transporte es una versión mejorada y más segura de SSL.
En resumen, lo que estamos haciendo, como vimos en lecturas anteriores, es cifrar los datos que viajan por la red. Pensemos en el caso de un
servidor web de compras online. Al usar SSL, lo que está garantizando es que toda la información de transacciones, como los datos del
comprador o de su tarjeta de crédito, viajen de manera segura de un extremo a otro de la comunicación.

En lecturas anteriores vimos cómo funcionan los cifrados. En este caso puntual, lo que debemos tener presente es que se utiliza la tecnología
de cifrado simétrico.

Anteriormente, utilizamos el ejemplo de una compra electrónica debido a que en servidores web es donde más utilizamos y donde es más
común encontrarnos con este tipo de tecnología. Es muy importante que, debido a la exibilidad de esta, podemos utilizarla en distintos
protocolos y sirve para garantizar la seguridad de correos electrónicos o servidores FTP.

Programas de correo electrónico como Outlook o Mozilla Thunderbird soportan esta tecnología para utilizar certi cados y hacer más seguras
las comunicaciones.

Figura 11: Opciones SSL/TLS Mozilla Thunderbird

Fuente: Captura de pantalla de computador personal.

En el caso de un navegador web (Chrome, Internet Explorer, Safari, etc.), la secuencia de conexión sería la siguiente:

La PC (computadora personal) se intenta conectar a un sitio web protegido con SSL.

El navegador solicita que el sitio web se identi que.

El sitio envía una copia de su certi cado SSL al navegador.

El navegador comprueba: 1) que confía en la autoridad certi cante (CA) que emite el certi cado; 2) que el certi cado es emitido para ese sitio
web; 3) que este es válido y aún no ha caducado.

Si todos estos pasos son correctos, envía un mensaje al sitio web.

 El servidor donde está alojado el sitio web responde enviando una con rmación rmada digitalmente para iniciar una sesión o
“conversación” cifrada mediante SSL

Es muy importante que, para que esta tecnología funcione, todo cliente que se conecta y quiere comunicarse utilizando SSL debe con ar en la
entidad que emite el certi cado CA. Sin esto no es posible utilizar este tipo de tecnologías.

Si recordás, en lecturas anteriores vimos que los sitios web normalmente utilizan certi cados emitidos por entidades comerciales, aunque
hay excepciones, como Google, que emite sus propios certi cados. Estas entidades venden el servicio de certi cados, a modo de suscripción.
Los certi cados duran 1 año o 2, y luego de ese período podemos renovarlo, o no, y hasta cambiar la entidad que genera el certi cado.

Existen también otros métodos para utilizar certi cados que no sean pagos y emitidos por una entidad comercial.

Otro dato muy importante que debemos tener en cuenta es que el certi cado tiene dentro los nombres que solicitamos al momento de pedirlo
y solo es válido para este sitio.

Supongamos que compramos un certi cado para el sitio web www.misitio1.com. Si dentro de este servidor web o en otro que administramos
queremos usar el certi cado, hay otros sitios hosteados. Por ejemplo, al visitar www.misitios2.com, no podemos usar el certi cado que
tenemos y que fue emitido para www.misitio1.com.

¿Esto quiere decir que debemos comprar un certi cado por sitio web o nombre que utilizamos en internet? La respuesta es no. Las CA
soportan certi cados multinombre llamados certi cados de tipo SAN (subject alternative name), es decir que se podría pedir que un mismo
certi cado contenga muchos nombres.

Pero, al momento de instalar y usar los certi cados, es importante que el certi cado original esté instalado en la menor cantidad de
servidores posibles por un tema de seguridad. Adicionalmente, los certi cados soportan wildcards o comodines del tipo (*). Entonces, por
ejemplo, si compramos un certi cado que contenga (*).misitio.com, vamos a poder usarlo para www.misitio.com o ftp.misitio.com o
mail.misitio.com.

Hay softwares que permiten instalar nuestra propia CA y emitir nuestros propios certi cados. Adicionalmente, hay softwares que son capaces
de generar sus propios certi cados, normalmente conocidos como auto rmados, ya que es el propio servidor el que rma los certi cados.
Como principal desventaja, tenemos que ningún cliente en internet confía en un certi cado emitido por un servidor que cualquier persona
instale, a no ser que enviemos nuestra clave pública a todos los clientes con los que vamos a trabajar e instalemos toda la cadena de
con anza de nuestro certi cado en todas las PC que van a trabajar con esa web.

Imaginemos que tenemos un sitio web y debemos instalar un certi cado en todas las PC que van utilizar nuestro sitio o explicarle a un
usuario cómo hacerlo. Técnicamente, es muy complicado, ya que requiere mucho trabajo y esfuerzo solo para instalar y difundir el certi cado
que usamos. Adicionalmente, debemos repetir esta tarea por cada renovación de certi cados.

Es por eso que normalmente, para los sitios web, se utilizan los certi cados emitidos por una CA comercial en la que todas las computadoras
confían. Como estos certi cados son públicos, cada una de estas entidades dentro de la información de los certi cados que emite una CRL
(certi cate revokation list) y los publica en puntos de distribución o distributions points.

El CRL es una lista de revocación de los certi cados. Como te imaginarás, esta lista es un repositorio público, a disposición de cualquier
persona o sistema. Contiene un listado de todos los certi cados emitidos por esa entidad con la información del certi cado y su fecha de
inicio y revocación. Esto funciona como una especie de lista negra, es decir, lista todos los certi cados que la entidad emitió, dando prueba de
su autenticidad, pero ya están revocados. Es decir, cualquier certi cado que esté en esta lista es válido, pero ya no es utilizable.

Entonces, si un certi cado emitido por esta entidad no está en esta lista, el sistema lo da por válido. La nalidad es que todos tengamos a
disposición la fecha e información de estos certi cados para evitar no solamente el uso de un certi cado vencido, sino también la
suplantación de un certi cado que pudo ser robado o cambiado.

Figura 12: Lista de CA en las que confía una PC Windows

Fuente: Captura de pantalla de computador personal.

Figura 13: Dirección de CRL de certi cado SSL

Fuente: Captura de pantalla de computador personal.

Figura 13: Dirección de CRL de certi cado SSL

 Fuente: Captura de pantalla de computador personal.

En el apartado “Para saber más”, podrás encontrar más información sobre este tema.

C O NT I NU E
LECCIÓN 4 de 6

Repasá

Caso práctico. Unidad 2

Trabajás en el sector de Tecnologías de Información de una empresa que se dedica a la comercialización de productos por internet y sos el
responsable de todos los servidores de la empresa. Dentro de uno de los servidores de la compañía, se ejecuta la web desde donde se venden
los productos. En el mismo servidor, hay un servicio de FTP donde se realizan intercambios de archivos con los grandes clientes.

El Área de Seguridad Informática te pide implementar una solución para que todo el trá co entre los clientes y el servidor esté encriptado.
Adicionalmente, requieren que esta solución se implemente con el menor costo administrativo.

El Área de Administración nos dice que solamente podemos comprar un solo certi cado. ¿Qué solución

implementarías?

PGP.

S/MIME.

Firma Digital.

SSL/TLS.

SUBMIT

Para cumplir con lo que te solicitaron en el área, también es necesario encriptar el trá co FTP. Pero, para cumplir con

lo que han requerido desde el Área de Administración, debés utilizar el mismo certi cado que usaste para el sitio web.

¿Qué nombres incluirías al momento de pedir el certi cado?

Haría un relevamiento de todos los nombres que utiliza la empresa y pediría un certi cado con todos estos nombres.

Pediría un certi cado www.midominio.com y ftp.midominio.com

Pediría un certi cado que contenga *.midominio.com

 SUBMIT

Señale para qué sirven las encuestas a clientes:

Medir

Medir e informar

Tener y archivar información del cliente

Tomar decisiones

SUBMIT

C O NT I NU E
LECCIÓN 5 de 6

Para saber más ...

“A Mission Statement for the IETF” (en inglés): https://tools.ietf.org/html/rfc3935

Arpanet The team behind the Internet (en inglés): https://www.youtube.com/watch?v=Cg_XeRSD6Rg

“Beginner’s Guide to SSL Certi cates” (Symantec):

https://www.websecurity.symantec.com/content/dam/websitesecurity/digitalassets/desktop/pdfs/whitepaper/beginners-guide-to-SSL-
certi cates_WP.pdf

“Certi cados SSL Cifrado y Autenticación” (Digicert): https://www.digicert.com/es/certi cado-ssl.htm

“Cómo funciona el servicio Kerberos”: https://docs.oracle.com/cd/E24842_01/html/E23286/intro-25.html

“Digital Equipment Corporation” (DEC): https://es.wikipedia.org/wiki/Digital_Equipment_Corporation

“Encapsulado de Datos y Pila de protocolo TCP/IP” (Oracle): https://docs.oracle.com/cd/E19957-01/820-2981/6nei0r0s7/index.html

“Grupo de trabajo de ingeniería en Internet”: https://es.wikipedia.org/wiki/Grupo_de_Trabajo_de_Ingenier%C3%ADa_de_Internet

“Guía de administración del sistema Servicios IP” (Oracle): https://docs.oracle.com/cd/E19957-01/820-2981/ipov-10/

“Guía de nitiva modelo OSI”: http://www.seaccna.com/modelo-osi-guia-de nitiva/

IETF web (en inglés): https://www.ietf.org/

IP Especi cación del protocolo RFC 0791: https://www.rfc-es.org/rfc/rfc0791-es.txt

“Kerberos” (Wikipedia): https://es.wikipedia.org/wiki/Kerberos

“Kerberos Authentication Overview”: https://docs.microsoft.com/es-es/windows-server/security/kerberos/kerberos-authentication-

overview

Kerberos Consortium: http://www.kerberos.org/

“Klist”: https://docs.microsoft.com/es-es/windows-server/administration/windows-commands/klist

Klist Mit Kerberos Documentation (en inglés): https://web.mit.edu/kerberos/krb5-latest/doc/user/user_commands/klist.html

OpenPGP web (en inglés): https://www.openpgp.org/

“OpenPGP Message Format”: https://www.ietf.org/rfc/rfc4880.txt

“Protéjase Contra los Certi cados SSL Fraudulentos” (Digicert): https://www.digicert.com/es/proteger-contra-certi cados-
fraudulentos.htm

“Protocolos TCP/IP”: https://www.ibm.com/support/knowledgecenter/es/ssw_aix_72/com.ibm.aix.networkcomm/tcpip_protocols.htm

“Protocolo de control de transmisiones/Protocolo Internet (Transmission Control Protocol/Internet Protocol)”:
https://www.ibm.com/support/knowledgecenter/es/ssw_aix_72/com.ibm.aix.networkcomm/tcpip_intro.htm

“Proyecto Athena” (Wikipedia): https://es.wikipedia.org/wiki/Proyecto_Athena_(computaci%C3%B3n)

Seguridad de Correo Electrónico Uso de Firmas Digitales y Cifrado: https://www.globalsign.com/es/lp/download-email- rmas-digitales-

cifrado/

The Evolving threat landscape and best practice for SSL (Symantec):
https://www.symantec.com/content/en/us/enterprise/other_resources/b-evolving-threat-landscape-ebook-en.pdf

“The GNU Privacy Guard” (en inglés): https://www.gnupg.org/index.es.html

“Un tutorial de TCP/IP” (RFC 1180): https://www.rfc-es.org/rfc/rfc1180-es.txt

C O NT I NU E
LECCIÓN 6 de 6

Referencias

1 Internet Engineering Task Force (IETF). (2010). Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2. Message
Speci cation. Recuperado de https://tools.ietf.org/html/rfc5751

2 Luis, R. (2008). IP Reference. [Blog en línea], Recuperado de: https://ipref.wordpress.com/2008/06/03/encapsulamiento/

3 Universidad de Málaga. (s. f.). [Imagen sin título sobre direcciones IPV4]. Recuperado de
http://neo.lcc.uma.es/evirtual/cdd/tutorial/red/ip.html

4 Xaedes, Jfreax y Acdx [Nombres de usuarios]. (2018). Diagrama de funcionamiento PGP [Imagen]. Recuperado de
https://commons.wikimedia.org/wiki/File:PGP_diagramES.svg

C O NT I NU E