This article is an automated machine-translation of an article in English. We know the translation isn't perfect, but we hope it's useful for people who don't read English.

El fiasco TURKTRUST certificado SSL - lo que realmente sucedió, y qué pasa después?

Filed Under: Featured, Privacy, Security threats

Hace unos días, mi colega Chester escribió un artículo con el no-golpes-sacó titular turco Certificate Authority screwup conduce al intento de suplantación de Google .

Desde entonces, una discusión en línea y la disección de lo sucedido - o, más exactamente, lo que sucedió hasta el momento como uno podría decir - ha desplegado , y parece haber llegado a una conclusión - o, más exactamente, una hipótesis aceptable.

Voy a tratar de resumir lo más brevemente me atrevo.

SSL y la jerarquía de confianza

Voy a usar una terminología informal, lo que probablemente ofenderá a los expertos SSL en todas partes, y que corre el riesgo de confundir la situación a través de la simplificación excesiva.

Pero aquí va.

Un certificado es, así, un simple certificado SSL de edad. Supersimplified, es una clave pública la gente puede utilizar para cifrar el tráfico a su sitio, junto con una firma digital que lo identifica como suyo.

Una autoridad de certificación (CA) es una empresa que agrega una firma digital a su certificado, supuestamente después de comprobar de alguna manera que usted es quien dice ser.

Un certificado intermedio es el instrumento que se utiliza SSL por una CA en la generación de la firma digital en su certificado, para que la gente pueda ver quién respondió por ti.

Un certificado raíz es el instrumento que es utilizado por una entidad de certificación en el nivel superior de confianza para agregar una firma digital a los certificados intermedios que se utilizan en el siguiente nivel de confianza hacia abajo, cuando se firmó el certificado. Eso significa que la gente puede ver en garante de la empresa que respondió por ti.

No se espera que verificar a mano en garante de los cuales en esta jerarquía de confianza. Todo sucede de forma automática cuando el navegador establece una conexión segura.

Las entidades emisoras de certificados en el nivel raíz del certificado público de confianza en realidad son las raíces del árbol. Sus certificados son pre-cargado en el navegador y automáticamente otorgar la baja confianza.

certs-incorporado-500

Así que si usted tiene un certificado SSL en nombre de EXAMPLE.ORG que está firmado por un certificado de, digamos, GOOD4NE1, y si el certificado está firmado por un certificado de, digamos, TURKTRUST, y si el certificado TURKTRUST 's es de confianza de su cliente navegador ...

... Entonces el navegador de su cliente (y por lo tanto su cliente) automáticamente confía en su servidor (y por tanto implícitamente confía en ti).

Usted responder por sí mismo. GOOD4NE1 avala para usted. Avala TURKTRUST para GOOD4NE1. Y da fe de su navegador para proveedores TURKTRUST.

Error operacional del TURKTRUST

¿Qué podría salir mal?

En el caso TURKTRUST, esto es lo que:

1. Ya en 2011, TURKTRUST introdujo un proceso de negocio viciado que ha permitido a la empresa para generar y enviar un certificado intermedio por error, cuando un certificado regular había sido solicitada.

2. A finales de 2012, TURKTRUST hecho esa metedura de pata, y envió dos certificados intermedios a una organización que había pedido dos certificados regulares. Esa organización fue EGO , la autoridad de transporte público, en Ankara, Turquía.

3. EGO dio cuenta del error, al menos en parte, y volvió uno de los certificados. TURKTRUST la revocó. Por alguna razón, EGO mantuvo el otro certificado.

Lo que quería decir es que EGO ahora tenía la capacidad, si se sentía tan inclinado, para firmar los certificados SSL para cualquier nombre de dominio que eligió, al parecer con el visto bueno de TURKTRUST.

Y lo que quería decir es que cualquier certificado firmado por el EGO de esta manera sin quejarse sería aceptada por casi todos los navegadores en el mundo, porque el certificado TURKTRUST 's raíz estaba en la lista de cada navegador de la presunta buena-CA.

Lo que sucedió después, al parecer, es que el ego decidió implementar análisis de seguridad de tráfico HTTPS de su red.

Escaneo el tráfico cifrado

Es fácil analizar el tráfico HTTP mediante el uso de un proxy, pero el tráfico HTTPS es más difícil de mirar dentro, ya que el contenido se supone que es cifrado de extremo a extremo.

El enfoque habitual es realizar un man in the middle (MITM) ataque a su propio tráfico. Los nombres de marketing para esto se keybridging o descifrar recrypt, pero no deja de ser un MITM.

Crea dos sesiones SSL - uno desde el navegador al proxy y el otro de proxy para el destino final.

Usted descifrar el interior del proxy, examinar el contenido, a continuación, volver a cifrar para el resto del viaje.

→ Keybridging no es un ataque si lo haces en el tráfico saliente de su propia compañía, pero usted debe saber que sus usuarios. Se viola la santidad de la encriptación de extremo a extremo que se espera de una conexión SSL.

El dolor operacional con keybridging es que los usuarios obtienen una advertencia de certificado cada vez que hacen una conexión segura a un sitio nuevo. Eso es debido a que sus conexiones SSL terminar en su poder, no en los sitios reales que tenían la intención de visitar.

