¿Cómo compruebo si un certificado SSL de gmail / gtalk es válido?

El mensaje que cita significa: "Quería hablar con un servidor llamado talk.google.com , pero lo que respondió allí parece usar un certificado que tiene el nombre gmail.com , y no %código%". Esto significa que cualquiera de estos es cierto:

• algún tercero malintencionado está redirigiendo activamente su conexión al servidor incorrecto, posiblemente por envenenamiento de DNS;
• algunos contratiempos en su ISP implicaron una mala configuración de DNS que emula el efecto del envenenamiento de DNS, redirigiendo su intento de conexión al servidor incorrecto;
• Google no sabe cómo hacer SSL;
• hay algo sospechoso en tu configuración de Pidgin.

Desde aquí, la conexión al puerto 443 en talk.google.com da como resultado un certificado de servidor que incluye el nombre: talk.google.com , que es correcto.

Tenga en cuenta que se sabe que Google juega trucos con el DNS. Desde la máquina de mi casa, subject=/C=US/ST=California/L=Mountain View/O=Google Inc./CN=talk.google.com se resuelve en un alias para talk.google.com , que tiene IP 74.125.113.125. Desde otra máquina en otro continente, talk.l.google.com se resuelve en un alias para talk.google.com , que esta vez tiene IP 209.85.147.125. Obviamente hay algún tipo de equilibrio de carga mundial en acción aquí.

Conclusión: no puede verificar "por sí mismo" si un certificado es bueno o no, excepto quizás al llamar a la sede de Google y hacer que escriban la huella digital del certificado (que podría estar de acuerdo; se rumorea que valoran este tipo de humor). En realidad, el mensaje que recibe es una indicación bastante clara de que no obtiene el certificado correcto, por lo que es mejor que use el mensaje como un síntoma e investigue si realmente se conecta al servidor correcto. Sugiero probar Wireshark para ver qué servidor Pidgin está contactando realmente, y qué sucede a nivel SSL.

  

¿Cómo (y dónde) puedo verificar si el nuevo certificado SSL es válido?

1. Guarde el certificado como un archivo (DER, Base-64 o PKCS # 7).
2. Lea el Emisor para el certificado.
3. Obtenga el certificado del emisor.
   • La ubicación del certificado del emisor generalmente se especifica en el campo "Acceso a la información de la autoridad".
4. Si el certificado del emisor no es una CA raíz, continúe en la cadena hasta que obtenga todo el certificado de la CA raíz para el certificado de interés.
5. Comenzando en el certificado firmado por la CA raíz, verifique que cada certificado tenga un período de validez y la denominación correcta del sujeto
6. Lea el campo de algoritmo de firma para las has y el tipo de cifrado utilizado.
7. Usando la clave pública del certificado de firma descifre la firma
8. Calcule el valor de hash utilizando el algoritmo especificado en el campo Algoritmo de la firma de los datos del certificado hasta, pero sin incluir la firma.
9. Compare el valor descifrado con el hash calculado. Si coinciden la firma es válida.
10. Continúe por la cadena hasta que encuentre un certificado que no es válido.

Si Pidgin inició sesión en dos cuentas, una cuenta de Google Apps y una cuenta de Gmail, entonces no hay problema, no hay error de certificado. Es solo un error Pidgin que han estado ignorando durante el año pasado.

Simplemente pensé en tirar la solución a este problema. Si abre la configuración de cuenta para su cuenta de gmail y hace clic en la pestaña avanzada, probablemente verá "Conectar servidor:" configurado para talk.google.com. No estoy exactamente seguro de lo que está pasando (si es un valor predeterminado anterior o algo así), pero deshacerme de eso resuelve el problema.

Lo que he visto en mi sesión de Wireshark es que se está conectando con talk.google.com, solicitando el certificado de gmail.com y luego confundiéndome con el resultado (no estoy seguro de si está obteniendo el certificado). gmail cert y está confundido porque se conectó a talk.google.com o si google está escupiendo un certificado incorrecto porque se está conectando a un servidor y está solicitando el certificado de otro servidor).

Resolví esto actualizando pidgin. 2.10.7 no me da el error de certificado que 2.7.11 hizo.

Aunque en realidad fue bastante difícil intentar verificar el certificado presentado; Nunca pude obtener ningún servicio de Google para darme un certificado con la misma huella digital de la que se estaba quejando el único pidgin.

No creo que sea un ataque MITM, solo la falta de publicación de los certificados, y mi propia capacidad para averiguar qué servidor responde en última instancia a la solicitud.

Pero no me sentía cómodo aceptando el error, así que espero que el pidgin actualizado no esté haciendo eso por mí.

Una solución diferente para el mismo problema: simplemente tuve que eliminar un carácter de espacio del campo:

Modificar cuenta > Avanzado > Conectar servidor:

No estoy seguro de por qué el mensaje solo comenzó a mostrarse ahora; No he cambiado la configuración durante ~ 2 años. Tal vez esto podría ayudar a alguien más.

Coloque el nombre de dominio ( gmail.com ) en un Firefox o Chrome con HTTPS ( https://gmail.com ) y verifique si el icono de barra / bloqueo de la URL es verde o no. Verde significa que el navegador confía en la conexión. Luego, verifique la huella digital del certificado en el navegador y compárela con la huella digital de la ventana de Pidgin.

No creo que la diferencia de nombre de dominio (gtalk.com vs. gmail.com) sea un gran problema, ambos son dominios de Google.

Hoy en día gmail.com redirige a accounts.google.com , así que en su lugar utilizo https://gmail.com/nosuchpage , que solo muestra una página 404 sin redireccionar.