Stoa :: Ewout ter Haar :: Blog :: TLS / SSL na Web: sabe com quem está falando?

abril 01, 2010

default user icon
Postado por Ewout ter Haar

Privacidade e Autenticidade da Comunicação

Um professor que coloca as notas no Júpiter ou alguém que usa o webmail da USP se identificam com as suas senhas ao servidor remoto. É importante manter estas senhas secretas, por razões óbivas. Mas além das limitações do cérebro humano, que não consegue lembrar senhas complexas, tem dois outros problemas.

Primeiro: o usuário entre a senha no seu navegador (Internet Explores, FireFox, Chrome, etc.), que então manda para o servidor remoto. Qualquer um que consegue interceptar a comunicação entre o navegador e os servidores na USP pode capturar estas senhas. E não é difícil interceptar tráfego na rede. 

Segundo: como o professor ou usuário do webmail.usp.br (por exemplo) sabem que de fato estão falando com o servidor certo? Podem estar sendo enganado por um esquema de phishing.

A solução para ambas os problemas é criptografia, que consegue assegurar a privacidade, a integridade da comunicação e da autenticidade da identidade de quem está no outro lado do canal de comunicação. Se ambos os lados, o navegador e o servidor remoto, compartilham um segredo (uma senha ou chave secreto), podem construir um canal seguro de comunicação.

 

[MAS! Como falei no post anterior, encriptar sem autenticar não tem valor. Se você não sabe com quem está se comunicando, é melhor nem tentar encriptar as suas mensagens porque a sua segurança é ilusório.]

A pergunta é: como distribuir estas novas senhas/chaves secretas? Não é viável para todos os usuários do webmail.usp.br ir fisicamente no CCE para trocar um segredo. É um problema do tipo ovo e galinha: é preciso compartilhar um segredo antes de comunicação, para que o usuário possa usar a sua senha de identificação de maneira segura, mas como é possível mandar um segredo sobre um canal não-seguro?

Criptografia de chaves públicas

Criptografia de chaves públicas (ou assimétrica) parece resolver esta questão. Por incrível que pareça, é possível estabelecer um canal seguro de comunicação com alguém só sabendo um número, que pode ser público (!). Pode encriptar a sua mensagem com este número público e somente o outro lado (o dono de um número secreto correspondendo a o número público) pode decriptar. Por exemplo, se te dou este número

30 81 89 02 81 81 00 BD 0D D6 B5 20 8A 6C A2 40
E7 1C 1E 31 26 C9 97 69 B3 A7 4B FD 8E DB CE 38
79 51 F9 19 67 7B 6F D6 D5 54 6B DF 4E E0 2F 4B
A4 67 14 1B 85 A3 34 18 E5 C2 28 FF 74 7E 5B 82
6D A7 7C 91 4C EF C1 18 99 70 FF 57 AD 0B CF 6D
96 26 C2 3E 06 F0 B6 11 0E 04 9A 0E 65 FC 51 5B
7F DE 8C 20 56 09 3E 2F 1E 6E 44 56 11 33 C5 40
BE 25 9D A7 FD CE F7 17 10 DD 84 AB F5 D6 03 16
41 FA 44 86 7C DE 99 02 03 01 00 01

você pode se comunicar de forma segura com o servidor por trás do stoa.usp.br. Só o servidor do Stoa vai poder entender o que está mandando. Resolve as nossas problemas?

Não! Como você sabe que de fato este número pertence ou está associado a o domínio stoa.usp.br? Novamente, há o problema do ovo e a galinha: um impostor podia muito bem apresentar uma chave pública qualquer a um navegador desavisado. Só porque eu falei que este é a chave pública do domínio stoa.usp.br não quer dizer nada! (Como você sabe que eu sou quem estou dizendo, estamos falando de comunicação a distância).

É preciso um mecanismo que associa chaves públicas com domínios como o stoa.usp.br (ou, em geral, com nomes ou alguma outra forma de identificação). 

Certificados

