diff options
Diffstat (limited to 'index.mdwn')
-rw-r--r-- | index.mdwn | 420 |
1 files changed, 420 insertions, 0 deletions
diff --git a/index.mdwn b/index.mdwn new file mode 100644 index 0000000..e5800b7 --- /dev/null +++ b/index.mdwn @@ -0,0 +1,420 @@ +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? +========= + + :) + |