Este blog invitado es parte de una serie y fue creado en asociación con F5.
CSR, PEM, DER, X509… no es de extrañar que los certificados a menudo se consideren una especie de magia.
La primera vez que tuve que obtener un certificado de trabajo, ¡no tenía idea de lo que estaba haciendo! Copié sin rumbo un montón de comandos y esperé que funcionaran. Pero cuando se trata de seguridad, esperar que alguien copie comandos ciegamente es algo riesgoso. Ninguno más que los certificados.
Los certificados son la piedra angular de las conexiones TLS (y más comúnmente HTTPS, que utiliza TLS). Si se equivoca en esto, se expone al riesgo de que un atacante intercepte la conexión (anulando así la protección que proporciona la conexión TLS).
Este blog es parte de una serie que descubrirá el papel de los certificados y, especialmente, la gestión de certificados. En la primera parte, exploraremos el propósito de los certificados y por qué juegan un papel importante en la protección de las conexiones (es decir, las conexiones TLS).
Cuando un cliente se conecta a un servidor hay dos principios de seguridad que debemos tener en cuenta.
Lo primero es la confidencialidad. Esto es fundamental para que los datos transmitidos hacia y desde el cliente no sean visibles para nadie fuera de ese tráfico. Una página de inicio de sesión es un buen ejemplo. Queremos asegurarnos de que el nombre de usuario y la contraseña que ingrese no sean visibles para nadie cuando sean transportados con el servidor al que intenta iniciar sesión. También vale la pena señalar que la confidencialidad también juega un papel en el aspecto de la privacidad, evitando que miradas indiscretas vean qué acciones o información estás viendo.
El segundo principio es la integridad. Este es un aspecto que muchas personas olvidan o no tienen en cuenta cuando se trata de TLS. Por integridad queremos decir que nadie puede manipular los datos que se transmiten hacia y desde el cliente. Incluso si el recurso es público, aún queremos garantizar la integridad de estos datos.
Considere un sitio de noticias de acceso público. No nos preocupa demasiado el aspecto de la confidencialidad (aparte de la privacidad, pero para este ejemplo dejémosla de lado) ya que esta página está disponible públicamente. Sin embargo, queremos asegurarnos de que los datos enviados al cliente (el navegador de un usuario) desde el servidor no hayan sido manipulados. Sin tener en cuenta la integridad de un servidor, un atacante podría editar el contenido de un artículo de noticias (piense en noticias falsas) o inyectar contenido malicioso en la página, como un gancho de Browser Exploitation Framework.
Entonces, ¿qué papel juegan los certificados en todo esto? Cuando un cliente se conecta a un servidor, debe asegurarse de que primero se conecte al servidor previsto. No es un servidor que un atacante haya imitado. También queremos garantizar que la conexión esté cifrada de extremo a extremo. Con esto queremos decir que la conexión no ha sido terminada en algún lugar para permitir la inspección y modificación del tráfico, y reenviada al servidor original. Esto se conoce como ataque de máquina en el medio .
Para que quede claro, existen casos de uso válidos para esto, especialmente en un entorno corporativo donde a menudo se inspecciona el tráfico de Internet para ayudar a mejorar la seguridad de la organización. Aquí es donde entran en escena los certificados. Cuando un cliente se conecta a un servidor TLS, el servidor deberá proporcionar su certificado (de servidor) al cliente. Luego, el cliente validará este certificado para asegurarse de que pertenece al servidor correcto al que el cliente intentaba conectarse originalmente. Una vez establecido esto (una parte del protocolo de enlace TLS), pueden comenzar las comunicaciones entre el cliente y el servidor.
En la próxima parte de esta serie continuaré explorando este tema en mi propio blog. Allí cubriremos el proceso de validación de certificados. Aquí es donde profundizaremos en el lado humano de la gestión de certificados y su importancia.
Hasta entonces, te recomiendo encarecidamente que consultes la sesión informativa de F5 myForum ( Prepárate para el cambiante panorama de SSL ) de David Warburton y Nigel Ashworth. Es una excelente descripción general de los panoramas SSL y TLS en constante evolución y vale la pena dedicarle tiempo.
Sean Wright es un ingeniero de seguridad de aplicação experimentado que comenzó como desarrollador de software. Se centra principalmente en la seguridad de aplicação basadas en web, con un interés especial en TLS y temas relacionados con la cadena de suministro. Sean también tiene experiencia en brindar liderazgo técnico en relación con la seguridad de las aplicação , así como en colaborar con equipos para mejorar la seguridad de los sistemas y aplicações que desarrollan y mantienen. Puedes leer su blog aquí .