PHP OpenID no funciona con Google / Yahoo y arreglar 'hacks' ... que son seguros?

Question

He estado experimentando con OpenID, y han creado una página web de ejemplo para el acceso usando mi cuenta de OpenID. Estoy usando el Php Biblioteca de OpenID por JanRain y no estaba trabajando con mi Google Cuenta. Un poco de investigación me llevó a esta pregunta , lo que sugiere que el problema es que Google utiliza https y ...

  

... es probable que la instalación para realizar las solicitudes HTTPS se borked en su servidor PHP. Asegúrese de que ha instalado el paquete ca-certificados.

En el mismo hilo, alguien enlaces a su versión hackeada del biblioteca que desplegué y han utilizado con mi cuenta de Google con éxito. Otras preguntas tienen otras personalizaciones de conseguir alrededor de problemas similares ( de JanRain PHP-OpenID y Google / Yahoo , php-openID no funciona con Yahoo! , < a href = "https://stackoverflow.com/questions/1183788/example-usage-of-ax-in-php-openid/2612816"> Ejemplo de uso de AX en PHP OpenID ...)

No estoy demasiado caliente en la seguridad, por lo que pido; ¿alguien sabe de una razón para no utilizar estas versiones pirateadas?

¿La biblioteca original tiene cualquier deficiencia estos hacks fijan por diseño, por lo que el corte es una vulnerabilidad de seguridad potencial?

¿Hay un cualificado cripto-ifier por ahí que ha mirado en cualquiera de estas soluciones y se han ido "Por las barbas de David Chaum! NO !! "

Si es así - y, por tanto, no debería utilizar cualquiera de estos hacks -? ¿Cómo puedo comprobar que "ha instalado el paquete ca-certificados"

Answer 1

Esto es lo que el autor de una de esas versiones "hackeados" escribió:

  

En particular CURLOPT_SSL_VERIFYPEER   y la opción CURLOPT_SSL_VERIFYHOST son verdaderas por   Por defecto: Me los puse en false y se   trabajado para la página de prueba!

El efecto que tiene es negar prácticamente cualquier ventaja de seguridad que ofrece el uso de HTTPS. La razón principal HTTPS es útil en OpenID es que protege contra un ataque man-in-the-middle, es decir, algunos malos venenos individuo su caché DNS para enviar todas las solicitudes google.com a bad-guys.example. Con HTTPS configurado correctamente, usted verificar el certificado en la conexión, descubrir que no era de Google, y decir "no voy a creer cualquier cosa que diga, bad-guys!"

A menos que, por supuesto, no verificar los certificados (se definen todas las opciones SSL_VERIFY a false), en cuyo caso el servidor se crea todo lo bad-guys dice como si fuera el verdadero proveedor de Google. Se puede imaginar cómo podría ser malo.

Ahora, francamente, este no es el peor elección que podría hacer, ya que no es peor que simplemente usando HTTP, que mucha gente hacer de todos modos. Estás a mentir a sus usuarios si implica que usted está proporcionando la seguridad HTTPS nivel cuando no estás.

Y hay una gran cantidad de información que hay sobre lo fácil que es o no es hacer un ataque basado en DNS, o lo fácil que es certificados SSL forja . De cualquier manera, requiere a alguien para atacar a la conexión entre el servidor y Google, que es general más difícil de atacar la conexión entre el ordenador portátil del usuario en la cafetería y el servidor.

Pero aún así, mucho mejor para fijar realmente su configuración de PHP o rizo SSL. O si no, advertir a sus usuarios de que cuando se inscriban con HTTPS identificadores, para que puedan elegir si realmente quieren usar esa OpenID con su sitio.

Lo que nos lleva a la segunda pregunta. Creo que, sin saber nada sobre qué plataforma de servidor que está utilizando, lo mejor que puedo hacer es que enlazar a la documentos Curl de los certificados SSL ; véase la sección que dice "Obtener un nuevo paquete mejor / diferente / CA cert!"

Answer 2

Desde el artículo de Wikipedia sobre Certificate Authority :

  

Una CA emite certificados digitales que contienen una clave pública y la identidad del propietario. Cuando un usuario final intenta acceder a una URL desconocida, el navegador web (por ejemplo Mozilla Firefox y Microsoft Internet Explorer) se comunicará con el CA para confirmar la clave pública de la URL.

... por lo que el certificado CA es una href="http://en.wikipedia.org/wiki/Public_key_certificate" rel="nofollow noreferrer"> Certificado de Clave Pública utilizado para comunicarse a través de https:// . El servidor debe tener estos certificados en alguna parte del sistema de archivos. Si no es así, tendrá que descargar el certificado de CA sí mismo y establecer la constante CURLOPT_CAINFO a punto a su ubicación. Ver este artículo.

http://unitstep.net/blog/2009/05/05/using-curl-in-php-to-access-https-ssltls-protected-sites/

Answer 3

  

[...] ¿alguien sabe de una razón para no   utilizar estas versiones pirateadas?

Además del hecho de que son versiones, que son muy probablemente no documentadas y no tienen ninguna garantía en cuanto a su comportamiento? Hackeado

No puedo responder específicamente, pero que debería haber alguna luces de advertencia intermitentes cuando se trabaja con módulos que han tenido soluciones rápidas y soluciones aplicadas, especialmente cuando usted está tratando con la autorización y la seguridad .. Creo que el mejor consejo sería "uso bajo su propio riesgo!"

Estoy seguro de que alguien con más conocimientos sobre el tema llegará muy pronto con una respuesta más informada.