La forma habitual de evitar esto es crear su propio certificado raíz privado, subirlo a tu servidor proxy keybridging, y dejar que el proxy automáticamente generar, firmar y presentar los certificados de marcador de posición para sus propios usuarios.

Al agregar el certificado raíz privado a todos los equipos dentro de la red, se suprimen las advertencias de certificado, ya que sus propios navegadores confiar en su propio proxy como una CA. Eso significa que sus navegadores tolerar en silencio los certificados de marcador de posición generados por el proxy.

Es algo impuro y feo, pero es práctico, y funciona.

El problema con los de afuera

Las cosas se ponen muy molestos, como se puede imaginar, cuando se tiene un Traiga su propio dispositivo (BYOD) política, o si deja que los contratistas en su red, y quiere (con suerte tanto con su conocimiento y su consentimiento) para escanear el tráfico SSL a lo largo de con la de sus usuarios habituales.

Hasta que descargar e instalar el certificado raíz privado en su navegador, por lo que aceptar como una entidad de nivel superior, recibirán advertencias de certificado.

Y por lo que aquellos que no siguen las instrucciones dadas por el servicio de asistencia seguirá recibiendo advertencias de certificado y seguiremos llamando a la mesa de ayuda. Lavar, enjuagar, repetir.

A menos que, como la suerte lo tendría, le sucede que tiene un certificado intermedio, firmado por una CA raíz de confianza ya nivel mundial, que usted puede utilizar para su MITM.

Pero eso, por supuesto, nunca va a pasar, sobre todo porque los procesos de cualquier entidad emisora ​​raíz de confianza de negocios le impida darse cuenta que la emisión de un certificado intermedio para ese propósito ...

... Y te puedo decir dónde va esto.

Clave pública SSL fijando

La palabrería TURKTRUST comenzó, al parecer, cuando uno de los usuarios de la red EGO, que estaba utilizando el navegador de Google Chrome, recibió una advertencia sobre el certificado inesperado que dice representar a una propiedad web google.com.

Esto se debe a una característica de Chrome llamada clave pública pinning , en el que está equipado el navegador no sólo con una lista de entidades emisoras de certificados raíz presunta-buenas, pero también con una lista de conocidos buenos certificados SSL de Google.

Así que, incluso si un presunto CA-bueno de repente empieza a firmar certificados que dicen ser de *. Google.com, el navegador se quejará.

Esto ayuda a proteger contra el compromiso de una CA raíz, o contra el comportamiento arriesgado deliberadamente por una CA raíz, o, como en este caso, en contra de procesos de negocio descuidado y un comportamiento incorrecto por una CA raíz.

Se habrá dado cuenta que he dicho "en este caso, en contra de procesos de negocio descuidado."

Las teorías de conspiración no obstante, estoy dispuesto a aceptar que se trataba de una crisis torpe de conveniencia, no un intento frustrado en la vigilancia secreta:

  • TURKTRUST no debería haber emitido el tipo equivocado de certificados.
  • TURKTRUST debería haber sido más proactivos en el rastreo del segundo certificado una vez que el primero se informó.
  • EGO no debería haber puesto mal el certificado expedido por intermedio del uso que hizo.

¿Hacia dónde vamos?

¿Qué pasa después?

Según Ben Laurie de Google, comentando sobre el artículo antes de Chester, una parte de la respuesta es Transparencia certificado .

Certificado transparencia

Voy a dejar que la propuesta de resumir por sí mismo:

El objetivo es hacer que sea imposible (o al menos muy difícil) para una autoridad de certificación para emitir un certificado para un dominio sin que sea visible para el propietario de ese dominio. Un objetivo secundario es el de proteger a los usuarios tanto como sea posible de los certificados emitidos mal. También se pretende que la solución debe ser compatible con los navegadores existentes y otros clientes.

Esto se logra mediante la creación de una serie de algoritmos criptográficos, aseguró públicamente que se pueden auditar, append-only logs de certificados. Cada certificado estará acompañado por una firma de uno o más registros que afirman que el certificado ha sido incluido en esos registros. Navegadores, auditores y supervisores colaborarán para garantizar que el registro es honesto. Los dueños de dominios y otras partes interesadas para supervisar el registro de errores de certificados expedidos.

En pocas palabras, la idea es mantener una lista comunitaria vigilada que le permite diferenciar entre los certificados que se supone que están en circulación y los certificados que se han generado a través de incompetencia o para propósitos nefastos.

Por supuesto, la transparencia certificado añadir otra capa de complejidad a un proceso ya complejo, que es una preocupación.

Pero también le inyectará una capa de honestidad forzada, la rendición de cuentas y la supervisión en el mundo SSL, que debe ser bueno para todos nosotros.

You might like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About the author

Paul Ducklin is a passionate security proselytiser. (That's like an evangelist, but more so!) He lives and breathes computer security, and would be happy for you to do so, too. Paul won the inaugural AusCERT Director's Award for Individual Excellence in Computer Security in 2009. Follow him on Twitter: @duckblog