En primer lugar, intente comprender cómo funciona la autenticación SSL (HTTPS) y HTTP.
Los métodos de autenticación HTTP habituales (resumen, básico y cualquier esquema de autenticación basado en formularios + cookies que puede implementar sobre HTTP) son inseguros por sí mismos, ya que envían información de autenticación más o menos en texto claro. Si los datos están en campos POST o encabezados, y si se aplica la codificación base64, no importa en absoluto a este respecto, la contraseña es claramente visible para cualquier persona con acceso al tráfico de red. Esto significa que la autenticación HTTP a través de un canal que no es de confianza no tiene valor: todo lo que necesita un atacante para leer su contraseña es detectar un poco la red.
SSL implementa un canal de comunicación seguro sobre un canal inherentemente inseguro. Esto funciona, más o menos, de la siguiente manera:
- El servidor envía un certificado firmado
- El cliente valida el certificado con una lista de claves de firma reconocidas; las firmas de certificados se pueden encadenar, de modo que cada nodo diga "si la firma que me firma es buena, entonces yo también lo soy", pero en última instancia, la cadena debe resolverse ante una de las pocas autoridades confiables preconfiguradas en el cliente.
- El cliente usa la clave de cifrado pública del servidor para enviar un secreto compartido
- El servidor descifra el secreto compartido usando la clave privada (porque solo el servidor legítimo tiene la clave privada, otros servidores no podrán descifrar el secreto compartido)
- El cliente envía datos de solicitud reales, encriptados usando el secreto compartido
- El servidor descifra los datos de la solicitud y luego envía una respuesta cifrada
- El cliente descifra la respuesta y se la presenta al usuario.
Tenga en cuenta algunos puntos importantes aquí:
- La cadena de certificados permite a los clientes asegurarse de que el servidor con el que están hablando es el real, no que alguien intercepte sus solicitudes. Esta es la razón por la que debe comprar un certificado SSL real, y por qué los navegadores le lanzan advertencias espeluznantes cuando visita un sitio que usa un certificado no válido, caducado o incorrecto: todo el cifrado en el mundo no ayuda si está hablando con la persona equivocada.
- El cifrado público / privado utilizado para intercambiar el secreto asegura que la comunicación exitosa solo funcione entre este par particular de cliente y servidor: los paquetes de red rastreados se cifrarán y requerirán la clave privada del servidor para obtener los datos.
- El cifrado simétrico se utiliza para la mayor parte de la solicitud, ya que tiene una sobrecarga de rendimiento mucho menor que el cifrado de clave privada / pública. Sin embargo, la clave (secreto compartido) se intercambia mediante el cifrado de clave privada / pública, porque esa es la única forma de hacerlo de forma segura (excepto transportándola a través de un canal separado, como un servicio de mensajería).
Obviamente, hay algunos gastos generales involucrados, pero no es tan malo como parece: es principalmente en la escala donde "arrojar más hardware" es la respuesta adecuada, a menos que se esté preparando para cantidades de tráfico absolutamente masivas ( piensa en Google o Facebook). En circunstancias normales, es decir, el uso típico de aplicaciones web, la sobrecarga de SSL es insignificante y, en consecuencia, tan pronto como tenga datos confidenciales, es mejor ejecutar todo a través de SSL, incluidos los recursos. SSL también es la única forma viable de proteger el tráfico HTTP; otros métodos simplemente no están tan estandarizados y, por lo tanto, no son ampliamente compatibles, y absolutamente no desea implementar estas cosas usted mismo, porque honestamente, es demasiado fácil equivocarse.
TL; DR: Sí, SSL Autenticación + básico es una idea buena, sí, se necesita un servidor seguro (y un certificado válido ), sí, va a frenar las cosas un poco, pero no, esto no es algo que preocuparse por la derecha ahora.