¿Es posible usar una clave GPG o SSH para la autenticación basada en web de forma segura?

Para una aplicación web, el problema principal es que el código del sitio web (Javascript en un navegador) no puede leer ni escribir archivos a voluntad. Bueno, en general, esto es más una bendición que un problema, pero aquí significa que el código Javascript no podrá acceder a las claves privadas SSH o PGP.

Hay cosas que se pueden hacer, dependiendo de la cantidad de expertos en tecnología que posean y de la cantidad de operaciones manuales que tolerarán:

• Puede usar una extensión de navegador instalada localmente que acceda a las claves privadas SSH o PGP en nombre del sitio web. Preferiblemente, es recomendable algún control del usuario: realmente no queremos un navegador que firme las cosas solo porque un sitio web dice que lo haga.

• El servidor puede actuar como un servidor SSH y requiere que los clientes se conecten con SSH y la autenticación de cliente basada en claves. El usuario ejecutaría SSH en modo "SOCKS proxy". El propio servidor web solo escucharía a localhost , es decir, será inalcanzable, excepto a través de un proxy local. En este modo, el servidor web incluso podría ser HTTP, no HTTPS; Esto realmente sería reemplazar SSL con SSH. En el lado del servidor, realizar un seguimiento de los usuarios debe usar mod_ident o algo similar (el servidor SSH sabe quién es el cliente, pero la información debe enviarse al servidor HTTP; afortunadamente, esto está en la misma máquina, por lo que se puede usar la identidad de nivel Unix).

• El sitio web podría mostrar un "desafío" como un archivo descargable con contenido aleatorio. El usuario obtiene el archivo, lo firma con GnuPG y pega la salida (ASCII-blindada) en un campo de texto en el sitio web. El servidor verifica la firma y la acepta como autenticación del usuario (siempre que el servidor ya conozca la clave pública del usuario). Clunky, pero funciona.

Una variante basada en correo de lo anterior puede ser recomendable, ya que las implementaciones de PGP a menudo están integradas en el software de correo electrónico, y también porque abre la posibilidad de no tener que confiar en una CA raíz externa. Se vería así:

• El usuario se conecta al servidor web con HTTPS. El servidor utiliza un certificado autofirmado. El navegador lo advierte (la "advertencia de miedo roja") pero permite que el usuario proceda.

• En el sitio, el usuario ingresa su nombre. Luego, el servidor envía un correo electrónico firmado y cifrado (con PGP) al usuario; el correo electrónico firmado contiene un nonce aleatorio y también una copia de la huella digital del certificado SSL del servidor. La fuente aleatoria también se imprime en el sitio web.

• El usuario verifica la firma PGP en el correo electrónico del servidor, luego verifica que la huella digital coincida con la que puede ver desde su navegador; esto convence al usuario de que está viendo el certificado original del servidor, por lo que no hay Man-in-the- Ataque medio . (Aquí es donde reemplazamos el sistema de CA X.509 con la validación basada en PGP).

• El usuario también verifica que el nonce que se muestra en el sitio web coincida con el que ve en el correo electrónico (esto es importante).

• El usuario responde al correo electrónico devolviendo su contenido, esta vez firmado con su propia clave privada PGP, y cifrado con la clave pública del servidor. El servidor verifica ese correo electrónico y, por lo tanto, sabe que el valor deseado fue recibido por el usuario deseado.

• El servidor envía el valor de nonce como una cookie al navegador del usuario. Esto permite navegar sin molestar al usuario con más rondas de autenticación. Es responsabilidad del servidor decidir cuánto tiempo aceptará la cookie como un token de autenticación válido.

En el esquema anterior, es importante tener en cuenta que al enviar su respuesta por correo electrónico, el usuario realmente está autorizando al servidor a asumir que quien sea que regrese con el nonce (como se incluye en el correo electrónico) es realmente el usuario. Por eso es importante verificar manualmente que el nonce coincida con lo que se muestra en la página web.

  

¿Es posible usar pares de claves OpenPGP / SSH para autenticarse con una aplicación web de manera segura para reemplazar a los tradicionales?   autenticación basada en contraseña?

Sí. Es bastante posible.

  

Si es posible, ¿cómo serán los pasos de autenticación? ¿Existe tal vez una buena implementación de esta idea para lenguajes y plataformas populares como Ruby, .NET, Java o Python?

Vea mi respuesta para la siguiente pregunta.

  

Si no es posible, ¿cuáles son las razones? ¿Existe tal vez una restricción en los navegadores web que acceden al llavero GPG o la clave SSH?   archivo?

El procesamiento de claves SSH y OpenPGP en una aplicación web es posible con bibliotecas de terceros (especialmente bibliotecas C o Java debido a su rica ecología), pero se perdería el aprovechamiento de la solución existente más común: SSL / TLS.

La mejor opción sería que los usuarios generen un certificado de cliente X509 firmado por su servidor para autenticarse, ya que entonces su aplicación web simplemente puede confiar en el contenedor web (Catalina Tomcat, ApacheD, IIS, etc.) para realizar un cifrado sin problemas y autenticación para su aplicación.

Bajo el capó, las claves OpenPGP tienen los mismos exponentes RSA que un certificado X509, por lo que las herramientas como openssl pueden convertir claves GPG / PGP en certificados * X509 autofirmados; lo mismo para claves SSH .

_{* OpenPGP web-of-trust califica como 'autofirmado' desde el punto de vista de X509 porque X509v3 no puede tener una cadena de confianza con múltiples raíces, hasta donde he podido determinar.}

Las respuestas existentes ofrecen un buen consejo: en su lugar, utilice la pila SSL en el navegador.

Sin embargo, en realidad es posible hacer exactamente lo que se desea: mediante la criptografía de JavaScript.

Hay una implementación de OpenPGP en JavaScript enlace No puedo responder por su calidad.

Además, es posible que HTML5 JavaScript acceda a archivos locales, por ejemplo, enlace

Creo que esto sería más una curiosidad que un sistema práctico.