Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 3개 있습니다.)

C# - WebClient로 https 호출 시 "The request was aborted: Could not create SSL/TLS secure channel" 예외 발생

오랜만에 간단하게 .NET 4 환경에서 WebClient를 사용했더니,

// 아래의 테스트 환경 결과는 레지스트리 설정, 윈도우 업데이트 패치 등의 영향에 따라 가변적일 수 있으니 유의해야 합니다.

// [클라이언트의 경우, 최소 Windows 10+ 이상의 환경]
// [서버의 경우, 최소 Windows Server 2016+ 환경]
// 1. .NET Framework 4.6+ 타겟으로 빌드하면 예외 발생하지 않음.
// 2.                4.5 이하로 빌드 후 단순히 app.config에 sku=".NETFramework,Version=v4.6"을 지정해도 예외 발생.
// 3. .NET Core로 빌드하면 예외 발생하지 않음.

using System;
using System.Net;

internal class Program
{
    static void Main(string[] args)
    {
        WebClient wc = new WebClient();

        try
        {
            wc.DownloadString("https://shinyoungjin.life/rss.xml");
        }
        catch (Exception ex)
        {
            Console.WriteLine(ex.ToString());
        }
    }
}

실행 시 이런 예외가 발생합니다.

// 4.x 응용 프로그램의 경우
C:\test\ConsoleApp1\bin\Debug>ConsoleApp1.exe
System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.
   at System.Net.WebClient.DownloadDataInternal(Uri address, WebRequest& request)
   at System.Net.WebClient.DownloadString(Uri address)
   at ConsoleApp1.Program.Main(String[] args) in C:\test\ConsoleApp1\Program.cs:line 17

// 4.x 미만 응용 프로그램의 경우
Unhandled Exception: System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: Received an unexpected EOF or 0 bytes from the transport stream.
   at System.Net.FixedSizeReader.ReadPacket(Byte[] buffer, Int32 offset, Int32 count)
   at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)
   at System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size)
   at System.Net.PooledStream.Write(Byte[] buffer, Int32 offset, Int32 size)
   at System.Net.ConnectStream.WriteHeaders(Boolean async)
   --- End of inner exception stack trace ---
   at System.Net.WebClient.DownloadDataInternal(Uri address, WebRequest& request)
   at System.Net.WebClient.DownloadString(Uri address)
   at Program.Main(String[] args)

디버거를 이용해 좀 더 세밀하게 예외 상황을 보면 WebException 이전에 이미 "System.Security.Authentication.AuthenticationException" 예외가 발생했고 이때의 메시지는 좀 더 자세한 정보를 담고 있습니다.

System.Security.Authentication.AuthenticationException
  HResult=0x80131501
  Message=A call to SSPI failed, see inner exception.
  Source=System
  StackTrace:
   at System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, Exception exception) in f:\dd\NDP\fx\src\net\System\Net\SecureProtocols\_SslState.cs:line 984

Inner Exception 1:
Win32Exception: The function requested is not supported

다행히 검색해 보면 답이 나옵니다. ^^

A call to SSPI failed, see inner exception - The Local Security Authority cannot be contacted
; https://stackoverflow.com/questions/37925505/a-call-to-sspi-failed-see-inner-exception-the-local-security-authority-cannot

그러니까, WebClient가 나온 지 꽤나 오래돼서 ^^; 당시에 기본 옵션이었던 Ssl3/Tls로는 더 이상 https 서버와 통신이 안 되었던 것입니다.

따라서, 혹시나 있을 기존 https 서버와의 호환을 고려해야 한다면 이렇게 코딩을 추가할 수 있습니다.

// SecurityProtocolType.Tls12 == 3072 (0xC00)

// .NET Framework 4.5.2 이하인 경우
// ServicePointManager.SecurityProtocol의 기본값 == SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls

// .NET Framework 4.6 이상인 경우
// ServicePointManager.SecurityProtocol의 기본값 == Tls | Tls11 | Tls12 | Tls13;

ServicePointManager.SecurityProtocol |= SecurityProtocolType.Tls12;

Console.WriteLine(wc.DownloadString("https://shinyoungjin.life/rss.xml"));

SecurityProtocolType에 Tls12 상수가 추가된 것은 .NET 4.5부터라서 만약 .NET 4.0 이하의 프로그램에서 사용해야 한다면 직접 상수를 기재해도 됩니다.

ServicePointManager.SecurityProtocol |= (SecurityProtocolType)3072;




만약 코드 변경을 원하지 않는다면 app.config을 바꿔도 됩니다. 일례로, AppContextSwitchOverrides를 이용해 다음과 같이 설정해 주면,

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <runtime>
        <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=false" />
    </runtime>
</configuration>

"ServicePointManager.SecurityProtocol |= SecurityProtocolType.Tls12;" 코드 설정 없이도 WebClient 호출에 예외가 발생하지 않습니다. 그런데 좀 이상하군요, CA5361의 정적 검사에서도 DontEnableSchUseStrongCrypto 옵션을 보안상 true로 설정하지 말라고 권고하고 있는데... ^^; 다시 말해 그동안 기본값이 true였던 것입니다.





코드 변경을 하지 않는 또 다른 방법은 레지스트리 설정입니다. 이런 경우, .NET Framework 4.5 이하의 프로그램에 대해서도 Tls12 (또는, 최신 버전의 보안 프로토콜) 설정이 적용되도록 강제할 수 있다는 장점이 있는데요, 방법은 다음의 문서에 잘 나와 있습니다.

How to enable TLS 1.2 on the site servers and remote site systems
 - Configure for strong cryptography
