Uso do WireShark para rastrear seu SharePoint 2010 para chamadas WCF sobre SSL do Azure
Artigo original publicado no domingo, dia 20 de março de 2011
Um dos desafios interessantes da tentativa de solução de problemas de sistemas conectados remotamente é descobrir o que eles estão dizendo uns dos outros. O Kit CASI sobre o qual postei outras vezes neste blog (https://blogs.msdn.com/b/sharepoint_br/archive/2010/12/17/kit-de-integra-231-227-o-de-declara-231-245-es-azure-e-sharepoint-parte-1.aspx) é um bom exemplo cuja finalidade principal é oferecer o encanamento para conectar nuvens de centros de dados. Uma das dificuldades de solucionar problemas neste caso é que o tráfego viaja sobre SSL e, portanto, as dificuldades podem ser grandes. Considerei o uso do NetMon 3.4, que agora possui um suplemento Expert para SSL e que pode ser obtido em https://nmdecrypt.codeplex.com/, e o WireShark. pessoalmente, sempre usei o NetMon, mas tinha dificuldade de fazer o especialista em SSL e, portanto, decidi dar uma chance ao WireShark.
Parece que a WireShark já oferece suporte a SSL há alguns anos; ela só exige que você forneça a chave privada usada com o certificado SSL que esteja criptografando sua conversa. Uma vez que o serviço WCF é um dos que escrevi, é fácil de obter. Grande parte da documentação sobre a WireShark sugere que você precisa converter o PFX do seu certificado SSL (o formato que você obtém ao exportar seu certificado e inclui a chave privada) em um formato PEM. Se você leu o wiki mais recente sobre o SSL da WireShark (https://wiki.wireshark.org/SSL) embora ele não seja realmente verdadeiro. Na verdade, a Citrix tem um artigo excelente sobre como configurar a WireShark para usar SSL (https://support.citrix.com/article/CTX116557), mas as instruções são bastante ocultas em relação a que valores você deve usar para a propriedade de "lista de chaves RSA" das configurações do protocolo SSL (se não estiver certo do que seja isso, basta acompanhar o artigo de suporte da Citrix acima). Assim, para combinar esse artigo do Citrix e as informações do wiki sobre a WireShark, veja uma análise destes valores:
- Endereço IP - é o endereço IP do servidor que está enviando o conteúdo criptografado por SSL que você deseja descriptografar
- Porta - é a porta pela qual o tráfego criptografado está passando. Para um ponto de extremidade WCF, provavelmente sempre será 443.
- Protocolo - para um ponto de extremidade WCF, sempre será http
- Nome de arquivo de chave - é a localização no disco onde você possui o arquivo de chave
- Senha - se você estiver usando um certificado PFX, esse será o quinto parâmetro e a senha para desbloquear o arquivo PFX. Isso não será abordado no artigo da Citrix, mas está no wiki da WireShark.
Dessa forma, suponha que seu ponto de extremidade WCF do Azure esteja no endereço 10.20.30.40 e que você possui um certificado PFX em C:\certs\myssl.pfx com a senha "FooBar". Então, o valor que você colocaria na propriedade de lista de chaves RSA na WireShark seria:
10.20.30.40,443,http,C:\certs\myssl.pfx,FooBar.
Como alternativa, você pode baixar o OpenSSL para Windows e criar um arquivo PEM a partir de um certificado PFX. Acabei de descobrir esse download em https://code.google.com/p/openssl-for-windows/downloads/list, mas aparentemente existem vários locais de download na Web. Depois de baixar os bits apropriados ao seu hardware, você poderá criar um arquivo PEM a partir do seu certificado PFX com esta linha de comando no diretório bin do OpenSSL:
openssl.exe pkcs12 -in <unidade:\caminho\para\cert>.pfx -nodes -out <unidade:\caminho\para\novo\cert>.pem
Assim, supondo que você tenha feito isso e criado um arquivo PEM em C:\certs\myssl.pem, então sua propriedade de lista de chaves RSA na WireShark seria:
10.20.30.40,443,http,C:\certs\myssl.pem
Uma outra observação - você pode adicionar várias entradas separadas por ponto-e-vírgula. Dessa forma, por exemplo, como descrevi na série do Kit CASI, começo com um serviço WCF hospedado em meu farm local, talvez em execução na malha dev do Azure. Em seguida, publico-o no Windows Azure. Mas durante a solução de problemas, talvez eu queira acessar o serviço local ou o serviço do Windows Azure. Um dos ótimos efeitos colaterais de usar esta abordagem que descrevi no Kit CASI de usar um certificado curinga é que ele me permite usar o mesmo certificado SSL para a minha instância local e para a instância do Windows Azure. Então, na WireShark, também posso usar o mesmo certificado para descriptografar tráfego simplesmente especificando duas entradas como esta (suponha que meu serviço WCF local esteja em execução no endereço IP 192.168.20.100):
10.20.30.40,443,http,C:\certs\myssl.pem;192.168.20.100,443,http,C:\certs\myssl.pem
Este é o básico da configuração da WireShark, que eu realmente poderia ter usado ontem de madrugada. :-) Agora, o outro ponto realmente complicado é descriptografar o SSL. O principal problema é, de acordo com o trabalho que tive com ele, que você precisa garantir que está capturando durante a negociação com o ponto de extremidade SSL. Infelizmente, descobri que, com os diversos comportamentos de cache do IE e do Windows, era muito difícil fazer isso realmente acontecer quando estava tentando rastrear minhas chamadas WCF vindas do navegador por meio do Kit CASI. Em cerca de duas horas de tentativas no navegador, só terminei obtendo um rastreamento de volta ao meu ponto de extremidade do Azure que realmente consegui descriptografar na WireShark e, portanto, estava quase ficando louco. Ao meu resgate, novamente, veio o Cliente de Teste do WCF.
A maneira que encontrei para que isso funcione de forma consistente é:
- Inicie a WireShark e comece uma captura.
- Inicie o Cliente de Teste WCF
- Adicione uma referência de serviço ao seu WCF (seja o seu WCF local ou o WCF do Windows Azure)
- Chame um ou mais métodos em seu WCF a partir do Cliente de Teste WCF.
- Vá para a WireShark e pare a captura.
- Localize qualquer quadro onde o protocolo diga TLSV1
- Clique com o botão direito do mouse nele e selecione Seguir Fluxo SSL no menu
Uma caixa de diálogo aparecerá e deverá mostrar a você o conteúdo descriptografado da conversa. Se a conversa estiver vazia, provavelmente isso significa que ou a chave privada não foi carregada corretamente ou a captura não incluiu a sessão negociada. Se funcionar, será muito legal, porque você poderá ver toda a conversa, ou somente a parte do remetente ou somente do destinatário. Veja um rápido trecho do que obtive de um rastreamento para meu método WCF sobre SSL para o Windows Azure:
POST /Customers.svc HTTP/1.1
Content-Type: application/soap+xml; charset=utf-8
Host: azurewcf.vbtoys.com
Content-Length: 10256
Expect: 100-continue
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
HTTP/1.1 100 Continue
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Server: Microsoft-IIS/7.0
X-Powered-By: ASP.NET
Date: Sat, 19 Mar 2011 18:18:34 GMT
Content-Length: 2533
<s:Envelope xmlns:s="https://www.w3.org/2003/05/soap-envelope" blá, blá, blá
E isto é tudo; demorou um pouco para fazer isso funcionar e espero que isso ajude você a entrar no modo de solução de problemas um pouco mais depressa do que eu.
Esta é uma postagem de blog traduzida. Encontre o artigo original em Using WireShark to Trace Your SharePoint 2010 to Azure WCF Calls over SSL