Segurança de transporte de HTTP
Ao usar HTTP como transporte, a segurança é fornecida por uma implementação do protocolo SSL. O SSL é amplamente usado na Internet para autenticar um serviço para um cliente e, em seguida, para fornecer confidencialidade (criptografia) ao canal. Este artigo explica como o SSL funciona e como ele é implementado no Windows Communication Foundation (WCF).
SSL básico
A forma como o SSL funciona é melhor explicada por meio de um cenário típico, nesse caso, um site de um banco. O site permite que um cliente faça logon com um nome de usuário e senha. Depois de autenticado, o usuário pode executar transações, como exibir saldos de conta, pagar contas e transferir dinheiro de uma conta para outra.
Quando um usuário visita o site pela primeira vez, o mecanismo SSL inicia uma série de negociações, chamada de handshake, com o cliente do usuário (nesse caso, o navegador da Web). O SSL autentica primeiro o site do banco para o cliente. Essa é uma etapa essencial porque os clientes devem primeiro saber que estão se comunicando com o site real e não uma falsificação que tenta convencê-los a digitar seu nome de usuário e senha. O SSL faz essa autenticação usando um certificado SSL fornecido por uma autoridade confiável, como o VeriSign. A lógica é a seguinte: o VeriSign atesta a identidade do site do banco. Como o navegador confia no VeriSign, o site é confiável. Se você quiser verificar com o VeriSign, também poderá fazer isso clicando no logotipo do VeriSign. Isso apresenta uma declaração de autenticidade com sua data de validade e para quem ela é emitida (o site do banco).
Para iniciar uma sessão segura, o cliente envia o equivalente a um "olá" para o servidor junto com uma lista de algoritmos de criptografia que ele pode usar para assinar, gerar hashes e criptografar e descriptografar. Em resposta, o site envia de volta uma confirmação e sua escolha de um dos conjuntos de algoritmos. Durante esse handshake inicial, ambas as partes enviam e recebem nonces. Um nonce é um dado gerado aleatoriamente que é usado, em combinação com a chave pública do site, para criar um hash. Um hash é um novo número derivado dos dois números usando um algoritmo padrão, como SHA1. (O cliente e o site também trocam mensagens para concordar com qual algoritmo de hash usar.) O hash é exclusivo e é usado apenas para a sessão entre o cliente e o site para criptografar e descriptografar mensagens. O cliente e o serviço têm o nonce original e a chave pública do certificado; portanto, ambos os lados podem gerar o mesmo hash. Portanto, o cliente valida o hash enviado pelo serviço por (a) usando o algoritmo acordado para calcular o hash dos dados e (b) comparando-o com o hash enviado pelo serviço; se os dois corresponderem, o cliente terá a garantia de que o hash não foi adulterado. Em seguida, o cliente pode usar esse hash como uma chave para criptografar uma mensagem que contém mais um novo hash. O serviço pode descriptografar a mensagem usando o hash e recuperar esse hash do segunda ao final. As informações acumuladas (nonces, chave pública e outros dados) agora são conhecidas por ambos os lados, e um hash final (ou chave mestra) pode ser criado. Essa chave final é enviada criptografada usando o penúltimo hash. A chave mestra é usada para criptografar e descriptografar mensagens para o restante da sessão. Como o cliente e o serviço usam a mesma chave, isso também é chamado uma chave da sessão.
A chave da sessão também é caracterizada como uma chave simétrica ou um "segredo compartilhado". Ter uma chave simétrica é importante porque reduz a computação exigida por ambos os lados da transação. Se cada mensagem exigisse uma nova troca de nonces e hashes, o desempenho se deterioraria. Portanto, o objetivo final do SSL é usar uma chave simétrica que permite que as mensagens fluam livremente entre os dois lados com um maior grau de segurança e eficiência.
A descrição anterior é uma versão simplificada do que acontece, pois o protocolo pode variar de site para site. Também é possível que o cliente e o site gerem nonces que são combinados algoritmicamente durante o handshake para adicionar mais complexidade e, portanto, proteção ao processo de troca de dados.
Certificados e infraestrutura de chave pública
Durante o handshake, o servidor também envia seu certificado SSL ao cliente. O certificado contém informações, como a data de validade, a autoridade emissora e o Uniform Resource Identifier (URI) do site. O cliente compara o URI com o URI que havia contatado originalmente para garantir uma correspondência e também verifica a data e a autoridade emissora.
Cada certificado tem duas chaves, uma chave privada e uma chave pública, e as duas são conhecidas como um par de chaves de troca. Resumidamente, a chave privada é conhecida apenas pelo proprietário do certificado enquanto a chave pública é legível no certificado. Qualquer chave pode ser usada para criptografar ou descriptografar um resumo da mensagem, hash ou outra chave, mas apenas como operações contrárias. Por exemplo, se o cliente criptografar com a chave pública, somente o site poderá descriptografar a mensagem usando a chave privada. Da mesma forma, se o site criptografar com a chave privada, o cliente poderá descriptografar com a chave pública. Isso fornece garantia ao cliente de que as mensagens estão sendo trocadas apenas com o possuidor da chave privada porque somente as mensagens criptografadas com a chave privada podem ser descriptografadas com a chave pública. O site tem a garantia de que está trocando mensagens com um cliente criptografado usando a chave pública. Entretanto, essa troca é segura apenas para um handshake inicial e é por isso que muito mais é feito para criar a chave simétrica real. No entanto, todas as comunicações dependem do serviço ter um certificado SSL válido.
Implementando o SSL com o WCF
A segurança de transporte HTTP (ou SSL) é fornecida externamente ao WCF. Você pode implementar o SSL de duas maneiras; o fator decisivo é como seu aplicativo é hospedado:
Se você estiver usando os Serviços de Informações da Internet (IIS) como host do WCF, use a infraestrutura do IIS para configurar um serviço SSL.
Se estiver criando um aplicativo WCF auto-hospedado, você pode associar um certificado SSL ao endereço usando a ferramenta HttpCfg.exe.
Usando os IIS para segurança do transporte
IIS 7.0
Para configurar o IIS 7.0 como um host seguro (usando SSL), consulte Configurar o protocolo SSL no IIS 7.0.
Para configurar certificados para uso com o IIS 7.0, consulte Configurar certificados do servidor no IIS 7.0.
IIS 6,0
Para configurar o IIS 6.0 como um host seguro (usando SSL), consulte Configurar o protocolo SSL.
Para configurar certificados para uso com o IIS 6.0, consulte Certificates_IIS_SP1_Ops.
Usando HttpCfg para SSL
Se estiver criando um aplicativo WCF auto-hospedado, use a ferramenta HttpCfg.exe.
Para obter mais informações sobre como usar a ferramenta HttpCfg.exe para configurar uma porta com um certificado X.509, consulte Como configurar uma porta com um certificado SSL.