Freigeben über

WireShark를 사용하여 SSL를 통한 SharePoint 2010에서 Azure WCF로의 호출 추적

  • Artikel

최초 문서 게시일: 2011년 3월 20일 일요일

원격으로 연결된 시스템의 문제를 해결할 때의 까다로운 작업 중 하나는 각 시스템이 서로 교환하는 내용을 파악하는 것입니다. 예전에 이 블로그에 게시했던 CASI Kit(https://blogs.msdn.com/b/sharepoint_ko/archive/2010/12/17/azure-sharepoint-1.aspx)는 데이터 센터 클라우드를 서로 연결하는 용도로 주로 사용되는 도구의 좋은 예입니다. 그런데 트래픽이 SSL을 통해 전송되어 문제를 해결하기가 어려운 경우가 있습니다. 이러한 경우 문제를 원활하게 해결하기 위해 https://nmdecrypt.codeplex.com/(영문일 수 있음)에서 다운로드할 수 있는 SSL용 고급 추가 기능인 NetMon 3.4와, WireShark를 모두 사용해 보았습니다. 개인적으로는 항상 NetMon을 사용해 왔지만 SSL과 관련한 고급 정보를 확인하기가 다소 어려워 WireShark를 사용해 보기로 했습니다.

WireShark는 약 2년 전부터 SSL을 지원하기 시작했습니다. WireShark를 사용하려면 대화를 암호화하는 SSL 인증서와 함께 사용되는 개인 키만 제공하면 됩니다. 제 경우에는 WCF 서비스를 직접 작성했기 때문에 개인 키를 쉽게 얻을 수 있었습니다. WireShark와 관련된 많은 문서에서는 SSL 인증서의 PFX(인증서를 내보내고 개인 키를 포함할 때 사용되는 형식)를 PEM 형식으로 변환해야 한다는 설명이 나와 있습니다. 그러나 최신 WireShark SSL Wiki(https://wiki.wireshark.org/SSL(영문일 수 있음))에는 반드시 이와 같이 변환하지 않아도 된다는 내용이 있습니다. 실제로 Citrix에는 SSL을 사용하도록 WireShark를 구성하는 방법에 대해 자세하게 설명하는 문서(https://support.citrix.com/article/CTX116557(영문일 수 있음))가 게시되어 있는데, 이 문서에서는 SSL 프로토콜 설정의 "RSA 키 목록" 속성에서 사용해야 하는 값과 관련한 내용이 너무 애매하게 나와 있습니다(위 링크를 클릭하여 Citrix 지원 문서를 확인해 보십시오). Citrix 문서와 WireShark Wiki의 정보를 조합해 보면, 대략적으로 다음과 같은 값을 사용할 수 있습니다.

  • IP 주소 - 암호 해독할 SSL로 암호화된 콘텐츠를 보내는 서버의 IP 주소입니다.
  • 포트 - 암호화된 트래픽이 유입되는 포트입니다. WCF 끝점의 경우에는 항상 443일 확률이 높습니다.
  • 프로토콜 - WCF 끝점의 경우에는 항상 http여야 합니다.
  • 키 파일 이름 - 키 파일이 저장되는 디스크의 위치입니다.
  • 암호 - PFX 인증서를 사용하는 경우에는 5번째 매개 변수(PFX 파일의 잠금을 해제하는 암호)입니다. Citrix 문서에는 암호에 대한 내용이 없지만 WireShark Wiki에는 해당 내용이 나와 있습니다.

Azure WCF 끝점의 주소가 10.20.30.40이고 PFX 인증서가 C:\certs\myssl.pfx에 있으며 암호는 "FooBar"라고 가정해 보겠습니다. 그러면 WireShark의 RSA 키 목록 속성에 입력하는 값은 다음과 같습니다.

10.20.30.40,443,http,C:\certs\myssl.pfx,FooBar.

Windows용 OpenSSL을 다운로드하고 PFX 인증서에서 PEM 파일을 만들 수도 있습니다. 제 경우에는 https://code.google.com/p/openssl-for-windows/downloads/list(영문일 수 있음)에서 다운로드했는데, 웹에서 다운로드할 수 있는 다른 곳도 많은 것 같네요. 사용 중인 하드웨어에 적합한 OpenSSL을 다운로드한 후에는 OpenSSL bin 디렉터리에서 아래 명령줄을 사용하여 PFX 인증서에서 PEM 파일을 만들 수 있습니다.

openssl.exe pkcs12 -in <drive:\path\to\cert>.pfx -nodes -out <drive:\path\to\new\cert>.pem

이 명령을 실행하여 C:\certs\myssl.pem에 PEM 파일을 만든 경우 WireShark의 RSA 키 목록 속성은 다음과 같습니다.

10.20.30.40,443,http,C:\certs\myssl.pem

여러 항목을 세미콜론으로 구분하여 추가할 수도 있습니다. 예를 들어 CASI Kit 시리즈 게시물에서 설명한 것처럼 먼저 로컬 팜에서 호스팅되는 WCF 서비스(Azure 개발 패브릭에서 실행될 수 있음)를 작성한 다음 Windows Azure에 게시할 수 있습니다. 이렇게 해 두고 문제를 해결할 때는 로컬 서비스 또는 Windows Azure 서비스를 사용할 수 있습니다. CASI kit에서 설명한 와일드카드 인증서를 사용하는 방식의 경우, 두 로컬 인스턴스 및 Windows Azure 인스턴스 모두에 대해 같은 SSL 인증서를 사용할 수 있다는 '부작용 아닌 부작용'이 있습니다. 따라서 WireShark에서도 이와 같은 두 항목을 지정하면 트래픽 암호를 해독하는 데 동일한 인증서를 사용할 수 있습니다. 로컬 WCF 서비스가 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

이와 같은 방식을 통해 WireShark를 기본적으로 설정합니다. 저 역시 같은 방법을 사용했고요. 문제 해결 시의 또 다른 까다로운 작업은 SSL의 암호를 해독하는 것입니다. 제 경험상 가장 큰 문제는 SSL 끝점과의 협상 중에 정보가 캡처되는지를 확인해야 한다는 것입니다. 그러나 IE와 Windows의 다양한 캐싱 동작으로 인해, CASI Kit를 통해 브라우저에서 수행한 WCF 호출을 추적할 때 이러한 정보를 실제로 캡처하기란 매우 어려웠습니다. 2시간 넘게 브라우저에서 작업을 해 보았지만, Azure 끝점으로 반환되어 WireShark에서 암호를 해독할 수 있었던 추적은 단 하나뿐이었을 정도로 힘든 작업이었는데요. 그래서 여기서도 WCF 테스트 클라이언트를 사용하게 되었습니다. 

다음과 같은 과정을 통해 이 작업을 일관성 있게 수행할 수 있었습니다.

  1. WireShark를 시작하고 캡처를 시작합니다.
  2. WCF 테스트 클라이언트를 시작합니다.
  3. WCF(로컬 WCF 또는 Windows Azure WCF)에 대한 서비스 참조를 추가합니다.
  4. WCF 테스트 클라이언트에서 WCF에 대해 메서드를 하나 이상 호출합니다.
  5. WireShark로 돌아가서 캡처를 중지합니다.
  6. 프로토콜이 TLSV1인 프레임을 찾습니다.
  7. 프레임을 마우스 오른쪽 단추로 클릭하고 메뉴에서 Follow SSL Stream(SSL 스트림 따라가기) 을 선택합니다.

그러면 대화에서 암호화되지 않은 콘텐츠를 보여 주는 팝업 대화 상자가 표시됩니다. 대화가 비어 있으면 개인 키가 올바르게 로드되지 않았거나 캡처에 협상된 세션이 포함되지 않은 것입니다. 대화가 제대로 캡처된 경우에는 전체 대화나 발신자 또는 수신자의 대화 내용만 볼 수 있으므로 매우 효과적입니다. 제가 SSL을 통해 Windows Azure에 대해 WCF 메서드를 호출하여 추적한 내용은 다음과 같습니다.

  • 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" 등등

제 경우 이 캡처 내용을 얻는 데까지 시간이 많이 걸렸는데요, 여러분은 이 블로그의 내용을 참조하셔서 좀 더 빠르게 문제를 해결하시기를 바랍니다.

이 문서는 번역된 블로그 게시물입니다. 원본 문서는 Using WireShark to Trace Your SharePoint 2010 to Azure WCF Calls over SSL을 참조하십시오.

 So there you have it; it took me a while to get this all working so hopefully this will help you get into troubleshooting mode a little quicker than I did.