Phenquestions
Problemas con HTTP y texto sin formato
Internet es un canal de comunicación que no es de confianza. Cuando envía o recibe información de un sitio HTTP antiguo http: //www.ejemplo.com en su navegador, pueden suceder muchas cosas a la mitad de sus paquetes.
- Un mal actor puede interceptar la comunicación, copiar los datos para sí mismo, antes de reenviarlo nuevamente en el canal hacia usted o el servidor con el que estaba hablando. Sin el conocimiento de ninguna de las partes, la información se ve comprometida. Necesitamos asegurarnos de que la comunicación sea privado.
- Un mal actor puede modificar la información a medida que se envía por el canal. Bob podría haber enviado un mensaje "X" pero Alice recibiría "Y" de Bob, porque un mal actor interceptó el mensaje y lo modificó. En otras palabras, el integridad del mensaje está comprometido.
- Por último, y lo más importante, debemos asegurarnos de que la persona con la que estamos hablando sea realmente quien dice ser. Volviendo al ejemplo.com dominio. ¿Cómo podemos asegurarnos de que el servidor que nos respondió es realmente el titular legítimo de www.ejemplo.com? En cualquier punto de su red, se le puede desviar a otro servidor. Un DNS en algún lugar es responsable de convertir un nombre de dominio, como www.ejemplo.com, en una dirección IP en la Internet pública. Pero su navegador no tiene forma de verificar que la dirección IP traducida del DNS.
Los dos primeros problemas se pueden resolver cifrando el mensaje antes de enviarlo por Internet al servidor. Es decir, cambiando a HTTPS. Sin embargo, el último problema, el problema de la Identidad es donde entra en juego una Autoridad de Certificación.
Inicio de sesiones HTTP cifradas
El principal problema con la comunicación encriptada a través de un canal inseguro es "¿Cómo lo iniciamos??"
El primer paso involucraría a las dos partes, su navegador y el servidor, para intercambiar las claves de cifrado que se intercambiarán a través del canal inseguro. Si no está familiarizado con el término claves, considérelas como una contraseña muy larga generada aleatoriamente con la que se cifrarán sus datos antes de enviarlos a través del canal inseguro.
Bueno, si las claves se envían a través de un canal inseguro, cualquiera puede escuchar eso y comprometer la seguridad de su sesión HTTPS en el futuro. Además, ¿cómo podemos confiar en que la clave enviada por un servidor que dice ser www.ejemplo.com es de hecho el propietario real de ese nombre de dominio? Podemos tener una comunicación encriptada con una parte malintencionada que se hace pasar por un sitio legítimo y no saber la diferencia.
Por lo tanto, el problema de garantizar la identidad es importante si queremos garantizar un intercambio de claves seguro.
Autoridades de certificación
Es posible que haya oído hablar de LetsEncrypt, DigiCert, Comodo y algunos otros servicios que ofrecen certificados TLS para su nombre de dominio. Puedes elegir el que se adapte a tus necesidades. Ahora, la persona / organización propietaria del dominio tiene que demostrar de alguna manera a su Autoridad de Certificación que realmente tiene control sobre el dominio. Esto se puede hacer creando un registro DNS con un valor único en él, según lo solicite la Autoridad de certificación, o puede agregar un archivo a su servidor web, con el contenido especificado por la Autoridad de certificación, la CA puede leer este archivo. y confirme que es el propietario válido del dominio.
Luego, negocia un certificado TLS con la CA, y eso da como resultado una clave privada y un certificado TLS público emitido para su dominio. Los mensajes cifrados con su clave privada pueden luego ser descifrados por el certificado público y viceversa. Esto se conoce como cifrado asimétrico
Los navegadores del cliente, como Firefox y Chrome (a veces incluso el sistema operativo) tienen el conocimiento de las Autoridades de Certificación. Esta información se almacena en el navegador / dispositivo desde el principio (es decir, cuando se instalan) para que sepan que pueden confiar en determinadas CA. Ahora, cuando intentan conectarse a www.ejemplo.com a través de HTTPS y ver un certificado emitido por, digamos DigiCert, el navegador realmente puede verificar que usando las claves almacenadas localmente. En realidad, hay algunos pasos intermedios más, pero esta es una buena descripción general simplificada de lo que está sucediendo.
Ahora que el certificado proporcionado por www.ejemplo.com puede ser confiable, esto se usa para negociar una clave de cifrado simétrica única que se usa entre el cliente y el servidor durante el resto de su sesión. En el cifrado simétrico, se utiliza una clave para cifrar y descifrar y, por lo general, es mucho más rápido que su contraparte asimétrica.
Matices
Si la idea de TLS y la seguridad de Internet le atrae, puede profundizar en este tema profundizando en LetsEncrypt y su TLS CA gratuito. Hay mucho más detalle en todo este galimatías de lo que se indicó anteriormente.
Otros recursos que puedo recomendar para aprender más sobre TLS son el Blog de Troy Hunt y el trabajo realizado por EFF como HTTPS Everywhere y Certbot. Todos los recursos son de acceso gratuito y muy baratos de implementar (solo tiene que pagar el registro del nombre de dominio y los cargos por hora del VPS) y obtener una experiencia práctica.