Public key infrastructure seria uma solução. Neste sistema, "Autoridades Certificadores" (CA) em que todos confiam "assinam" um certificado, dizendo basicamente que esta chave pública de fato pertence a este domínio. Se visitar um site usando https (note o "s" de segura), o seu navegador e o servidor fazem uma pequena dança.

O servidor diz, "este é a minha chave pública, pode usar para encriptar (por exemplo) a sua senha". O navegador diz "ah é? como sei que é você?". O servidor mostra o seu certificado, "está vendo? este certificado diz que esta chave público pertence ao domínio "exemplo.com". O navegador pensa "hmmpf, qualquer um pode fazer um certificado fake". Mas o navegador pode checar a autenticidade do certificado pela assinatura da entidade em que todos confiam (Thawte, na imagem em baixo).

Se tudo der certo, cores tranquilizantes como azul ou verde e ícones de cadeados aparecem na barra de endereços do seu navegador.

Repare um problema: qual são as entidades que todos confiam? O governo? Uma empresa nos EUA? É o ovo e a galinha de novo! Mas aí entram os vendedores / fornecedores de navegadores e sistemas operacionais: eles dizem efetivamente qual "Autoridades Certificadores" são confiáveis. Se o chamado "certificado raiz" do CA que assinou o certificado do stoa.usp.brestá instalado no seu navegador, e

Em Windows, é o Microsoft que determina que é ou não é confiável. No FireFox, é a fundação Mozilla. [Veja este post do Ed Felten para alguns problemas deste modelo.] 

Seja como for, é esta a tecnologia que temos. Mas o que acontece se o site apresenta um certificado que não é assinado por uma entidade aprovado pelos fabricantes de navegadores? Veja o que o meu navegador faz quando um site me apresenta um certificado que não é assinado por uma entidade em que confia:

De fato, é o interface de usuário aterrorizante é correto, porque um certificado assinado por uma entidade desconhecida é indistinguível de um ataque "Man in the Middle", onde o atacante intercepta e de-codifica todo tráfego. Novamente, sem saber com quem está falando, encriptar o tráfego é completamente inútil.

Certificados auto-assinados

Na minha opinião, certificados que não são assinados por CAs já pre-instalados nos navegadores de usuários comuns, são piores do que inúteis. Existe, em princípio, a possibilidade de instalar o certificado raiz de um CA qualquer no seu navegador. Mas usuários comuns não conseguem fazer isto e de qualquer maneira, como este certificado raiz vai chegar neles de forma segura. 

Se usar certificados auto-assinados (ou atrelados a CAs não-instalados por padrão em IE ou FF) você na verdade está treinando os seu usuários a abrir exceções e não prestar mais atenção nos ícones de cadeia, etc. 

A única situação onde faz sentido usar certificados assinados é onde o administrador controla todos os computadores e navegadores que os seus usuários vão usar. Isto faz sentido num ambiente corporativo. Mas para serviços, "de consumidor", voltado para o público, é essencial que o certificado já está instalado. 

Porque na USP não se usa TLS?

Bom, alguns sites usam. Os sistemas Júpiter ou MarteWeb, do DI, usam. Mas sites importantes como o webmail.usp.br ou os webmails das unidades não usam. [O webmail da IME use um certificado auto-assinado].

Ao meu ver, a razão é que certificados são difíceis de comprar se não tiver cartão de crédito internacional, inviabilizando o uso em projetos pequenas. [Recentemente fiquei sabendo que talvez não é tão difícil: parece que pode comprar via a imprensa oficial].

Iniciei uma conversa na lista de sysadmins da USP que vou resumir num outro post.

Porque o Stoa não usa TLS?

Na verdade, usamos o ano passado, com um certificado que comprei com o meu próprio dinheiro. Agora o CCE gentilmente comprou certificados do Thawte para os domínios stoa.usp.br e moodle.usp.br. Vou configurar o Stoa em breve para que pelo menos as senhas trafegam seguramente. 

Palavras-chave: criptografia, segurança, senhas, ssl, sysadmin, tls, web

Esta mensagem está sob a licença CreativeCommons Atribuição.

Postado por Ewout ter Haar

