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.

O TURKTRUST fiasco certificado SSL - o que realmente aconteceu, eo que acontece depois?

Filed Under: Featured, Privacy, Security threats

Alguns dias atrás, meu colega Chester escreveu um artigo com o não-golpes puxados manchete turco Autoridade Certificadora screwup leva a Google tentou representação .

Desde então, uma discussão on-line e dissecação do que aconteceu - ou, mais precisamente, o que aconteceu até agora como se poderia dizer - tem desdobrado , e parece ter chegado a uma conclusão - ou, mais precisamente, uma hipótese aceitável.

Deixe-me tentar resumir tão brevemente quanto eu ousar.

SSL e da hierarquia de confiança

Vou usar uma terminologia informal, o que provavelmente ofender especialistas SSL em todos os lugares, e que corre o risco de confundir a situação através de banalização.

Mas aqui vai.

Um certificado é, também, um certificado SSL velho liso. Supersimplified, é uma chave pública as pessoas podem usar para criptografar o tráfego para seu site, combinado com uma assinatura digital que identifica como a sua.

Uma autoridade de certificação (CA) é uma empresa que adiciona uma assinatura digital para o seu certificado, supostamente após a verificação de alguma maneira que você é quem diz ser.

Um certificado intermediário é o instrumento SSL que é usado por uma CA na geração da assinatura digital no seu certificado, de modo que as pessoas possam ver que atestou para você.

Um certificado raiz é o instrumento que é utilizado por uma CA no nível mais alto de confiança para adicionar uma assinatura digital para os certificados intermediários que são utilizados no próximo nível de confiança baixo, quando o seu certificado fica assinado. Isso significa que as pessoas podem ver que atestou a empresa que atestou para você.

Você não se espera para verificar a mão que atestou que na hierarquia de confiança. Tudo acontece automaticamente quando o navegador estabelece uma conexão segura.

Os CAs a nível público certificado raiz de confiança realmente são as raízes da árvore. Seus certificados são pré-carregados no seu browser e automaticamente dar baixa confiança.

certs-built-in-500

Então se você tem um certificado SSL em nome de EXAMPLE.ORG que é assinado por um certificado de, digamos, GOOD4NE1, e se o seu certificado é assinado por um certificado de, digamos, TURKTRUST, e se o certificado TURKTRUST 's tem a confiança de browser do seu cliente ...

... Então browser do seu cliente (e, portanto, o seu cliente) confia automaticamente seu servidor (e, portanto, implicitamente confia em você).

Você atestar para si mesmo. GOOD4NE1 atesta para você. Atesta TURKTRUST para GOOD4NE1. E seu navegador atesta fornecedor para TURKTRUST.

Erro operacional da TURKTRUST

O que poderia dar errado?

No caso TURKTRUST, aqui é o que:

1. Voltar em 2011, TURKTRUST introduziu um processo de negócio falho que tornou possível para a empresa para gerar e enviar um certificado intermediário, por engano, quando um certificado regular havia sido solicitado.

2. No final de 2012, TURKTRUST feito tal asneira, e enviou dois certificados intermediários para uma organização que tinha pedido dois certificados regulares. Essa organização foi EGO , a autoridade de transporte público, em Ancara, Turquia.

3. EGO percebeu o erro, pelo menos em parte, e voltou um dos certificados. TURKTRUST revocasse. Por alguma razão, EGO manteve o outro certificado.

O que quis dizer foi que o EGO já tinha a capacidade, se sentiu tão inclinado, para assinar os certificados SSL para qualquer nome de domínio que escolheu, aparentemente com o imprimatur de TURKTRUST.

E o que quis dizer foi que qualquer certificado assinado pelo EGO, desta forma seria sem reclamar ser aceito por quase todos os browser do mundo, porque TURKTRUST o certificado raiz estava na lista de cada navegador de suposta boa-CAs.

O que aconteceu em seguida, ao que parece, é que o EGO decidiu implementar varredura de segurança de tráfego HTTPS para fora de sua rede.

Digitalização tráfego criptografado

É fácil verificar o tráfego HTTP usando um proxy, mas o tráfego HTTPS é mais difícil de olhar para dentro, já que o conteúdo é suposto ser criptografado de ponta a ponta.

A abordagem usual é realizar um homem no ataque Middle (MITM) em seu próprio tráfego. Os nomes de marketing para isso são keybridging ou decifrar-recrypt, mas é realmente apenas um MITM.

Você cria duas sessões SSL - um de navegador para o proxy e outro do proxy para o destino final.

Você descriptografar dentro do proxy, examinar o conteúdo, e então re-criptografar para o resto da viagem.

→ Keybridging não é um ataque, se você fizer isso no tráfego de saída de sua própria empresa, mas você deve deixar os usuários sabem. Isso viola a santidade da criptografia end-to-end que você espera de uma conexão SSL.