; https://learn.microsoft.com/en-us/mem/configmgr/core/plan-design/security/enable-tls-1-2-server#configure-for-strong-cryptography
// 64비트 운영체제/64비트 응용 프로그램, 32비트 운영체제/32비트 응용 프로그램에 대해
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]
      "SystemDefaultTlsVersions" = dword:00000001
      "SchUseStrongCrypto" = dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
      "SystemDefaultTlsVersions" = dword:00000001
      "SchUseStrongCrypto" = dword:00000001

// 64비트 운영체제에서 32비트 응용 프로그램에 대해
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727]
      "SystemDefaultTlsVersions" = dword:00000001
      "SchUseStrongCrypto" = dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
      "SystemDefaultTlsVersions" = dword:00000001
      "SchUseStrongCrypto" = dword:00000001




참고로, 제어판에서 지역 설정 창의 "Beta: Use Unicode UTF-8 for worldwide language support" 옵션을 체크하지 않은 경우 위에서 만든 코드를 통해 반환한 텍스트의 한글이 깨져 있는 문제가 있습니다.

이에 대해서도 예전에 쓴 글이 있는데요, ^^

WebClient.DownloadString 문자열 인코딩 문제
; https://www.sysnet.pe.kr/2/0/1493

그나저나, 이런 문제는 근래의 HttpClient를 사용하면 발생하지 않으므로... 이젠 머나먼 과거의 이야기가 될 것입니다.




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 1/30/2023]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




... 61  62  63  64  65  66  67  68  [69]  70  71  72  73  74  75  ...
NoWriterDateCnt.TitleFile(s)
12085정성태12/20/201914106오류 유형: 586. iisreset - The data is invalid. (2147942413, 8007000d) 오류 발생 - 두 번째 이야기 [1]
12084정성태12/19/201914776디버깅 기술: 143. windbg/sos - Hashtable의 buckets 배열 내용을 모두 덤프하는 방법 (do_hashtable.py) [1]
12083정성태12/17/201917173Linux: 27. linux - lldb를 이용한 .NET Core 응용 프로그램의 메모리 덤프 분석 방법 [2]
12082정성태12/17/201915933오류 유형: 585. lsof: WARNING: can't stat() fuse.gvfsd-fuse file system
12081정성태12/16/201917851개발 환경 구성: 465. 로컬 PC에서 개발 중인 ASP.NET Core 웹 응용 프로그램을 다른 PC에서도 접근하는 방법 [5]
12080정성태12/16/201915633.NET Framework: 870. C# - 프로세스의 모든 핸들을 열람
12079정성태12/13/201916925오류 유형: 584. 원격 데스크톱(rdp) 환경에서 다중 또는 고용량 파일 복사 시 "Unspecified error" 오류 발생
12078정성태12/13/201916757Linux: 26. .NET Core 응용 프로그램을 위한 메모리 덤프 방법 [3]
12077정성태12/13/201916427Linux: 25. 자주 실행할 명령어 또는 초기 환경을 "~/.bashrc" 파일에 등록
12076정성태12/12/201914353디버깅 기술: 142. Linux - lldb 환경에서 sos 확장 명령어를 이용한 닷넷 프로세스 디버깅 - 배포 방법에 따른 차이
12075정성태12/11/201915091디버깅 기술: 141. Linux - lldb 환경에서 sos 확장 명령어를 이용한 닷넷 프로세스 디버깅
12074정성태12/10/201914743디버깅 기술: 140. windbg/Visual Studio - 값이 변경된 경우를 위한 정지점(BP) 설정(Data Breakpoint)
12073정성태12/10/201916713Linux: 24. Linux/C# - 실행 파일이 아닌 스크립트 형식의 명령어를 Process.Start로 실행하는 방법
12072정성태12/9/201913956오류 유형: 583. iisreset 수행 시 "No such interface supported" 오류
12071정성태12/9/201916567오류 유형: 582. 리눅스 디스크 공간 부족 및 safemode 부팅 방법
12070정성태12/9/201918835오류 유형: 581. resize2fs: Bad magic number in super-block while trying to open /dev/.../root
12069정성태12/2/201914862디버깅 기술: 139. windbg - x64 덤프 분석 시 메서드의 인자 또는 로컬 변수의 값을 확인하는 방법
12068정성태11/28/201923074디버깅 기술: 138. windbg와 Win32 API로 알아보는 Windows Heap 정보 분석 [3]파일 다운로드2
12067정성태11/27/201915074디버깅 기술: 137. 실제 사례를 통해 Debug Diagnostics 도구가 생성한 닷넷 웹 응용 프로그램의 성능 장애 보고서 설명 [1]파일 다운로드1
12066정성태11/27/201914831디버깅 기술: 136. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석 - OracleCommand.ExecuteReader에서 OpsSql.Prepare2 PInvoke 호출 분석
12065정성태11/25/201913631디버깅 기술: 135. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석파일 다운로드1
12064정성태11/25/201916076오류 유형: 580. HTTP Error 500.0/500.33 - ANCM In-Process Handler Load Failure
12063정성태11/21/201915001디버깅 기술: 134. windbg - RtlReportCriticalFailure로부터 parameters 정보 찾는 방법
12062정성태11/21/201915029디버깅 기술: 133. windbg - CoTaskMemFree/FreeCoTaskMem에서 발생한 덤프 분석 사례 - 두 번째 이야기
12061정성태11/20/201915502Windows: 167. CoTaskMemAlloc/CoTaskMemFree과 윈도우 Heap의 관계
12060정성태11/20/201915841디버깅 기술: 132. windbg/Visual Studio - HeapFree x64의 동작 분석
... 61  62  63  64  65  66  67  68  [69]  70  71  72  73  74  75  ...