Pregunta:
Veo dos conjuntos diferentes de certificados para sitios web de Google cuando estoy en el trabajo y cuando estoy en casa
Ali
2011-09-06 23:35:23 UTC
view on stackexchange narkive permalink

Veo dos conjuntos diferentes de certificados para sitios web de Google cuando estoy en el trabajo y cuando estoy en casa.

Me refiero a que si guardo los certificados (en firefox, haga clic en "Google.com "bloquear a la izquierda de https en la barra de direcciones y seleccionar" más información "-> seguridad -> ver detalles del certificado -> exportar) tanto en casa como en el trabajo son diferentes. (Solo los estoy comparando usando diff work.cert home.cert).

Me di cuenta de esto cuando comencé a usar el complemento "Convergence" FireFox ( http://convergence.io/)

¿Está bien?

¿Podrías pegar los detalles del certificado? Esto podría resultar útil para determinar el origen de la discrepancia.
@iszi ¿Qué detalles serían útiles? ¿Te refieres a la fecha de emisión y la fecha de vencimiento y ...?
Prácticamente cualquier detalle que nos pueda dar sobre los certificados sería útil. Especialmente pertinente son los elementos que ve que son diferentes entre sí.
Lo haría mañana y publicaría el resultado aquí.
¡Todos los metadatos (así como SHA1 y MD5 que se muestran en el visor de certificados FF) son exactamente iguales! ¡Solo cuando los exporto son diferentes!
Parece que los certificados son los mismos (dado que los hashes son los mismos), pero que la forma en que se exportan y guardan es de alguna manera diferente, presumiblemente usando un formato de archivo diferente, un sistema de archivo diferente o similar. ¿Puede describir los resultados de la exportación con más claridad? ¿O lo ideal sería publicar los dos archivos con los que terminó?
Seis respuestas:
Hendrik Brummermann
2011-09-07 00:00:31 UTC
view on stackexchange narkive permalink

Puede haber varias razones para ello. Sin la información de ambas cadenas de certificados, es imposible dar una respuesta definitiva.

Diferentes conjuntos de servidores

Google tiene muchos clústeres de servidores distribuidos por todas partes el mundo. Su solicitud es manejada por un clúster que está cerca de usted según la topología de la red. Es posible que termine en un clúster de servidores diferente según su proveedor de servicios de Internet y el de la empresa. Google puede usar diferentes claves para diferentes clústeres.

Proxies https

Es probable que su empresa use un servidor proxy que rastrea el tráfico https. Dado que https está encriptado y tiene medidas especiales para evitar ataques de intermediario, el servidor proxy tiene que falsificar el certificado.

Una conexión de proxy https normal funciona así:

  1. el navegador le dice al servidor proxy: "Quiero una conexión de bajo nivel a www.google.com:443"
  2. el servidor proxy se conecta a www.google.com : 443 y reenvía ciegamente todos los paquetes desde el navegador a Google y viceversa.

Un proxy https dedicado hace esto en su lugar:

  1. el navegador le dice al proxy servidor: "Quiero una conexión de bajo nivel a www.google.com:443"
  2. el servidor proxy genera un par de claves para www.google.com:443
  3. el servidor proxy firma el certificado con la clave privada de una CA local.
  4. el servidor proxy muestra este certificado al navegador
  5. el navegador verificará el certificado. Normalmente se quejaría, pero el administrador le dijo de antemano que la CA del proxy es confiable.
  6. el navegador envía la solicitud http para una página.
  7. el proxy lee al servidor las solicitudes , abre una conexión segura a www.google.com y solicita la página correspondiente
  8. el servidor proxy recibe la respuesta, la descifra, la comprueba y la cifra con la clave de sesión derivada de la clave privada falsa generada en paso 2.
  9. el navegador recibe la respuesta, la descifra y está contento.

El paso crítico aquí que rompe SSL es que el administrador ha configurado el navegador para aceptar la CA proxy que se utiliza para firmar las llaves falsas.

¿Es posible que el administrador del proxy obtenga (dada la autoridad y el acceso a una CA raíz) una clave para firmar los paquetes en nombre de Google o de cualquier otra persona para que puedan inspeccionar los paquetes y hacer cumplir algo de Internet? política de conexión? (Me refiero solo a evitar la manipulación de los navegadores para que acepten la firma del proxy ssl)
Si entiendo su pregunta correctamente, entonces sí, hay proveedores (por ejemplo, Bluecoat) que fabrican cajas que pueden emitir certificados sobre la marcha que se relacionan con un certificado de CA personalizado instalado en su computadora portátil, todo con el propósito de ver (aunque probablemente no cambiar) lo que sucede dentro de sus sesiones SSL.
dr jimbob
2011-09-06 23:49:06 UTC
view on stackexchange narkive permalink

Esta es una práctica estándar. Se ha dicho que la mejor práctica es no compartir certificados entre servidores, por lo que verá diferentes certificados de servidores en diferentes ubicaciones. De Verisign:

¿Puedo proteger varios servidores con un solo certificado? Compartir certificados en varios servidores aumenta el riesgo de exposición. La auditoría se vuelve más compleja, lo que reduce la responsabilidad y el control. Si una clave privada se ve comprometida, puede ser difícil rastrearla y todos los servidores que comparten ese certificado están en riesgo. Debido a que compartir certificados degrada la seguridad, el acuerdo de suscripción de certificados de VeriSign prohíbe a los clientes usar un certificado en más de un servidor físico o dispositivo a la vez, a menos que el cliente haya comprado licencias de servidor adicionales. La política de licencias de VeriSign permite que los certificados con licencia se compartan en las siguientes configuraciones: copias de seguridad de servidor redundantes, equilibrio de carga del servidor y aceleradores SSL. Consulte Acerca de las licencias de certificados SSL.

Por ejemplo, si ejecuto nslookup www.google.com en diferentes computadoras, encontraré varias direcciones IP diferentes para diferentes servidores de Google. .One dará un certificado SSL con una huella digital SHA256:

  SHA-256: F6 41 C3 6C FE F4 9B C0 71 35 9E CF 88 EE D9 31 7B 73 8B 59 89 41 6A D4 01 72 0C 0A 4E 2E 63 52  

mientras que otro dará:

  SHA-256: 63 80 03 73 A7 74 72 E0 3E 7E 56 4E A2 17 2F C2 5C 37 D5 71 BD 05 10 1C B4 3C 14 00 04 92 0F 64  

Ambos son "Builtin Object Token: Equifax Secure CA -> Google Internet Authority -> *. google.com "y parecen ser válidos.

Entonces, básicamente, el certificado en sí no se puede usar para verificar si es válido o no, a menos que pueda verificar si está firmado por una CA válida (o la CA válida) ¿es la clave?
@Ali: Bastante. La CA que firmó el certificado da fe de su autenticidad. Hay algunas comprobaciones preliminares de cordura que puede hacer con el certificado en sí (en particular, "válido desde-hasta"), pero eso es todo.
"Debido a que compartir certificados degrada la seguridad [...] prohíbe a los clientes usar un certificado en más de un servidor físico o dispositivo a la vez, ** a menos que el cliente haya comprado licencias de servidor adicionales **" Solo queremos lo mejor de usted;)
Steve Dispensa
2011-09-07 08:21:23 UTC
view on stackexchange narkive permalink