A dor operacional com keybridging é que seus usuários recebem um aviso de certificado cada vez que fazem uma conexão segura com um novo site. Isso porque suas conexões SSL terminar em seu proxy, e não nos locais reais que pretendiam visitar.

A maneira usual de contornar isso é criar o seu próprio certificado raiz privada, enviá-lo para o seu proxy keybridging, e deixar o proxy automaticamente gerar, assinar e fornecer certificados de espaço reservado para seus próprios usuários.

Ao adicionar o seu certificado raiz privada para todos os computadores dentro da sua rede, você suprimir os avisos de certificado, porque seus próprios navegadores confiar em seu próprio proxy como uma CA. Isso significa que seus navegadores tranquilamente tolerar os certificados de espaço reservado gerados pelo proxy.

É algo impuro e feio, mas é prático, e funciona.

O problema com pessoas de fora

As coisas ficam realmente problemático, como você pode imaginar, quando você tem um seu próprio dispositivo de política (BYOD), ou se você deixar que as empresas em sua rede, e quiser (espero que com tanto o seu conhecimento e consentimento) para digitalizar seu tráfego SSL junto com a de seus usuários regulares.

Até que baixar e instalar o certificado raiz particular no seu navegador, portanto, aceitar você como um CA de nível superior, vão receber avisos de certificado.

E para aqueles que não seguem as instruções dadas pelo helpdesk vai conseguir manter avisos de certificado, e irá manter telefonando para o helpdesk. Lavagem, enxágüe, repita.

A menos que, como ele teria sorte, acontecer de você ter um certificado intermediário, assinado por um já globalmente raiz confiável, que você pode usar para seu MITM.

Mas isso, é claro, nunca vai acontecer, até porque os processos de qualquer respeitável raiz de negócios da CA iria impedi-lo de inadvertidamente emissão lo com um certificado intermediário para o efeito ...

... E você pode dizer onde isso vai dar.

Chave pública SSL fixando

O palavrório TURKTRUST começou, ao que parece, quando um dos usuários na rede EGO, que estava usando o navegador do Google Chrome, recebeu um aviso sobre um certificado inesperado alegando representar uma propriedade da web google.com.

Isso é por causa de um recurso chamado Chrome chave pública pinagem , em que o navegador está equipado, não só com uma lista de ACs presumido de bem de raiz, mas também com uma lista de certificados em boas Google SSL.

Assim, mesmo se uma CA suposta boa-de repente começa a assinar certificados que dizem ser de *. Google.com, o navegador vai reclamar.

Isso ajuda a proteger contra a fuga de uma raiz, ou contra o comportamento deliberadamente desonesto por uma raiz, ou, como neste caso, contra o processo de negócio malfeito e comportamento de buggy por uma CA raiz.

Você vai notar que eu disse ", neste caso, contra o processo de negócio malfeito."

Teorias da conspiração, não obstante, estou inclinado a aceitar que esta foi uma crise desajeitado de conveniência, e não uma tentativa abortada de vigilância secreta:

  • TURKTRUST não deveria ter emitido o tipo errado de certificados.
  • TURKTRUST deveria ter sido mais pró-ativa sobre rastrear o segundo certificado uma vez que o primeiro foi relatado.
  • EGO não deveria ter colocado o certificado emitido erroneamente intermediário para o uso que fez.

Onde a partir daqui?

O que acontece a seguir?

De acordo com Ben Google Laurie, comentando em artigo anterior Chester, uma parte da resposta é Transparência Certificado .

Transparência certificado

Eu vou deixar a proposta resumir para si:

O objetivo é torná-lo impossível (ou pelo menos muito difícil) para uma autoridade de certificação para emitir um certificado para um domínio sem que seja visível para o proprietário do domínio. Um objetivo secundário é o de proteger os usuários, tanto quanto possível a partir de certificados mal emitidos. Pretende-se também que a solução deve ser compatível com os navegadores existentes e outros clientes.

Isto é conseguido através da criação de um número de criptograficamente assegurados, publicamente auditáveis, append-only, registros de certificados. Cada certificado será acompanhado por uma assinatura de um ou mais registros que afirmam que o certificado foi incluído nos registros. Navegadores, auditores e monitores vão colaborar para garantir que o log é honesto. Proprietários de domínios e outras partes interessadas irá monitorar o log para mis-emitidos certificados.

Em suma, a idéia é manter uma lista comunidade policiada que permite diferenciar os certificados que devem estar em circulação, e certificados que foram geradas por incompetência ou para fins nefastos.

Naturalmente, a transparência certificado irá adicionar outra camada de complexidade a um processo já complexo, o que é uma preocupação.

Mas também vai injetar uma camada de aplicada a honestidade, responsabilidade e supervisão para o mundo SSL, que deve ser bom para todos nós.

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