Segurança de Transporte HTTP
Ao usar HTTP como transporte, a segurança é fornecida por uma implementação SSL (Secure Sockets Layer). SSL é amplamente utilizado na Internet para autenticar um serviço para um cliente e, em seguida, para fornecer confidencialidade (criptografia) para o canal. Este artigo explica como o SSL funciona e como ele é implementado no Windows Communication Foundation (WCF).
SSL básico
Como o SSL funciona é melhor explicado através de um cenário típico, neste caso, o site de um banco. O site permite que um cliente faça logon com um nome de usuário e senha. Depois de ser autenticado, o usuário pode realizar transações, como visualizar saldos de contas, pagar contas e mover 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, chamadas de handshake, com o cliente do usuário (no caso, o navegador da web). O SSL primeiro autentica o site do banco para o cliente. Este é um passo essencial porque os clientes devem primeiro saber que estão se comunicando com o site real, e não uma falsificação que tenta atraí-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 a VeriSign. A lógica é a seguinte: a VeriSign garante a identidade do site do banco. Como o navegador confia na VeriSign, o site é confiável. Se você quiser verificar com a VeriSign, você também pode fazê-lo clicando no logotipo da VeriSign. Que apresenta uma declaração de autenticidade com a sua data de validade e para quem é emitida (o site do banco).
Para iniciar uma sessão segura, o cliente envia o equivalente a um "olá" para o servidor, juntamente com uma lista de algoritmos criptográficos que pode usar para assinar, gerar hashes e criptografar e descriptografar. Em resposta, o site envia de volta um reconhecimento e sua escolha de um dos conjuntos de algoritmos. Durante este aperto de mão 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 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, para que ambos os lados possam gerar o mesmo hash. Portanto, o cliente valida o hash enviado pelo serviço (a) usando o algoritmo acordado para calcular o hash a partir dos dados e (b) comparando-o com o hash enviado pelo serviço; Se os dois corresponderem, o cliente tem a garantia de que o hash não foi adulterado. O cliente pode então usar esse hash como uma chave para criptografar uma mensagem que contém outro novo hash. O serviço pode descriptografar a mensagem usando o hash e recuperar esse hash do segundo 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 é então usada para criptografar e descriptografar mensagens para o resto da sessão. Como o cliente e o serviço usam a mesma chave, isso também é chamado de chave de sessão.
A chave de 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 permita 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, porque o protocolo pode variar de site para site. Também é possível que tanto o cliente quanto 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 serviço também envia seu certificado SSL para o cliente. O certificado contém informações, como sua data de validade, autoridade emissora e o URI (Uniform Resource Identifier) 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. Em resumo, a chave privada é conhecida apenas pelo proprietário do certificado, enquanto a chave pública é legível a partir do certificado. Qualquer chave pode ser usada para criptografar ou descriptografar um resumo, 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 encriptar com a chave privada, o cliente pode desencriptar com a chave pública. Isso fornece garantia ao cliente de que as mensagens estão sendo trocadas apenas com o detentor da chave privada, porque apenas as mensagens criptografadas com a chave privada podem ser descriptografadas com a chave pública. O site tem a certeza de que está trocando mensagens com um cliente que foi criptografado usando a chave pública. Esta troca é segura apenas para um aperto de mão inicial, no entanto, é por isso que muito mais é feito para criar a chave simétrica real. No entanto, todas as comunicações dependem de o serviço ter um certificado SSL válido.
Implementando SSL com WCF
A segurança de transporte HTTP (ou SSL) é fornecida externamente ao WCF. Você pode implementar SSL de duas maneiras; O fator decisivo é como seu aplicativo é hospedado:
Se você estiver usando o IIS (Serviços de Informações da Internet) como host WCF, use a infraestrutura do IIS para configurar um serviço SSL.
Se você estiver criando um aplicativo WCF auto-hospedado, poderá vincular um certificado SSL ao endereço usando a ferramenta HttpCfg.exe.
Usando o IIS para segurança de transporte
IIS 7.0
Para configurar o IIS 7.0 como um host seguro (usando SSL), consulte Configurando o Secure Sockets Layer no IIS 7.0.
Para configurar certificados para uso com o IIS 7.0, consulte Configurando certificados de servidor no IIS 7.0.
IIS 6.0
Para configurar o IIS 6.0 como um host seguro (usando SSL), consulte Configurando o Secure Sockets Layer.
Para configurar certificados para uso com o IIS 6.0, consulte Certificates_IIS_SP1_Ops.
Usando HttpCfg para SSL
Se você 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.