OpenID sin certificado SSL

Sería más seguro para el usuario OpenID si el sitio que está ingresando no es compatible con SSL que usar un nombre de usuario y una contraseña. Mientras el proveedor de OpenID proporcione SSL, todo lo que se enviará de forma clara (es decir, que un hombre del medio podría obtener) sería la presentación del ticket que indica que usted es quien dice que es al servidor.

Solo sería útil para alguien que intenta comprometer su cuenta en el sitio no seguro en el que está iniciando sesión. Dependiendo de la configuración, es probable que no puedan volver a usar el ticket para iniciar sesión en el futuro, donde una combinación de nombre de usuario y contraseña podría usarse indefinidamente en el futuro.

Solo quería corregir este error:

  

Solo para aclarar las cosas, no es posible instalar un certificado SSL porque no hay una dirección IP dedicada para el alojamiento web.

Si bien esto puede ser lo que su proveedor de alojamiento le ha dicho, no es una propiedad fundamental de SSL / TLS y en la mayoría de los entornos de alojamiento no es cierto.

La idea errónea se deriva del hecho de que el encabezado Host: de una solicitud HTTP está cifrado dentro del flujo SSL y, por lo tanto, durante muchos años, la única forma de distinguir qué certificado SSL se debe usar en un servidor que aloja múltiples sitios web es tener una dirección IP por certificado SSL.

Para solucionar este problema, SNI se creó como una extensión de SSL / TLS. Si tanto el cliente como el servidor admiten SNI, cualquier número de certificados SSL se puede entregar desde una única dirección IP. SNI fue la primera práctica en 2008 y es bastante compatible en estos días, pero debe verificar los clientes que realmente ve en su sitio web en la lista de clientes que lo respaldan en el artículo de Wikipedia.

Si se realiza una solicitud en la que el servidor o el cliente no son compatibles con SNI, el comportamiento de Apache es elegir el primer certificado SSL en su configuración y usarlo. Esto provocará una advertencia en el navegador, pero si el usuario decide ignorar la advertencia, aún se realizará una conexión cifrada, aunque se negocie con el certificado incorrecto.

En aras de la precisión / integridad, en el caso anterior, alguien que tuviera acceso a la clave privada del certificado SSL predeterminado en su configuración de Apache sería posible, pero dado que requerirían privilegios de root en la misma casilla donde se encuentra cert está almacenado No veo esto como una amenaza significativa. Enseñar a sus usuarios a ignorar las advertencias de falta de coincidencia del servidor SSL no es una buena práctica y sugerir que se actualicen a un navegador / sistema operativo más moderno es mucho mejor desde una perspectiva de seguridad.