TLS 1.0 문제 해결, 2차 버전

이 문서에서는 Microsoft 운영 체제를 기반으로 하여 빌드된 소프트웨어의 TLS(전송 계층 보안) 프로토콜 버전 1.0 종속성을 빠르게 식별하고 제거하는 방법에 대한 최신 지침을 제공하며, 사용자 고유의 고객과 온라인 서비스를 보호하기 위해 Microsoft에서 제공하는 제품 변경 내용 및 새로운 기능에 대한 자세한 정보를 제공합니다. TLS 1.2 이상 네트워크 환경으로 마이그레이션 계획을 빌드하기 위한 시작점으로 사용됩니다. 여기서 설명하는 솔루션은 이월되어 타사 운영 체제 또는 암호화 라이브러리에서 TLS 1.0 사용을 제거하는 데 도움이 될 수 있지만 이 문서의 초점은 아닙니다.

TLS 1.0은 컴퓨터 네트워크를 통한 암호화 채널을 설정하기 위해 1999년에 처음 정의된 보안 프로토콜입니다. Microsoft는 Windows XP/Server 2003부터 이 프로토콜을 지원해 왔다. 최신 OS에서 사용하는 기본 보안 프로토콜은 더 이상 없지만 TLS 1.0은 이전 버전과의 호환성을 위해 계속 지원됩니다. TLS 1.0의 새로운 보안 취약성뿐만 아니라 진화하는 규제 요구 사항은 기업에게 TLS 1.0을 완전히 사용하지 않도록 설정하는 인센티브를 제공합니다.

고객은 환경에서 TLS 1.0 종속성을 제거하고, 가능한 경우 운영 체제 수준에서 TLS 1.0을 사용하지 않도록 설정하여 이 문제를 적시에 해결하는 것이 좋습니다. 소프트웨어 업계에서 TLS 1.0을 지원하는 기간을 고려할 때 TLS 1.0 사용 중단 계획에는 다음이 포함되는 것이 좋습니다.

• TLS 1.0 또는 이전 보안 프로토콜의 하드 코딩된 인스턴스를 찾아서 수정하기 위한 코드 분석입니다.

• TLS 1.0 또는 이전 프로토콜을 사용하여 운영 체제를 식별하기 위한 네트워크 엔드포인트 검사 및 트래픽 분석

• TLS 1.0을 사용하지 않도록 설정된 상태에서 전체 애플리케이션 스택에 대한 전체 재발 테스트

• 레거시 운영 체제와 개발 라이브러리/프레임워크를 기본적으로 TLS 1.2를 협상할 수 있는 버전으로 마이그레이션

• 비즈니스에서 TLS 1.2 지원 문제를 식별하는 데 사용하는 운영 체제 간 호환성 테스트입니다.

• TLS 1.0 사용 중단 조치를 알리기 위한 사용자의 비즈니스 파트너 및 고객과의 조정

• TLS 1.0을 사용하지 않도록 설정하면 서버에 더 이상 연결할 수 없는 클라이언트를 이해합니다.

이 문서는 TLS 1.0을 사용하지 않도록 설정하는 기술 차단을 제거하는 동시에 이 변경이 고객에게 미치는 영향을 쉽게 확인할 수 있는 데 도움이 되는 추천 사항을 제공하기 위한 것입니다. 이러한 조사를 완료하면 TLS 1.0에서 다음 보안 취약성의 비즈니스 영향을 줄일 수 있습니다. 이 문서의 목적을 위해 TLS 1.0의 사용 중단에 대한 참조에는 TLS 1.1도 포함됩니다.

엔터프라이즈 소프트웨어 개발자는 향후 보안 프로토콜 손상에 대처하기 위해 보다 안전하고 민첩한 솔루션(Crypto Agility라고도 함)을 채택해야 하는 전략적 요구 사항이 있습니다. 이 문서에서는 TLS 하드코딩을 제거하는 민첩한 솔루션을 제안하지만, 광범위한 Crypto Agility 솔루션은 이 문서의 범위를 벗어버칩니다.

Microsoft의 TLS 1.0 구현에 대한 현재 상태

Microsoft의 TLS 1.0 구현 에는 알려진 보안 취약성이 없습니다. 향후 프로토콜 다운그레이드 공격 및 기타 TLS 1.0 취약성이 Microsoft 구현과 관련이 없기 때문에 가능한 경우 TLS 1.2보다 오래된 모든 보안 프로토콜에 대한 종속성을 제거하는 것이 좋습니다(TLS 1.1/1.0/ SSLv3/SSLv2).