@Hendrik cubrió muy bien las dos situaciones más probables. Debo agregar que sospecharía si viera diferentes CA públicas en la raíz de la cadena de confianza para el mismo sitio en casa o en el trabajo. Es muy posible que su grupo de TI esté usando un proxy de interceptación, pero me sorprendería ver, por ejemplo, Equifax desde el trabajo y Verisign desde casa. Quizás otros puedan comentar lo común que es usar diferentes CA para las mismas direcciones en el mundo real, pero personalmente, nunca me he encontrado con eso.

Sip. Además, si una de las CA raíz es DigiNotar, NO CONFÍE. (si está utilizando IE, la CA raíz solo se ha eliminado con la actualización del sistema * de hoy * (con un retraso de moda como de costumbre;)) - aunque ya se han revocado varios certificados, hay varios certificados fraudulentos no contabilizados firmados por ellos todavía están flotando)
Firefox ha eliminado la confianza de DigiNotar en 6.0.1 e hizo una limpieza más en 6.0.2.
@Iszi: Tanto FF como Chrome reaccionaron con una velocidad encomiable; sin embargo, como la actualización de FF requiere la interacción del usuario (en Windows XP, al menos, "¿por qué me molesta actualizar * de nuevo *? ¡Ya actualicé la semana pasada!"), creo que todavía hay un porcentaje significativo de usuarios de FF en ` 6.0.0` o inferior.
Personalmente, soy un fanático de requerir la suscripción voluntaria (o, al menos, permitir la exclusión voluntaria) para las actualizaciones automáticas completas, pero esa es otra discusión por completo. Escuché que Chrome se había actualizado, pero no estaba seguro del número de versión o cuándo sucedió.
Piskvor left the building
2011-09-07 12:39:25 UTC
view on stackexchange narkive permalink