Comentários

  1. Leonardo Silva Amaral escreveu:

    Porque na USP não se usa TLS? Bom, alguns sites usam. Os sistemas Júpiter ou MarteWeb, do DI, usam. Mas sites importantes como o webmail.usp.br ou os webmails das unidades não usam. [O webmail da IME use um certificado auto-assinado]. Ao meu ver, a razão é que certificados são difíceis de comprar se não tiver cartão de crédito internacional, inviabilizando o uso em projetos pequenas. [Recentemente fiquei sabendo que talvez não é tão difícil: parece que pode comprar via a imprensa oficial]. Iniciei uma conversa na lista de sysadmins da USP que vou resumir num outro post. --------------------------------------------- Não acho que seria um problema para uma instituição como a USP ter certificados para seus sistemas dinâmicos. Em tempo: http://www.verisign.com.br/ssl/index.html e http://www.certisign.com.br/produtos-e-servicos/certificados-para-s Francamente existem uma série de coisas nas redes da USP que ainda não entendi e uma delas é porque fazem diferente do que usualmente se faz nas redes vinculadas à RNP. Porque os campus tem que ser interligados por enlaces comerciais (Vide http://www.pop-mg.rnp.br/ por exemplo) terrivelmente pequenos (155mbps para São Carlos *via Tele(c|f)onica*)? Especulo sinceramente ser coisa do governo Serra.

    Leonardo Silva AmaralLeonardo Silva Amaral ‒ sábado, 03 abril 2010, 08:46 BRT # Link |

  2. Ewout ter Haar escreveu:

    Viu os preços dos certificados do certisign.com.br? 2, 3 mil reais! Absurdo, para um cert que nem funciona (ainda, no caso daquele emitido pelo ICP-Brasil) no FireFox). Note que não dizem em que navegadores vai funcionar! Não vejo absolutamente nenhum valor em o que efetivamente é um pedágio de 3 mil reais. Prefiro dar menos pedágio, se for a empresas americanos, que seja.

    O ICP-Brasil devia dar estes certs de graça, isso sim! Que história é esse de certisign.com.br lucrar 3 mil reais em cada cert quando o governo (ICP-Brasil) fez todo investimento e eles não gastaram nada na infra PKI? Absurdo!

    Quanto ao seu comentário sobre a conectividade da USP com a internet: é completamente off-topic. Sei que na USP temos um dos melhores conectividades do Brasil, não sei como ou porque as escolhas técnicas e estratégicas foram feitas. 

    Ewout ter HaarEwout ter Haar ‒ segunda, 05 abril 2010, 10:54 BRT # Link |

  3. Leonardo Silva Amaral escreveu:

    Bom, então que adquira-se os certificados da Verisign. Se foi algo que aprendi trabalhando em estatal é que qualquer tipo de compra é possível contanto que tenha verba para ela (Lembro-me da época que trabalhei na CEMIG e todo gasto que era necessário ser feito em CC, era feito com os cartões corporativos). O dificil é justificar a ausencia de certificado pela incapacidade de adquiri-los (Na verdade não é ser dificil ou não, é se tratar da USP).

    Sobre a conectividade, não creio ser tão offtopic assim não porque 1) É dinheiro público 2) Existe um recurso de conectivade pública próprio para redes acadêmicas - a qual a USP inclusive se conecta com e hospeda o PoP-SP. O que sempre vi no PoP-MG pelo menos e que a UFMG conecta seus enlaces por link próprio (Se bem que com o projeto do Campus 2000 eu acabei perdendo contato com o prédio da Engenharia). Sinceramente eu acho complicado manter um enlace acadêmico - público diga-se de passagem - nas mãos de empresas de telecom.

    Leonardo Silva AmaralLeonardo Silva Amaral ‒ segunda, 05 abril 2010, 13:22 BRT # Link |

Você deve entrar no sistema para escrever um comentário.

Termo de Responsabilidade

Todo o conteúdo desta página é de inteira responsabilidade do usuário. O Stoa, assim como a Universidade de São Paulo, não necessariamente corroboram as opiniões aqui contidas.