TLS 1.2 이상으로의 마이그레이션을 계획할 때 개발자와 시스템 관리자는 직원 및 파트너가 개발한 애플리케이션에서 프로토콜 버전 하드코딩의 가능성을 알고 있어야 합니다. 여기서 하드 코딩한다는 것은 TLS 버전이 최신 버전보다 오래되고 안전하지 않은 버전으로 고정됨을 의미합니다. 하드 코드된 버전보다 최신 TLS 버전은 해당 프로그램을 수정하지 않고는 사용할 수 없습니다. 소스 코드 변경 및 소프트웨어 업데이트 배포 없이는 이 문제 클래스를 해결할 수 없습니다. 프로토콜 버전 하드코딩은 과거에 여러 브라우저와 운영 체제에서 다양한 수준의 TLS 지원을 받았기 때문에 테스트 및 지원 가능성을 위해 일반적이었습니다.

Windows에서 지원되는 TLS 버전

대부분의 운영 체제에는 오래된 TLS 버전 기본값 또는 고려해야 하는 최대값이 지원됩니다.

그림 1: OS 버전별 보안 프로토콜 지원

Windows OS	SSLv2	SSLv3	TLS 1.0	TLS 1.1	TLS 1.2	TLS 1.3
Windows Vista	사용	사용	사용	지원되지 않음	지원되지 않음	지원되지 않음
Windows Server 2008	사용	사용	사용	사용 안 함*	사용 안 함*	지원되지 않음
Windows 7(WS2008 R2)	사용	사용	사용	사용 안 함*	사용 안 함*	지원되지 않음
Windows 8(WS2012)	사용 안 함	사용	사용	사용	사용	지원되지 않음
Windows 8.1(WS2012 R2)	사용 안 함	사용	사용	사용	사용	지원되지 않음
Windows 10	사용 안 함	사용	사용	사용	사용	지원되지 않음
Windows 11	사용 안 함	사용	사용	사용	사용	사용
Windows Server 2016	지원되지 않음	사용 안 함	사용	사용	사용	지원되지 않음
Windows Server 2016	지원되지 않음	사용 안 함	사용	사용	사용	지원되지 않음
Windows Server 2019	지원되지 않음	사용 안 함	사용	사용	사용	지원되지 않음
Windows Server 2019 GS 버전	지원되지 않음	사용 안 함	사용 안 함	사용 안 함	사용	지원되지 않음
Windows Server 2022	지원되지 않음	사용 안 함	사용 안 함	사용 안 함	사용	사용

Windows Server 2019 GS 버전은 Microsoft SDL 규격이며, TLS 1.2는 제한된 암호화 도구 모음 집합에만 적용됩니다.

Windows Server 2022 버전은 Microsoft SDL 규격, TLS 1.2 및 TLS 1.3이며 암호화 제품군의 제한된 집합만 포함됩니다.

이 선택적 Windows 업데이트 패키지를 통해 Windows Server 2008에서 TLS 1.1/1.2를 사용하도록 설정할 수 있습니다.

IE/Edge의 TLS 1.0/1.1 사용 중단에 대한 자세한 내용은 Microsoft Edge 및 Internet Explorer 11에서 TLS 연결 현대화, Microsoft Edge에 제공되는 사이트 호환성에 영향을 미치는 변경 내용 및 새 Edge 브라우저에서 TLS/1.0 및 TLS/1.1을 사용하지 않도록 설정

Qualys SSL Labs의 핸드셰이크 시뮬레이션을 참조하여 온라인 서비스 연결할 때 다양한 클라이언트가 요청할 TLS 버전을 빠르게 확인할 수 있습니다. 이 시뮬레이션에서는 제조업체 간의 클라이언트 OS/브라우저 조합을 다룹니다. www.microsoft.com 연결할 때 다양한 시뮬레이션된 클라이언트 OS/브라우저 조합으로 협상된 TLS 프로토콜 버전을 보여 주는 자세한 예제는 이 문서의 끝에 있는 부록 A를 참조하세요.

아직 완료되지 않은 경우, 회사, 고객 및 파트너가 사용하는 운영 체제의 인벤토리를 수행하는 것이 좋습니다(후자의 두 주체는 지원/통신 또는 최소한 HTTP 사용자-에이전트 문자열 컬렉션을 통해). 이 인벤토리는 엔터프라이즈 네트워크 에지의 트래픽 분석을 통해 추가로 보완할 수 있습니다. 이러한 상황에서 트래픽 분석은 서비스에 연결하는 고객/파트너가 성공적으로 협상한 TLS 버전을 생성하지만 트래픽 자체는 다시 암호화되지 기본.

