Seguridad de las Comunicaciones de Datos

Cómo Funciona la Comunicación Segura

Pasos:

1. La CA genera el certificado del servidor (srv.crt) con la clave pública (paso previo ya hecho).
2. El cliente se conecta al servidor y recibe el certificado del servidor.
3. El cliente verifica que el certificado del servidor ha sido firmado por una autoridad de certificación (CA) válida.
4. El cliente cifra la comunicación con la clave pública del certificado ya validado.
5. La comunicación cifrada sólo puede ser descifrada con la clave privada del servidor que en ningún momento ha salido del servidor.

Más información:

• https://mcuoneclipse.com/2017/04/14/introduction-to-security-and-tls-transport-security-layer/ 
• http://www.steves-internet-guide.com/ssl-certificates-explained/ 

Instalar Certificado

Instalar certificado TLS/SSL confiado de Lets Encrypt:

• https://letsencrypt.org/es/
• Getting started Lets Encrypt: https://letsencrypt.org/es/getting-started/ 
• Como funciona Lets Encrypt: https://letsencrypt.org/es/how-it-works/ 
• Apache seguro en CentOS 8 https://www.digitalocean.com/community/tutorials/how-to-secure-apache-with-let-s-encrypt-on-centos-8 
• Automatizar la renovación del certificado: https://www.digitalocean.com/community/tutorials/how-to-use-cron-to-automate-tasks-centos-8 

Certbot simplifica todo el proceso: https://certbot.eff.org/ 

Instrucciones certbot: https://certbot.eff.org/instructions 

Certbot en CentOS 8: https://certbot.eff.org/lets-encrypt/centosrhel8-other 

Más información:

• https://www.digitalocean.com/community/tutorials/how-to-use-certbot-standalone-mode-to-retrieve-let-s-encrypt-ssl-certificates-on-ubuntu-16-04 
• https://www.howtoforge.com/how-to-manage-lets-encrypt-ssl-tls-certificates-with-certbot/ 

Instalar: 

• sudo yum install epel-release
• yum install certbot

Solo certificado: certbot certonly –standalone

Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/midominio.com/fullchain.pem

   Your key file has been saved at:
   /etc/letsencrypt/live/midominio.com/privkey.pem

   Your cert will expire on 2021-02-04. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"

Solo con certbot certonly –standalone ya me genera el certificado.

Para renovar hacer: certbot renew

Interesante nodo de lets encrypt para solicitar y renovar certificados: https://github.com/bartbutenaers/node-red-contrib-letsencrypt 

Mejores prácticas

Utilice siempre TLS si puede

Utilice siempre TLS si puede permitirse el ancho de banda adicional y sus clientes tienen suficiente potencia de cálculo y memoria para TLS. Como regla general, utilice siempre canales de comunicación encriptados, también para otros protocolos como HTTP, MQTT, etc…

Utilizar la versión TLS más alta posible

Aunque TLS 1.0, TLS 1.1 y TLS 1.2 no están rotos en la práctica (al menos hasta ahora), siempre debe utilizar la versión más alta de TLS que sea factible para sus clientes. Existen ataques conocidos contra TLS 1.0 y 1.1, que pueden ser mitigados. Algunos ataques están diseñados para explotar HTTP.

En mosquitto, apachem etc.., se puede elegir la versión de TLS a usar en la configuración.

No utilice SSLv3

No utilice SSLv3 ni ninguna versión anterior. El ataque a POODLE demostró que SSLv3 debe ser considerado roto. Todas las demás versiones de SSL también se consideran rotas y no deben utilizarse.

Siempre validar la cadena de certificados X509

Para evitar ataques Man-In-The-Middle, haga que sus clientes (MQTT, HTTP, etc…) validen el certificado X509 del servidor. Algunas implementaciones de clientes descuidadas utilizan un enfoque “allow-all» (a menudo en combinación con certificados de servidor autofirmados). Siempre vale la pena hacer un esfuerzo adicional para validar los certificados.

Utilizar certificados de las autoridades de certificación de confianza

Los certificados de las autoridades de certificación de confianza valen el dinero extra que cuestan. Los certificados autofirmados no se adaptan bien a muchas implementaciones de TLS y a menudo conducen a un código erróneo. Por ejemplo, código que no valida los certificados y abre la puerta a los ataques Man-In-The-Middle.

Si su broker de MQTT es público, un certificado de confianza es imprescindible. Si utiliza MQTT sobre sockets web, los certificados autofirmados no son óptimos. La mayoría de los navegadores web modernos no permiten conexiones de sockets web a recursos con certificados no confiables.

Utilizar otros mecanismos de seguridad

Además de TLS, siempre es una buena idea utilizar otros mecanismos de seguridad como el cifrado de la carga útil, las verificaciones de la firma de la carga útil y los mecanismos de autorización. En general, más seguridad nunca hace daño.

Utilice sólo suites de cifrado seguro

Hay muchas suites de cifrado inseguras disponibles para TLS. Asegúrese de permitir únicamente suites de cifrado seguras para su comunicación. Se sabe que muchas suites de cifrado están rotas y no tienen una falsa sensación de seguridad.

Cipher Suite:

• https://www.deacosta.com/que-es-un-conjunto-de-cifrado-cipher-suite-y-como-funciona-en-ssltls/
• https://www.flu-project.com/2020/09/suites-de-cifrado-tlsssl-parte-i.html
• https://www.ssl.com/es/c%C3%B3mo/elija-las-suites-de-cifrado-adecuadas-en-schannel-dll/ 
• https://blog.isecauditors.com/2020/10/la-importancia-de-las-suites-de-cifrado-en-las-comunicaciones.html 

Más información: https://www.hivemq.com/blog/mqtt-security-fundamentals-tls-ssl