HTTPS es HTTP dentro de SSL. SSL es un protocolo de túnel: funciona en un flujo bidireccional de datos existente, y proporciona una Secuencia bidireccional para datos. Las dos partes involucradas en SSL son el cliente y el servidor , que son dos roles dentro del protocolo SSL; no es necesario que estos roles se correspondan con las nociones de "cliente" y "servidor" del protocolo de transporte subyacente.
Por ejemplo, se puede imaginar una configuración, en la que el sistema cliente (C) inicia una conexión TCP con el servidor (S), y luego el servidor inicia un protocolo de enlace SSL, que actúa como el cliente SSL (es decir, enviando el mensaje ClientHello , en lugar de esperar un ClientHello entrante). Esto invierte los roles de ambas máquinas y también las garantías de seguridad: la máquina S tendrá una buena idea de la identidad del cliente C conectado, pero el cliente C no estará seguro de con qué servidor S está hablando (un atacante podría haber interceptado y redirigido la comunicación). Dependiendo del contexto, esto puede o no ser apropiado.
Sin embargo, esto se aparta de HTTPS , en el que el cliente TCP también es el cliente SSL, y ese cliente espera el servidor para mostrar un certificado, que el cliente validará con su CA conocida y confiable, y que contiene el nombre del servidor esperado (extraído de la URL, consulte section 3.1 ). En consecuencia, los clientes existentes (navegador web) no admiten la anulación de roles SSL. Si su situación requiere el uso de navegadores, entonces, por supuesto, debe usar solo la funcionalidad disponible en los navegadores.
SSL admite algunos conjuntos de cifrado sin certificado. Las suites de cifrado "DH_anon" se consideran débiles, ya que no implican ninguna autenticación (por lo tanto, Man-in- Los ataques del medio son posibles). Los conjuntos de cifrado PSK implican la autenticación mutua del cliente y el servidor con respecto a un secreto compartido. Cuando el secreto compartido es de baja entropía (por ejemplo, es una contraseña ), SRP cifrado Las suites son mejores.
Nuevamente, estas suites de cifrado no están (todavía) disponibles en los navegadores principales (aunque algunas personas están trabajando en ello ). Requieren un secreto compartido (clave o contraseña), una condición que puede o no ser fácil de lograr en su contexto específico.
Si el conocimiento de la identidad del servidor no es importante, puede darle al servidor un certificado autofirmado, junto con instrucciones para los clientes sobre cómo hacer que su navegador acepte el certificado del servidor sin encogerse demasiado fuerte (consulte esta pregunta como punto de partida). Esto se asignará a "SSL normal", que tiene dos ventajas:
- Los navegadores existentes lo admiten.
- Cuando el servidor presenta un certificado, aunque sea falso, se le permite solicitar, a cambio, un certificado de cliente , lo que proporciona el tipo de autenticación que está buscando. Y los navegadores web do admiten certificados de cliente para SSL.
Tenga en cuenta que el certificado autofirmado contiene la clave pública del servidor. Aunque esta clave pública no se validará, aún se utilizará para impulsar el intercambio de claves, por lo que debe usar un tipo y longitud de clave adecuados (por ejemplo, RSA 2048). Alternativamente, use uno de los conjuntos de cifrado "DHE", en cuyo caso la clave pública del servidor se usa solo para firmas, no para proteger realmente los datos, por lo que ( en su caso específico ), su tamaño y el secreto ya no es importante.