¿Enviando datos confidenciales a través de HTTPS y no datos confidenciales a través de HTTP?

Question

¿Enviando datos confidenciales a través de HTTPS y no datos confidenciales a través de HTTP?

#1 de Anders (6 votos)
#2 de Rápli András (4 votos)

0

Se me ocurrió una idea acerca del uso del cifrado solo para datos confidenciales al transferir datos.

Aquí hay un ejemplo: cuando abres una página web, puedes ver muchas cosas a las que otros usuarios pueden acceder. Pero una pequeña parte de la información en un sitio web es específica del usuario, que debe ser protegida. Usted envía y recibe estos datos a través de un canal protegido, todos los demás se redirigen a los canales normales (no protegidos).

Con eso podemos tener menos gastos generales causados por el cifrado.

¿Es esto factible y seguro? ¿Ya se ha hecho esto?

EDITAR: Entiendo por los comentarios que usar dos canales es una mala idea. Tengo otra idea: usted asegura los datos no confidenciales con un algoritmo de cifrado menos exigente computacional. Con datos confidenciales utiliza un algoritmo computacional más exigente que proporciona una mejor seguridad. Los datos se envían a través de un solo canal.

tls performance

pregunta Theory 03.01.2017 - 14:57

fuente

2 respuestas

4

El cifrado / descifrado / separación de datos sensibles / no confidenciales en su aplicación probablemente cause más sobrecarga de lo que HTTPS causaría. ¡No reinventes la rueda! En 2017, la elección de la protección TLS causa una sobrecarga tan insignificante relacionada con los precios del ancho de banda del servidor o del usuario, que ni siquiera vale la pena mencionarlo.

respondido por el Rápli András 03.01.2017 - 15:38

fuente

Lea otras preguntas en las etiquetas tls performance

Hacer la clave pública irrecuperable dada la clave privada ¿Por qué el sistema de archivos de Linux se considera DAC y no MAC?

score 6 · Accepted Answer

Esta es una mala idea.

Los datos sin cifrar no solo pueden ser leídos por un hombre en el medio. También puede ser modificado. Por lo tanto, si solo una pequeña parte de su HTML no está cifrado, un atacante puede insertar JavaScript malicioso que lee los datos confidenciales una vez que se descifra en el navegador. Boom, todo el cifrado es derrotado.

Esto también es, por cierto, la razón por la que necesita servir a todo su sitio y no solo la página de inicio de sesión a través de HTTPS .

En cuanto a su segunda idea, realmente no ayuda nada con el rendimiento, pero tiene el mismo tipo de implicaciones preocupantes para la seguridad que su primera idea. El contenido en su conjunto no es más seguro que el enlace más débil.

Entonces, ¿por qué no ayuda con el rendimiento? La razón principal por la que Crypto puede afectar el rendimiento es que complica el cambio. Crypto más débil no resolvería eso. Puede haber algún algoritmo que sea un poco más rápido que, por ejemplo, AES-128, pero menos seguro, pero sería una ganancia muy marginal en el rendimiento que paga en términos de seguridad.

Y ni siquiera he mencionado todo el trabajo que tendrías que realizar para separar los datos "confidenciales" de los "no sensibles" ...

Editar: Uno no debe ser categórico ... Si eres, por ejemplo. programando un juego, es posible que desee enviar los datos del juego en tiempo real (quién dispara qué) a través de algo rápido como un TCP sin cifrar, mientras que usted tiene una conexión HTTPS separada para, por ejemplo. enviando nombre de usuario y contraseña al servidor. Pero eso está bastante lejos del caso de uso de la página web HTTP.