TLS 1.0 종속성을 제거하기 위한 Microsoft의 엔지니어링 개선 사항

이 문서의 v1 릴리스 이후 Microsoft는 TLS 1.0 사용 중단을 지원하는 여러 소프트웨어 업데이트와 새로운 기능을 제공했습니다. 여기에는 다음이 포함됩니다.

• 클라이언트 IP/사용자 에이전트 문자열, 서비스 URI, TLS 프로토콜 버전 및 암호 그룹을 상호 연결하는 IIS 사용자 지정 로깅 입니다.

  • 이 로깅을 사용하면 관리자는 마침내 약한 TLS에 대한 고객의 노출을 정량화할 수 있습니다.

• SecureScore - Office 365 테넌트 관리자가 자신의 약한 TLS 사용량을 식별할 수 있도록 2018년 10월 Office 365에서 TLS 1.0이 지원을 종료함에 따라 SecureScore 포털이 이 정보를 공유하도록 빌드되었습니다.

  • 이 포털은 자체 TLS 1.0 종속성을 알지 못하는 Office 365 테넌트 관리자의 고객에게 전달하는 데 필요한 중요한 정보를 이 관리자에게 제공합니다.

  • 자세한 내용은 https://securescore.microsoft.com/을 방문하세요.

• 앱 수준 하드코딩을 제거하고 프레임워크 상속 TLS 1.0 종속성을 방지하기 위한 .Net Framework 업데이트입니다.

• 고객이 취약한 TLS에 대한 .Net 종속성을 식별하고 제거하는 데 도움이 되도록 개발자 지침 및 소프트웨어 업데이트가 릴리스되었습니다(.NET Framework를 사용한 TLS(전송 계층 보안) 모범 사례).

  • 참고: .NET 4.5 이하를 대상으로 하는 모든 앱은 TLS 1.2를 지원하기 위해 수정해야 할 수 있습니다.

• 레거시 의무를 수행하는 고객을 지원하기 위해 TLS 1.2는 Windows Server 2008 SP2 및 XP POSReady 2009로 백포팅되었습니다.

• 더 많은 공지 사항은 2019년 초에 발표될 예정이며 이 문서의 후속 업데이트에서 전달될 예정입니다.

코드에서 TLS 1.0 종속성 찾기 및 수정

Windows OS에서 제공하는 암호화 라이브러리 및 보안 프로토콜을 사용하는 제품의 경우 다음 단계를 통해 애플리케이션에서 하드 코딩된 TLS 1.0 사용을 식별할 수 있습니다.

1. AcquireCredentialsHandle()의 모든 인스턴스를 식별합니다. 이렇게 하면 검토자가 TLS를 하드 코딩할 수 있는 코드 블록에 더 근접할 수 있습니다.

2. 하드 코딩된 TLS에 대한 SecPkgContext_SupportedProtocols 및 SecPkgContext_커넥트ionInfo 구조의 인스턴스를 검토합니다.

3. 네이티브 코드에서 grbitEnabledProtocols의 0이 아닌 할당을 0으로 설정합니다. 이를 통해 운영 체제에서 기본 TLS 버전을 사용할 수 있습니다.

4. 이 문서에서 TLS 1.0/1.1을 명시적으로 사용하지 않도록 설정하는 데 필요한 설정과 충돌할 가능성이 있으므로 FIPS 모드를 사용하도록 설정하는 경우 FIPS 모드를 사용하지 않도록 설정합니다. 자세한 내용은 부록 B를 참조하세요.

5. Server 2012 이상에서 호스트되는 WinHTTP를 사용하여 모든 애플리케이션을 업데이트하고 다시 컴파일합니다.

   1. 관리형 앱 – 최신 .NET Framework 버전에 대해 다시 빌드하고 대상을 변경합니다.

   2. 애플리케이션에서 WinHttpSetOption을 통해 TLS 1.2를 지원하는 코드를 추가해야 합니다.

6. 모든 기본을 포함하려면 TLS 하드코딩에 일반적으로 사용되는 열거형 형식 값에 해당하는 아래 패턴에 대한 소스 코드 및 온라인 서비스 구성 파일을 검색합니다.

   1. SecurityProtocolType

   2. SSLv2, SSLv23, SSLv3, TLS1, TLS 10, TLS11

   3. WINHTTP_FLAG_SECURE_PROTOCOL_

   4. SP_PROT_

   5. NSStreamSocketSecurityLevel

   6. PROTOCOL_SSL 또는 PROTOCOL_TLS

