Convergence e Monkeysphere: chaves para gestão SSL distribuída - Co0l - Ed. 2

Duas alternativas viáveis para substituir ou complementar o atual cartel das Autoridades Certificadoras utilizadas na pilha SSL/TLS.

Propósito

De 2008 até o momento, foram reveladas falhas fundamentais em vários protocolos básicos da internet:

• DNS: Dan Kaminsky Discovers Fundamental Issue In DNS (análise)
• BGP: The Internet’s Biggest Security Hole
• SSL: Várias brechas

Estamos falando principalmente de falhas de especificação e não de implementação ou DoS, o que é muito mais difícil de mitigar.

SSL: Breve histórico

Pontos principais de um protocolo seguro:

1. Sigilo: a informação não será lida por terceiros.
2. Integridade: a informação não será adulterada.
3. Altenticidade: os pontos da comunicação serão verificados.
4. Disponibilidade: proteção a DoS, etc.
5. Anonimato.

No caso do SSL/TLS:

1. Sigilo:
   • Criptografia usando chaves assimétricas.
   • Troca de chaves: RSA or Diffie-Hellman (usem DHE!)
2. Integridade: MAC Digest (hash)
3. Autenticidade: Certificados

SSL

• Encapsulamento de outros protocolos
• HTTP Strict Transport Security - HSTS
• CipherSuite e Perfect Forward Secrecy
• Revogação (CRL / OCSP)
• Autoridades Certificadoras (CAs)
• Ataques:
  • SSL Computational DoS (THC)
  • Hashclash (MD5)
  • BEAST
  • LittleBlackBox: chaves padrões em dispositivos embarcados!
  • sslsnif

Autoridades certificadoras

• Sistema PKI em x509 (ITU-T - 1998): atrela uma chave pública a um nome (domínio, email, etc)
• Árvore hierárquica de certificação
• 2009: Relatório da Netcraft
• 2010: Verisign: operação de CA vendida por US$1.28 bi para a Symantec
• “Two big to fail”

Netcraft (2009)

Como me torno uma autoridade certificadora?

Depende dos processos de inclusão

• Pelo fabricante da aplicação ou biblioteca
• Pelo distribuidor da aplicação ou biblioteca
• O usuário pode incluir manualmente

Quanto mais upstream for a inclusão, maior a ubiquidade. Certificados não-instalados são considerados como autoassinados.

• Exemplo: o caso do http://www.cacert.org, uma CA Comunitária
• Mozilla: https://www.mozilla.org/projects/security/certs/included/
• ICP-Brasil: http://www.iti.gov.br

CA: Procedimentos

• Mozilla - https://wiki.mozilla.org/CA:How_to_apply
• Opera - http://www.opera.com/docs/ca/
• M$ - http://technet.microsoft.com/en-us/library/cc751157.aspx (desatualizado)
• Safari - https://www.apple.com/certificateauthority/ca_program.html
• Chromium - NSS (GNU/Linux)

CA: Em geral

• Há pouca transparência na relação entre CAs e fabricantes de software

• Sem gestão multissetorial

• Admins de instituições pequenas não tem outra escolha senão utilizar esses CAs

• As CAs são confiadas exatamente por serem CAs. Onde está a abertura das auditorias?

Obtenção de um certificado assinado

           ________ 
          |        |
       ___|   CA   |--.
      /   |________|   \ 2
     ^        |         : 
   1 |        | 3       v   
 ____|____    v     __________
|         |   |    |          |
|  Admin  |__/     | Servidor |
|_________|        |__________|

Situação atual

The authenticity of host 'foo.example.org (192.0.2.3)' can't be established.
RSA key fingerprint is 17:f4:2b:22:90:d4:98:9a:a2:c5:95:4e:4a:89:be:90.
Are you sure you want to continue connecting (yes/no)?

• Vocês checam seus fingerprints (OpenPGP, SSH e OpenSSL)?

• Maus hábitos de sysadmins geram falsa sensação de segurança

• Usabilidade: Bypass da tela de “conexão não-confiável”

Evidências de cooperação

• Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL: evidence that CAs may be cooperating with government agencies to help them spy undetected on “secure” encrypted communications

• Man-in-the-Middle Attacks Against SSL: a new attack, the compelled certificate creation attack, in which government agencies compel a certificate authority to issue false SSL certificates that are then used by intelligence agencies to covertly intercept and hijack individuals’ secure Web-based communications.

Casos reais

• Comodogate: mail.google.com, addons.mozilla.org, login.skype.com, etc.

• DigiNotar: certificados falsos da CIA, MI6 e Mossad (timeline).

• The EFF SSL Observatory (27c3)

• A situação é alarmante: basta apenas que um único CA seja comprometido para ruir toda a infraestrutura.

• SSL não se aplica apenas a HTTPS: StartTLS/SMTPS/IMAPS/XMPP/VPN/etc também sofrem dessas vulnerabilidades.

O que é preciso para interceptar conexão SSL?

1. Certificado falso.

2. Meios efetivos de um MITM:

   • DNS poisoning apontando requisições para servidores maliciosos.
   • Redirecionamento de tráfego via BGP.
   • Acesso físico à rede.

Conexão SSL

 _______________ 
|               |
|   CA (local)  |
|_______________|
     |
     ^ 3
 ____|____       2        __________
