Title: Convergence e Monkeysphere: chaves para gestão SSL distribuída
Author: Silvio
Generator: S9

%css 

body {
  font-family: monospace;
}
  
.centered img {
  display: block;
  margin-left: auto;
  margin-right: auto;
}

.centered {
  text-align: center;
}

%end

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](https://lwn.net/Articles/289138) ([análise](http://www.unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html))
- BGP: [The Internet’s Biggest Security Hole](http://www.wired.com/threatlevel/2008/08/how-to-intercep/)
- SSL: [Várias brechas](https://links.sarava.org/tags/ssl)

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. Autenticidade: os pontos da comunicação serão verificados.
  4. Disponibilidade: proteção a DoS, etc.
  5. Anonimato.

SSL: Breve histórico (cont)
===========================

No [caso do SSL/TLS](https://techmeet.sarava.org/uploads/Agenda/SSL_For_Activists.pdf):

  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
- CipherSuite e Perfect Forward Secrecy
- Revogação (CRL / OCSP)
- Autoridades Certificadoras (CAs)
- Ataques:
  - [SSL Computational DoS (THC)](http://www.thc.org/thc-ssl-dos/)
  - [Hashclash (MD5)](http://www.win.tue.nl/hashclash/rogue-ca/)
  - [BEAST](https://wiki.koumbit.net/BeastSecurityAssessment)
  - [LittleBlackBox](https://code.google.com/p/littleblackbox/): chaves padrões em dispositivos embarcados!
  - [sslsnif](http://www.thoughtcrime.org/software/sslsniff)

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](https://ssl.netcraft.com/ssl-sample-report)
- 2010: Verisign: operação de CA vendida por US$1.28 bi para a Symantec
- "Two big to fail"

Netcraft (2009)
===============

<div class="centered" markdown="1">
![Netcraft - Linha do Tempo](images/netcraft-ssl-timeline.png)
![Netcraft - Fatias do Bolo](images/netcraft-ssl-pizza.png)
</div>

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](http://code.google.com/p/chromium/wiki/LinuxCertManagement) (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](http://web.monkeysphere.info/news/CA_Cooperation_with_Governments/): _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](https://www.schneier.com/blog/archives/2010/04/man-in-the-midd_2.html): _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
===========

% "Crime maior do que roubar uma CA é fundar uma CA" - Bertold Brecha

- [Comodogate](http://it.slashdot.org/story/08/12/23/0046258): mail.google.com, addons.mozilla.org, login.skype.com, etc.

- [DigiNotar](http://www.f-secure.com/weblog/archives/00002228.html): certificados falsos da CIA, MI6 e Mossad ([timeline](http://www.networking4all.com/en/ssl+certificates/ssl+news/time-line+for+the+diginotar+hack/)).

- [The EFF SSL Observatory](https://www.eff.org/observatory) ([27c3](http://events.ccc.de/congress/2010/Fahrplan/events/4121.en.html))

- 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](http://www.slate.com/articles/technology/webhead/2010/08/the_internets_secret_back_door.html) (Cybertrust / Verizon)
  - [Iran's Web Spying Aided By Western Technology ](http://online.wsj.com/article/SB124562668777335653.html#mod=rss_whats_news_us) (Nokia-Siemens)
  - [Out of Egypt Censorship, US Tech Export Under Fire](http://yro.slashdot.org/story/11/02/11/1920258/Out-of-Egypt-Censorship-US-Tech-Export-Under-Fire) (Narus)
  - [A Syrian Man-In-The-Middle Attack against Facebook](https://www.eff.org/deeplinks/2011/05/syrian-man-middle-against-facebook)

- EUA: [NSA warrantless surveillance controversy](https://en.wikipedia.org/wiki/NSA_warrantless_surveillance_controversy / https://en.wikipedia.org/wiki/Hepting_v._AT%26T)

- Brasil: [Massive DNS poisoning attacks in Brazil](http://www.securelist.com/en/blog/208193214/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:

- [HTTP Strict Transport Security - HSTS](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security)
- [Certificate Patrol](https://addons.mozilla.org/pt-BR/firefox/addon/certificate-patrol/?src=search): muito útil porém sofre to problema de secure introduction (Trust On First Use/Persistence of Pseudonym - TOFU/POP).
- [Certlock](https://code.google.com/p/certlock/)
- IETF:
  - [Public Key Pinning Extension for HTTP](https://www.ietf.org/id/draft-evans-palmer-key-pinning-00.txt): também sofre do "problema de bootstrapping".
  - [DNSSEC/DANE](http://tools.ietf.org/html/draft-ietf-dane-protocol-12): aumenta ainda mais a centralidade do DNS e apenas muda o problema de lugar.
  - [CAA](https://tools.ietf.org/html/draft-hallambaker-donotissue-03)
  - [HASTLS](https://tools.ietf.org/html/draft-hoffman-server-has-tls-04)
- [Sovereign Keys (EFF)](https://www.eff.org/deeplinks/2011/11/sovereign-keys-proposal-make-https-and-email-more-secure)
- Google:
  - [Certificate Authority Transparency and Auditability](http://tech.slashdot.org/story/11/11/29/2226211/google-researchers-propose-plan-to-fix-ca-system)
  - [Google Certificate Catalog](http://googleonlinesecurity.blogspot.com/2011/04/improving-ssl-certificate-security.html)

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_ e explorar características _locais_ e _globais._

http://convergence.io
=====================

- [Add-on para firefox](http://convergence.io/releases/firefox/convergence-current.application=x-xpinstall) + 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

- [BlackHat USA 2011: SSL And The Future Of Authenticity](https://www.youtube.com/watch?v=Z7Wl2FW2TcA)

Funcionamento
=============

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

Constelação
===========

                         ____      
                .-----<-|    | 
                |  .-->-| N1 |<
     ___________|_|_    |____| \
    |               |    ____   \
    | Notary bounce |->-|    |   \
    |_______________|-<-| 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

  - Futuro: [TACK (Tethered Assertions for Certificate Keys)](https://github.com/moxie0/Convergence/wiki/TACK): similar às Chaves Soberanas da EFF

http://web.monkeysphere.info
============================

- [Add-on pra firefox](https://addons.mozilla.org/pt-BR/firefox/addon/monkeysphere/?src=search) + agent + userland

- 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?
=========

    :)