위의 모든 경우에 권장되는 솔루션은 하드 코딩된 프로토콜 버전 선택을 제거하고 운영 체제 기본값으로 연기하는 것입니다. DevSkim을 사용하는 경우 여기를 클릭하여 사용자 고유의 코드와 함께 사용할 수 있는 위의 검사 다루는 규칙을 확인합니다.

Windows PowerShell 스크립트 또는 관련 레지스트리 설정 업데이트

Windows PowerShell은 TLS 1.2를 사용 가능한 프로토콜로 포함하지 않는 .NET Framework 4.5를 사용합니다. 이 해결을 위해 다음 두 가지 솔루션을 사용할 수 있습니다.

1. 다음을 포함하도록 해당 스크립트를 수정합니다.

   [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12;
   

2. .NET 앱에서 TLS 1.2 연결을 설정해야 하는 모든 컴퓨터에 시스템 차원의 레지스트리 키(예: 그룹 정책을 통해)를 추가합니다. 이로 인해 .NET은 TLS 1.2를 사용 가능한 프로토콜로 추가하는 "시스템 기본" TLS 버전을 사용하고 OS에서 지원하는 경우 스크립트가 향후 TLS 버전을 사용할 수 있도록 합니다. (예: TLS 1.3)

   reg add HKLM\SOFTWARE\Microsoft.NETFramework\v4.0.30319 /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /f /reg:64

   reg add HKLM\SOFTWARE\Microsoft.NETFramework\v4.0.30319 /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /f /reg:32

솔루션(1) 및 (2)는 상호 배타적이므로 함께 구현할 필요가 없습니다.

최신 .Net Framework 버전을 사용하여 관리되는 애플리케이션 다시 빌드/대상 다시 지정

4.7 이전의 .NET Framework 버전을 사용하는 애플리케이션은 기본 OS 기본값에 관계없이 TLS 1.0에 대한 지원을 효과적으로 제한하는 제한 사항이 있을 수 있습니다. 자세한 내용은 .NET Framework를 사용한 아래 다이어그램 및 TLS(전송 계층 보안) 모범 사례를 참조하세요.

SystemDefaultTLSVersion은 TLS 버전의 앱 수준 대상 지정보다 우선합니다. 권장되는 모범 사례는 항상 OS 기본 TLS 버전을 연기하는 것입니다. 또한 앱이 향후 TLS 1.3 지원을 활용할 수 있는 유일한 암호화 민첩 솔루션이기도 합니다.

4.5.2 또는 3.5와 같은 이전 버전의 .NET Framework를 대상으로 하는 경우 기본적으로 애플리케이션은 SSL 3.0 또는 TLS 1.0과 같이 권장되지 않는 이전 프로토콜을 사용합니다. .NET Framework 4.6과 같은 최신 버전의 .NET Framework로 업그레이드하거나 'UseStrongCrypto'에 적절한 레지스트리 키를 설정하는 것이 좋습니다.

TLS 1.2 이상을 사용하여 테스트

위의 섹션에서 권장하는 수정 사항에 따라 프로토콜 협상 오류 및 엔터프라이즈의 다른 운영 체제와의 호환성을 위해 제품을 회귀 테스트해야 합니다.

• 이 회귀 테스트에서 가장 일반적인 문제는 TLS 1.2를 지원하지 않는 운영 체제 또는 브라우저의 클라이언트 연결 시도로 인한 TLS 협상 실패입니다.

  • 예를 들어 Vista 클라이언트는 Vista의 지원되는 최대 TLS 버전이 1.0이므로 TLS 1.2 이상에 대해 구성된 서버와 TLS를 협상하지 못합니다. 해당 클라이언트는 TLS 1.2 이상 환경에서 업그레이드되거나 서비스 해제되어야 합니다.

• 인증서 기반 상호 TLS 인증을 사용하는 제품은 TLS 1.0과 연결된 인증서 선택 코드가 TLS 1.2보다 덜 표현적이었기 때문에 추가 회귀 테스트가 필요할 수 있습니다.

  • 제품이 표준이 아닌 위치(Windows의 표준 명명된 인증서 저장소 외부)에서 인증서와 MTLS를 협상하는 경우 해당 코드는 인증서를 올바르게 획득하도록 업데이트해야 할 수 있습니다.

• 문제 지점에 대한 서비스 상호 종속성을 검토해야 합니다.

  • 3개의 rd-party 서비스와 상호 운용하는 모든 서비스는 해당 3^{개 rd} 당사자와 추가 interop 테스트를 수행해야 합니다.

  • 사용 중인 비 Windows 애플리케이션 또는 서버 운영 체제는 TLS 1.2를 지원할 수 있는지 조사/확인이 필요합니다. 검색은 이를 확인하는 가장 쉬운 방법입니다.

온라인 서비스에서 이러한 변경을 테스트하기 위한 간단한 청사진은 다음과 같이 구성됩니다.

1. 프로덕션 환경 시스템을 검사하여 TLS 1.2를 지원하지 않는 운영 체제를 식별합니다.

2. "코드에서 TLS 1.0 종속성 찾기 및 수정"에 설명된 대로 하드 코딩된 TLS에 대한 소스 코드 및 온라인 서비스 구성 파일을 검색합니다.

3. 필요에 따라 애플리케이션을 업데이트/다시 컴파일합니다.

   1. 관리형 앱

      1. 최신 .NET Framework 버전에 대해 다시 빌드합니다.

      2. OS 기본 설정을 사용하기 위해 SSLProtocols 열거형의 사용이 SSLProtocols.None으로 설정되어 있는지 확인합니다.

   2. WinHTTP 앱 – WinHttpSetOption을 사용하여 다시 빌드하여 TLS 1.2 지원

4. 레지스트리를 통해 TLS 1.2 이전의 모든 보안 프로토콜을 사용하지 않도록 설정 하여 사전 프로덕션 또는 스테이징 환경에서 테스트를 시작합니다.

5. TLS 하드코딩의 재기본 인스턴스가 테스트 중에 발견되면 수정합니다. 소프트웨어를 다시 배포하고 새 회귀 테스트 실행을 수행합니다.

파트너에게 TLS 1.0 사용 중단 계획 알림

TLS 하드코딩이 해결되고 운영 체제/개발 프레임워크 업데이트가 완료된 후 TLS 1.0을 더 이상 사용하지 않도록 선택하면 고객 및 파트너와 조정해야 합니다.

• TLS 1.0 사용 중단을 성공적으로 롤아웃하려면 초기 파트너/고객의 지원이 필수적입니다. 최소한 블로그 게시물, 백서 또는 기타 웹 콘텐츠로 구성되어야 합니다.

• 파트너는 각각 위의 섹션에서 설명한 운영 체제/코드 검사/회귀 테스트 이니셔티브를 통해 자체 TLS 1.2 준비 상태를 평가해야 합니다.

결론

TLS 1.0 종속성을 제거하는 것은 엔드투엔드 드라이브에 복잡한 문제입니다. Microsoft 및 업계 파트너는 현재 OS 구성 요소 및 개발 프레임워크에서 이를 기반으로 하여 빌드된 애플리케이션/서비스까지 전체 제품 스택을 기본적으로 더 안전하게 보호하기 위해 이러한 작업을 수행하고 있습니다. 이 문서의 권장 사항에 따라 엔터프라이즈가 올바른 과정을 차트로 작성하고 예상되는 과제를 파악하는 데 도움이 됩니다. 또한 고객이 전환에 더 많은 준비를 하는 데 도움이 됩니다.

부록 A: www.microsoft.com 연결하는 다양한 클라이언트를 위한 핸드셰이크 시뮬레이션, 무료 SSLLabs.com

부록 B: FIPS 모드를 유지하면서 TLS 1.0/1.1 사용 중단

네트워크에 FIPS 모드가 필요하지만 TLS 1.0/1.1을 더 이상 사용하지 않으려면 아래 단계를 따릅니다.

1. 원치 않는 TLS 버전 에 대해 "사용"을 0으로 설정하여 레지스트리를 통해 TLS 버전을 구성합니다.

2. 그룹 정책을 통해 Curve 25519(Server 2016에만 해당)를 사용하지 않도록 설정합니다.

3. 관련 FIPS 게시에서 허용하지 않는 알고리즘을 사용하여 모든 암호 그룹을 사용하지 않도록 설정합니다. 서버 2016의 경우(기본 설정이 적용된 것으로 가정) 이는 RC4, PSK 및 NULL 암호화를 사용하지 않도록 설정하는 것을 의미합니다.

기여자/감사드리는 분

Mark Cartwright
브라이언 설리번
패트릭 정글스
마이클 스코베타
토니 라이스
데이비드 르블랑
모티머 쿡
Daniel Sommerfeld
Andrei Popov
미치코 쇼트
저스틴 버크
정부 마하라지
브래드 터너
숀 스티븐슨