|         |------<-------|          |
| Cliente |              | Servidor |
|_________|------>-------|__________|
                 1  

MITM

           ________ 
          |        |
       .->|  MITM  |-<.
      /   |________|   \
     |                  |
     v                  v 
 ____|____          ____|_____
|         |        |          |
| Cliente |---X----| Servidor |
|_________|        |__________|

Mas o quanto disso é factível?

• Oriente médio:
  • The Internet’s Secret Back Door: Web users in the United Arab Emirates have more to worry about than having just their BlackBerries cracked (Cybertrust / Verizon)
  • Iran’s Web Spying Aided By Western Technology (Nokia-Siemens)
  • Out of Egypt Censorship, US Tech Export Under Fire (Narus)

• EUA: NSA warrantless surveillance controversy

• Brasil: Massive DNS poisoning attacks in Brazil

Pequenos provedores até grandes porções da internet podem ser afetados. O ataque é o mesmo, variando apenas a capacidade do atacante.

Mitigação

Recentemente foram propostas várias formas de mitigação:

• Certificate Patrol: muito útil porém sofre to problema de “bootstrapping”/secure introduction (Trust On First Use/Persistence of Pseudonym - TOFU/POP).
• Certlock
• IETF:
  • Public Key Pinning Extension for HTTP: também sofre do “problema de bootstrapping”.
  • DNSSEC/DANE: aumenta ainda mais a centralidade do DNS e apenas muda o problema de lugar.
  • CAA
  • HASTLS
• Sovereign Keys (EFF)
• Google:
  • Certificate Authority Transparency and Auditability
  • Google Certificate Catalog

Alternativas?

A grande questão é: abandonar o SSL hoje é uma opção que não depende apenas dos/as usuários, porém é importante considerar que o modelo atual de certificação não é mandatório. Ao invés disso, o modelo de CAs pode ser plugável.

http://convergence.io

• Add-on para firefox + daemon
• Precedido pelo Perspectives (http://perspectives-project.org)
• “Trust agility”: usuário/a escolhe em quem confiar e por quanto tempo
• Sistema notarial distribuído e robusto
• Anônimo e com boa usabilidade

Funcionamento

 _______________     5 cert
|               |----<----.
| Notary server |          \
|_______________|---->---.  \
  |  |               4    \  \
6 v  ^ 3 h+fp              \  \
 _|__|____        2 cert  __\__\____
|         |------<-------|          |
| Cliente |              | Servidor |
|_________|------>-------|__________|
                 1  

Bundles

                     ____      
            .-----<-|    | 
            |  .-->-| N1 |<
 ___________|_|_    |____| \
|               |    ____   \
| Notary proxy  |->-|    |   \
|_______________|-<-| N2 |<.  \
      |  |          |____|  \  \
      v  ^            .      \  \
      |  |            .       \  \
      |  |            .        \  \
      v  ^           ____       \  \
      |  |          |    |       \  \
      |  |          | Nn |        \  .
      v  ^          |____|-<-->.   . |
   ___|__|__                   _\__v_v___
  |         |------<----------|          |
  | Cliente |                 | Servidor |
  |_________|------>----------|__________|

Convergence: Problemas

• Se o MITM estiver exatamente no provedor upstream, o Convergence pode não perceber.
• Mudanças de chaves.
• The Citibank Problem

http://web.monkeysphere.info

• Add-on pra firefox + agent
• Atrela a autenticação à identificações pessoais pela Web Of Trust
• Também provê autorização

I - Estabelecimento de confiança entre pessoas

Usuários e/ou admins trocam seus fingerprints OpenPGP.

 ________       ________
|        |-->--|        |
| Admin  |     |  User  |
|________|--<--|________|

II - Assinatura de chave do servidor

 ___________
|           |
| Keyserver | 
|___________|
     |
     ^ 3
 ____|____       2        __________
|         |------<-------|          |
|  Admin  |              | Servidor |
|_________|------>-------|__________|
                 1  

III - Conexão SSL

 ___________
|           |
| Keyserver | 
|___________|
     |
     ^ 3
 ____|____       2        __________
|         |------<-------|          |
|   User  |              | Servidor |
|_________|------>-------|__________|
                 1  

Web of Trust

• Identificação.
• Confiabilidade.
• Mesmo que um usuário não tenha identificado um admin que assinou a chave de um servidor, confiabilidade ainda pode ser estabelecida por meios indiretos.

Integração

• O Monkeysphere ainda é muito geeky porém oferece um nível de segurança muito mais alto para a verificação de certificados; o código está maduro porém é preciso muito mais desenvolvimento de UI e usabilidade, além de depender de uma grande WoT para ser eficaz.
• O Convergence pode utilizar como backend o Monkeysphere, o que pode reduzir o problema do MITM upstream.

Perspectivas

• A indústria sabe que o modelo de CAs está falido, mas ainda assim existe uma insistência em dizer que o problema são as “maçãs podres” ou o excesso de CAs.

• Os fabricantes de navegadores tem peso maior na decisão, porém dificilmente farão mudanças bruscas uma vez que a internet hoje é muito dependente na infraestrutura de CAs.

• A pluralidade de métodos e a plugalidade (:P) de soluções podem convergir num esquema de validação híbrido.

• Conscientização do público é fundamental.

Demonstrações

• Monkeysphere
• Convergence

Perguntas?

:)