Existe un ataque MITM (por lo que sabemos, todavía en curso) contra usuarios de Internet (en su mayoría iraníes), utilizando certificados fraudulentos firmados por la CA de DigiNotar. Si alguna de las autoridades de certificación dice "DigiNotar" o "PKIoverheid", considere la conexión insegura. Este es un evento actual, ver p. Ej. esto: http://www.google.com/search?aq=f&hl=en&gl=us&tbm=nws&btnmeta_news_search=1&q=diginotar

Thomas Pornin
2013-08-12 22:24:09 UTC
view on stackexchange narkive permalink

Es normal, esperado y de hecho recomendado que los sitios grandes utilicen varios certificados. Google es enorme y tiene muchos servidores en todo el mundo; El DNS y el enrutamiento se realizan de tal manera que, en promedio, sus solicitudes a www.google.com van al servidor más cercano, donde "cerca" significa en la topología de la red, que puede diferir de consideraciones geográficas.

Cada servidor con el nombre www.google.com debe poder utilizar un certificado que lleve su nombre (o algo que coincida con su nombre, como *. google.com ), y el servidor debe tener acceso a la clave privada correspondiente. Sin embargo, si dos servidores geográficamente distantes usan la misma clave privada, entonces esa clave privada necesariamente debe haber viajado entre ellos o desde una fuente común en algún momento. Cuanto más se duplica y viaja una clave privada, menos "privada" puede ser.

Por tanto, es mejor, desde el punto de vista de la seguridad, que cada servidor genere su propio par de claves privada / pública y certificado específico del servidor. Desde el punto de vista de un cliente, puede observar varios de estos certificados, en particular si se "muda" (en el mundo de la red, su oficina de trabajo y su hogar pueden estar bastante lejos el uno del otro).

Otras situaciones que implican necesariamente cambios de certificado son las renovaciones. Los certificados tienen una vida útil limitada, con una fecha de "fin de validez"; normalmente viven de uno a tres años. La renovación puede o no reutilizar la misma clave pública, pero en cualquier caso el nuevo certificado será distinto del anterior, aunque solo sea en la fecha de vencimiento. X.509 está diseñado para admitir tales actualizaciones sin problemas. En realidad, está diseñado para admitir renovaciones cada 5 minutos, lo cual es una exageración; Convergence intenta vivir en ese "margen excesivo" (es decir, detecta certificados sospechosos en virtud de que aparentemente se renuevan o cambian con demasiada frecuencia).

nickmotor
2015-03-23 06:00:22 UTC
view on stackexchange narkive permalink

¿Estás usando Firefox? Si es así, vaya a Herramientas-> Opciones-> Avanzado-> y elija ver Certificados. Eliminarlo o desconfiar de él. Creo que si quiere estar "seguro", debe hacer que la cadena de certificados tenga la misma ruta cuando se ve desde la misma computadora. Cuando hice esto desde Firefox, la cadena de certificados fue la misma que se presentó desde Chrome.

El OP dice que está usando Firefox y dice que son diferentes. No estoy seguro de que esta respuesta ayude de alguna manera.


Esta pregunta y respuesta fue traducida automáticamente del idioma inglés.El contenido original está disponible en stackexchange, a quien agradecemos la licencia cc by-sa 3.0 bajo la que se distribuye.
Loading...