Si tengo un sitio web o una aplicación móvil, se comunica con el servidor a través de una conexión segura SSL / TLS (es decir, HTTPS) y también cifra los mensajes enviados y recibidos entre el usuario y el servidor, además de la conexión ya segura ¿Estaré haciendo movimientos innecesarios? ¿O es el cifrado doble un método común? Si es así, ¿por qué?
No es infrecuente, pero puede que no sea necesario. Parece que muchos desarrolladores olvidan que el tráfico HTTPS ya está cifrado (solo mire la cantidad de preguntas sobre la implementación del cifrado del lado del cliente en este sitio web) o siente que no se puede confiar debido a problemas bien publicitados como el href="https://en.wikipedia.org/wiki/Superfish"> Lenovo SSL MitM mess .
Sin embargo, la mayoría de las personas no se vieron afectadas por esto, y no hay ningún ataque particularmente viable contra TLSv1.2 en este momento, por lo que realmente no agrega mucho.
Por otro lado, hay razones legítimas para cifrar los datos antes de la transmisión en algunos casos. Por ejemplo, si está desarrollando una aplicación de almacenamiento, es posible que desee encriptar utilizando una aplicación en el lado del cliente con una clave que solo el usuario conozca, lo que significa que el servidor no podrá descifrar los datos. pero todavía podría almacenarlo. El envío a través de HTTPS significaría que un atacante tampoco debería poder capturar los datos cifrados del cliente, pero incluso si lo hicieran, no importaría. Este patrón es a menudo utilizado por los administradores de contraseñas basados en la nube.
Esencialmente, depende de contra qué te estés defendiendo; si no confías en SSL / TLS, probablemente tampoco puedas confiar en el código de cifrado que estás enviando (en el caso de la aplicación web).
HTTPS solo proporciona cifrado mientras el mensaje está en tránsito a través de la red / internet.
Si el mensaje es almacenado o procesado por un intermediario (por ejemplo, una cola de mensajes) en algún punto entre el cliente y el servidor que finalmente lo procesa, no permanecerá cifrado mientras esté en el intermediario.
Además, si el TLS / SSL finaliza en los perímetros del servicio (por ejemplo, en un equilibrador de carga), es posible que no esté cifrado en la red interna. Esto puede ser un problema donde se requiere alta seguridad, por ejemplo, en algunos entornos regulados.
En ambos casos, el cifrado a nivel de mensaje garantizará que los datos se cifren en todos los puntos entre el cliente y el receptor final.
Como dijo @honze, esto se denomina defensa en profundidad y está destinado a garantizar que incluso si un sistema está parcialmente comprometido (por ejemplo, logran realizar un ataque de hombre en el medio para comprometer el SSL / TLS, o explotar una vulnerabilidad en la cola de mensajes para obtener los datos en reposo) el atacante no puede obtener los datos protegidos.
Me gustaría compartir mi experiencia en la pregunta del título. No está realmente relacionado con la pregunta completa en sí, pero esto responde a la pregunta "¿por qué alguien cifraría dos veces?"
Anteriormente trabajé para una organización que maneja la comunicación entre los proveedores de atención (médicos, hospitales, etc.) y las organizaciones aseguradoras (mutualidades). Nos comportamos como un enrutador.
El esquema era aproximadamente el siguiente:
care provider 1 \ / insuring organization 1
care provider 2 ---- router (us) ---- insuring organization 2
care provider 3 / \ insuring organization 3
Teníamos la siguiente protección:
Espero que esto arroje algo de luz sobre por qué se pueden requerir varias capas de cifrado.
HTTPS se cifra en tránsito y se descifra en los extremos. Por lo tanto, la situación obvia en la que podría querer cifrar dos veces es cuando no quiere uno (o posiblemente ambos) de los extremos para ver el texto claro.
Algunas situaciones en las que puedo pensar desde lo alto de mi cabeza:
correo electrónico cifrado a través de proveedores de correo web. Si envío un mensaje GPG cifrado a través de Gmail al que accedo a través de una conexión HTTPS, se cifrará dos veces. Porque no quiero que gmail lea el contenido.
servicios de copia de seguridad cifrados. Quiero usar HTTPS para evitar que me roben las credenciales de inicio de sesión, pero no quiero que el servicio de copia de seguridad vea "dentro" de las copias de seguridad.
pasarelas de pago. Podría imaginar uno donde se envía un mensaje cifrado entre un token de hardware de pago seguro y un banco, a través de el dispositivo inseguro de un usuario y el sitio de un comerciante. El enlace en el medio debe ser HTTPS, pero eso no es suficiente: debe estar cifrado en la PC insegura y en el sitio web del comerciante menos seguro.
Tenga en cuenta que S / MIME proporciona "triple envoltura" (firmar / cifrar / firmar): enlace , así que si considera que firmar y cifrar aún más posibilidades pueden tener sentido.
Quería dar una razón adicional: la estandarización.
Tengo una aplicación que, por razones de seguridad, todos los datos que entran y salen de ella deben estar cifrados. Debido a que ya está encriptado una vez, se permite que los datos fluyan a través de las conexiones http (heredadas) y https (actuales). Tiene mucho más sentido cifrar dos veces que crear una versión de la aplicación que se ejecuta sin cifrar en https y cifrada en http.
Son las mejores prácticas cuando se trata de información altamente confidencial, como datos financieros, médicos, militares o psicológicos. La idea básica de los cifrados múltiples es evitar que cualquier usuario no autorizado recupere los datos. Supongamos que las posibles combinaciones iniciales para el método de encriptación fueran 1 billón. Al aplicar otro método de cifrado encima de él, podríamos multiplicar las posibilidades para 1b ^ 3. Se requeriría que un usuario no autorizado demore más en descifrar los datos. Si bien el cifrado aún no es perfecto, es mejor.
En una de las organizaciones en las que trabajé, utilizamos varios cifrados. Esta es una simplificación del flujo anterior:
Si no está lidiando con un entorno que está lleno de datos confidenciales en la red, esto es una exageración.
La estrategia detrás de este método garantiza que los dispositivos, los componentes (MAC) y la IP se hayan autenticado. El cifrado de datos es un procedimiento estándar y también lo es el envío a través de HTTPS. Algunas organizaciones van más allá de la seguridad básica y también requieren redes de tipo darknet que utilizan Freenet, I2P, IPsec / VPN o Tor para conectarse. Independientemente del cifrado, la compresión de datos reducirá los recursos de almacenamiento y de red necesarios; Sin embargo, compensará su rendimiento a RAM o procesamiento. Finalmente, la razón por la que reiniciamos la conexión después de una desconexión es que descubrimos una forma de secuestrar el flujo de datos a través de la persona en el medio.
En última instancia, no hay una manera perfecta de cifrar los datos para siempre, pero enfoca sus esfuerzos para cifrarlos hasta que los datos o la información se vuelvan irrelevantes o usted produzca una forma superior de cifrar los datos.
Hay varias razones para enviar datos cifrados a través de una conexión cifrada:
Incluso si toda la comunicación está cifrada a través de HTTPS, el cliente todavía puede tener la opción de ver su tráfico antes del cifrado con varias herramientas de depuración. Especialmente si utiliza un entorno de navegador o una aplicación con https provistos por un sistema subyacente.
En este caso, podría cifrar sus datos con una clave estática, por lo que el cliente no puede leer y manipular fácilmente el tráfico. Por supuesto, esto solo es una ofuscación, ya que la clave debe almacenarse en algún lugar de la máquina del cliente (al menos en la memoria RAM), pero con el código fuente del software siempre es solo una ofuscación. El usuario tendría que hacer un esfuerzo considerable para recuperar su clave y descifrar su tráfico para leer y manipular sus solicitudes.
Los ejemplos podrían ser un juego basado en la web, que presenta la puntuación más alta de los jugadores.
Si entendí correctamente, la red del enrutador de cebolla (TOR) funciona de esa manera:
Alice escribe una carta a Dave y la cifra tres veces: primero con la clave de Dave, luego agrega la dirección de Dave, cifra el paquete con la clave de Craigs, agrega la dirección de Craig y cifra el paquete con la clave de Bob.
Luego envía la carta a Bob, quien la desencripta, encuentra la dirección de Craig y se la envía a él.
Craig lo descifra, encuentra la dirección de Dave y se la envía a él. Dave lo desencripta y encuentra que la carta es para él
En un mundo perfecto, nadie, excepto Alice y Dave, ahora podría decir que Dave es el destinatario de esa carta, porque PODRÍA ser que había encontrado la dirección de Emily dentro del sobre y la había enviado.
Una segunda aplicación sería cifrar un mensaje tanto con su clave privada como con la clave pública del destinatario. El destinatario descifra el mensaje con su clave pública y su clave privada y, por lo tanto, puede obtener la información de que el mensaje es suyo y para él. Pero, por lo general, se usa un HMAC para asegurarse de que el mensaje proviene de un determinado remitente y no se ha manipulado.
La razón principal para el cifrado de múltiples niveles es la separación de la preocupación.
A menudo, un conjunto de datos puede ser procesado por múltiples servidores, posiblemente controlados por múltiples organizaciones, no todos los cuales son completamente confiables con todos los datos. En la mayoría de los casos, la mayoría de estos servidores intermedios solo necesitan actuar sobre partes de los datos, por lo que si no necesitan ver algunas partes de los datos, esa parte se puede cifrar. Daría el acceso intermedio a los datos que necesitan para ver encriptados en una clave que tienen y los blob (s) encriptados que pueden pasar a otros servidores para su posterior procesamiento.
El ejemplo más simple es el correo electrónico con cifrado GPG y TLS. El trabajo principal de un agente de transferencia de correo (retransmisiones de correo electrónico) es transferir el correo electrónico de un salto al siguiente. Necesitan ver la información de enrutamiento del correo para hacer su trabajo, pero no necesitan ver los mensajes en sí. De este modo, cifraría dos veces la conexión de correo electrónico con una clave que el agente de transferencia de correo pueda entender y el mensaje con otra clave que solo el destinatario entiende.
Otro ejemplo es el servicio de programación de calendario / notificación. Usted coloca eventos en su calendario, para ser notificado por su aplicación de calendario de que algo está sucediendo en un momento determinado. El calendario no tenía necesidad de saber qué es el evento, quiénes participan en los eventos ni dónde se encuentra el evento.
Una razón secundaria para el cifrado múltiple es como un seguro en caso de que se rompa una de las capas de cifrado. En mi opinión, esta es una razón mucho más débil porque debe considerar que cada capa adicional innecesaria aumenta la complejidad de la implementación y la complejidad es el enemigo de la seguridad.
No veo esto aquí mencionado, pero creo que es un poco más importante que un comentario. Podrían hacerlo para secreto hacia adelante perfecto . Es posible que un atacante no sepa la clave de su conexión HTTPS, pero puede registrar cada byte y almacenarlo durante años. Luego, pueden atacarle por la línea, descubrir una vulnerabilidad o obligarlo a revelar la clave privada de su servidor más tarde, luego volver al historial y descifrar sus mensajes. Al tener una clave efímera temporal que encripta mensajes debajo de la conexión HTTPS, el atacante aún no podrá lea los mensajes, o por lo menos significativamente retrasado.
Es probable que existan fallas tanto en los algoritmos como en las implementaciones en este momento, que aún no se han descubierto. Idealmente, estas fallas no existirían pero sí.
Si cifras con dos algoritmos diferentes y solo uno de ellos tiene fallas, todavía estás bien y tus datos están seguros. Si la primera capa está rota, entonces un atacante solo puede obtener texto cifrado. Si la segunda capa está rota, un atacante no puede atravesar la primera capa.
El doble cifrado (o triple o cuádruple o ...) puede ser una buena manera de evitar poner todos sus huevos en una canasta.
Para evitar problemas con el cumplimiento de PCI, donde el desarrollador desea utilizar la pasarela de pago y asigna la responsabilidad de cumplimiento a la tercera parte.
Los campos en la publicación de formulario pueden ser del lado del cliente cifrado, por lo que el desarrollador no tiene datos de tarjetas sin cifrar que pasen por sus sistemas (por lo que es un paso más que no almacenarlos).
Notablemente, esto está por encima de HTTPS . Por lo tanto, el sitio web ni siquiera ve los datos sin cifrar, solo el usuario y la pasarela de pago.
Ejemplo con la pasarela de pago Brain Tree: enlace
No es exactamente un problema de HTTPS, pero otro caso de uso válido de doble cifrado se usa comúnmente en Tor en caso de que "no crea al encargado de la entrega y quiera permanecer en el anonimato usando más pasos".
Cada "repartidor" desencripta solo el sobre para descubrir al otro repartidor. La comunicación en este caso está encapsulada y encriptada en el proxy SOCKS.
Lea otras preguntas en las etiquetas encryption tls