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">
</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?
=========
:)
