Función de inicio de sesión seguro con bajo poder de CPU

HTTPS no es demasiado pesado para un RPi, son sorprendentemente poderosos y SSL es muy liviano en términos de CPU y uso de memoria. Lo he visto implementado en microcontroladores Atmega de 40MHz.

Si no me crees, considera el hecho de que puedes SSH en un RPi sin ningún problema.

SSL será bastante pesado en un procesador Pi ARM en comparación con las conexiones HTTP de vainilla. Cuando los procesadores normales del servidor tenían 1Ghz, probé el rendimiento de SSL con varios aceleradores de hardware SSL en ese momento. Normalmente, SSL bajaría al 15% del rendimiento de HTTP de vainilla para Apache, IIS, etc. en ese momento.

SIN EMBARGO. Es el protocolo de enlace SSL, es decir, en la conexión, que utiliza la CPU. Entonces, si puede minimizar esto, entonces el uso general de la CPU será un problema menor.

Hay dos estrategias:

1. traza el modelo de rendimiento para tu aplicación. Si los clientes están creando nuevas conexiones SSL todo el tiempo, puede sufrir problemas de rendimiento. Quizás considere mantener sesiones más largas entre solicitudes y esto reducirá la carga.
2. Utilice SSL mutuamente asegurado, es decir, con certificados del lado del cliente. Esto reduce la carga de la CPU en la conexión a cerca de la de HTTP de texto plano de vainilla.

SSH parece funcionar bastante bien con mi Pi (pero no es aplicable en este escenario)

Sé de un procesador PowerPC de 50 MHz que ejecuta un servidor SSL y maneja rutinariamente 70 clientes simultáneos; Yo mismo escribí el código. SSL es no pesado. Además, toso y grito cuando escucho que un procesador de 1 GHz es "lento": una Raspberry Pi habría sido una estación de juego totalmente radical en 2001, e Internet ya existía en ese momento ...

Si tienes algo de fetiche sobre los ciclos de CPU, entonces la buena idea aún es no para diseñar tu propio protocolo. En su lugar, use un SSL correctamente configurado (por ejemplo, con curvas elípticas para la criptografía asimétrica).

Básicamente estás implementando un sistema de sesión. Lea más acerca de cómo asegurarla en enlace y enlace . Básicamente, desea evitar el secuestro de sesiones y los ataques de reproducción. Una de las defensas es vincular la sesión a la dirección IP de un cliente y requerir una nueva autorización si la dirección IP cambia. Busca más en la web, la palabra clave es "secuestro de sesión".

Para mayor seguridad, necesita usar HTTPS. Puede minimizar la cantidad de recursos que utiliza HTTPS (SSL / TLS) durante el intercambio mediante el uso de certificados RSA de 1024 bits en lugar de los estándares de 2048 bits. Para el cifrado simétrico, use RC4 en lugar de AES, porque RC4 usa menos CPU, lo que probablemente es la razón por la que Google lo está usando, aunque eso debería cambiar pronto con el soporte de AES-NI.

Alternativamente, puede configurar un proxy que permita que los clientes entrantes se conecten al proxy a través de HTTPS, y luego el proxy puede realizar el cifrado / descifrado, y obtener los datos reales del Pi: esto permite que el Pi se enfoque en el aspectos no relacionados con la seguridad y descargue el HTTPS si ese es el problema, tenga en cuenta que esto requiere una red "segura" entre el Pi y el proxy si lo necesita para estar realmente seguro.