HTTPS 규정 준수 설정에서 구형 TLS 프로토콜을 비활성화하려면 어떻게 해야 하나요?

HTTPS 규정 준수 설정에서 구버전 TLS를 비활성화하는 일반적인 방법은 TLS 1.0, TLS 1.1 및 그 이전의 SSL 프로토콜을 끄고 TLS 1.2를 유지하며, 서버에서 지원하는 경우 TLS 1.3을 활성화하는 것입니다. 하지만 요구 사항 충족 여부는 적용되는 보안 기준, 암호화 스위트, 인증서 및 실제 적용 범위에도 달려 있으므로 프로토콜 버전만으로 판단할 수는 없습니다.

작업 전에 먼저 확인해야 할 사항은 다음과 같습니다. 브라우저의 TLS 연결은 어디에서 종료되나요? 웹사이트에 CDN, WAF 또는 로드 밸런서가 연결되어 있다면 원본 서버 설정만 변경해도 공개 인터넷에 노출된 진입점에서 구버전 프로토콜을 계속 허용할 수 있습니다.

수정이 필요한 HTTPS 진입점 모두 파악하기

해외 무역 기업의 공식 웹사이트, 크로스보더 쇼핑몰 및 광고 랜딩 페이지는 흔히 “방문자—CDN/WAF—로드 밸런서—원본 서버”로 이어지는 접속 경로를 사용합니다. 각 구간에서 별도로 수립되는 TLS 연결마다 자체 프로토콜 설정이 있습니다. 중간 장비가 트래픽을 단순 전달하는 경우에는 실제로 TLS를 종료하는 백엔드 구성 요소가 설정을 제어합니다.

서버 대수가 아니라 도메인과 수신 대기 포트를 기준으로 정리하는 것이 좋습니다.

• 공개 인터넷 진입점: 기본 도메인, www 하위 도메인, 다국어 사이트, 쇼핑몰, API 및 광고 랜딩 페이지.
• 원본 서버 연결 경로: CDN과 로드 밸런서 간 연결, 리버스 프록시와 애플리케이션 서비스 간 HTTPS 연결.
• 우회 진입점: 직접 연결할 수 있는 원본 서버 주소, 보조 도메인, 관리 진입점 및 기타 HTTPS 포트.

CDN의 “최소 TLS 버전”은 일반적으로 방문자 연결을 제어하며, 원본 서버로 연결할 때 사용할 프로토콜은 별도로 설정해야 합니다. 원본 서버 연결에 여전히 HTTP를 사용한다면 공개 인터넷 측 검사에 통과했더라도 전체 연결 경로가 암호화되었다고 볼 수 없습니다.

허용할 프로토콜을 명확히 지정하기

구버전을 하나씩 제외하는 것보다 허용할 프로토콜을 명확하게 지정하는 편이 더 이해하기 쉽습니다. 설정하기 전에 웹 서버와 연결된 TLS 라이브러리가 목표 버전을 지원하는지 확인해야 합니다. 설정 파일에 TLS 1.3을 기재했다고 해서 현재 환경에서 이를 제공할 수 있는 것은 아닙니다.

Nginx 설정 예시

적절한 설정 컨텍스트에 다음을 지정합니다.

ssl_protocols TLSv1.2 TLSv1.3;

모든 사이트에 동일한 정책을 적용한다면 http 계층에서 통합 관리하고, 각 server에 설정을 덮어쓰는 항목이 있는지 확인합니다. 동일한 주소와 포트에서 여러 HTTPS 가상 호스트를 제공하는 경우 기본 가상 호스트도 확인해야 합니다. 프로토콜 협상은 기본 서버 설정의 영향을 받을 수 있으므로 대상 도메인이 포함된 설정 블록만 수정해서는 안 됩니다.

저장한 뒤 먼저 구문을 확인하고 서비스를 다시 불러옵니다.

nginx -t
nginx -s reload

구문 검사가 성공한 경우에만 설정을 불러와야 합니다. 컨테이너, 클러스터 또는 관리형 환경에서는 해당 배포 절차에 따라 업데이트하고 모든 인스턴스에 동일한 설정이 적용되었는지 확인해야 합니다. 그래야 일부 요청이 이전 노드로 계속 전달되는 상황을 방지할 수 있습니다.

Apache 및 관리형 플랫폼에서의 처리 방법

Apache에서는 SSLProtocol 지시문으로 프로토콜을 제한할 수 있습니다. 해당 버전을 지원하는 환경에서는 다음과 같이 설정할 수 있습니다.

SSLProtocol -all +TLSv1.2 +TLSv1.3

전역 설정, 가상 호스트 설정 및 상속 관계도 함께 확인합니다. CDN, 클라우드 로드 밸런서 또는 SaaS 웹사이트 구축 플랫폼을 사용하는 경우 실제로 TLS를 처리하는 콘솔에서 최소 버전을 조정하고, 방문자 연결과 원본 서버 연결을 각각 확인해야 합니다.

易营宝와 같이 웹사이트 구축과 마케팅 서비스를 통합 제공하는 플랫폼을 이용하는 경우 웹 페이지, 마케팅 도메인, CDN 및 원본 서버를 서로 다른 담당자가 관리할 수 있습니다. 적용 전에 각 진입점의 설정 책임과 검증 방법을 명확히 해야 합니다. “플랫폼에 인증서를 배포했다”는 사실만으로 “모든 진입점에서 구버전 프로토콜이 비활성화되었다”고 간주해서는 안 됩니다.

검증을 통해 “구버전은 거부되고 신버전은 사용 가능함”을 모두 입증해야 합니다

브라우저에서 웹사이트가 열린다는 사실은 어떤 프로토콜로든 협상이 성공했다는 것만 보여 줄 뿐, 구버전이 비활성화되었음을 입증하지는 않습니다. 동일한 도메인에 지정된 각 버전으로 핸드셰이크를 별도로 시도해야 합니다.

openssl s_client -connect example.com:443 -servername example.com -tls1
openssl s_client -connect example.com:443 -servername example.com -tls1_1
openssl s_client -connect example.com:443 -servername example.com -tls1_2
openssl s_client -connect example.com:443 -servername example.com -tls1_3

예시 도메인을 실제 도메인으로 바꿉니다. TLS 1.0과 TLS 1.1은 핸드셰이크를 완료할 수 없어야 하고, TLS 1.2는 정상적으로 연결되어야 합니다. TLS 1.3을 제공할 계획이라면 해당 버전도 연결에 성공하는지 검증해야 합니다. -servername은 SNI를 전달하여 잘못된 가상 호스트에 요청이 연결되는 것을 방지합니다.

구버전 프로토콜 테스트에서 오류가 발생했다고 해서 반드시 서버가 연결을 거부한 것은 아닙니다. 로컬 OpenSSL에서 구버전 프로토콜을 이미 금지했거나 사용할 수 있는 구버전 암호화 스위트가 없을 수 있습니다. 클라이언트가 핸드셰이크를 보내기 전에 실패했다면 이 결과는 서버에서 프로토콜을 비활성화했다는 증거가 될 수 없습니다. 오류 메시지를 함께 확인하고, 해당 프로토콜을 탐지할 수 있는 TLS 스캔 도구로 교차 검증해야 합니다.

공개 도메인과 원본 서버를 각각 확인해야 합니다. 원본 서버에 직접 연결할 때는 -connect를 원본 서버 IP로 바꾸고, -servername으로 도메인을 지정하면 됩니다. IPv4, IPv6, 보조 진입점 및 서로 다른 배포 노드도 모두 확인해야 합니다. 검수 및 후속 문제 해결을 위해 검사 시간, 대상 주소 및 협상 결과를 기록해 두십시오.

업무 연결 경로를 통해 호환성을 확인하기

구형 운영 체제, 임베디드 장치 또는 장기간 업데이트되지 않은 API 클라이언트는 설정 변경 후 연결하지 못할 수 있습니다. 배포 전에 연결 로그, 호출자 목록 및 업무 테스트를 통해 의존성을 파악하고, 특히 문의 제출, 결제 페이지 이동, 주문 콜백, 마케팅 데이터 API 및 타사 동기화 작업을 확인해야 합니다.

호환성 문제는 우선 클라이언트, 실행 환경 또는 API 구성 요소를 업그레이드하여 해결해야 합니다. 과도기 조치가 꼭 필요한 경우에는 격리된 전용 진입점을 검토하고 접근 범위를 제한하며 종료 시점을 명확히 해야 합니다. 오래된 호출자 하나 때문에 주 웹사이트 전체에서 구버전 프로토콜을 다시 허용해서는 안 됩니다. 단계적 배포 기간에는 핸드셰이크 오류, 콜백 실패 및 주요 양식의 결과를 모니터링해야 합니다. 페이지가 열린다고 해서 거래 또는 고객 확보 경로가 정상적으로 작동하는 것은 아닙니다.

구버전 TLS 비활성화가 HTTPS 작업의 전부는 아닙니다. TLS 1.2에서도 암호화 스위트를 검토해야 하며, 인증서 체인, 도메인 일치, 만료 관리 및 혼합 콘텐츠도 각각 처리해야 합니다. HTTP 리디렉션과 HSTS는 각각 별도의 역할을 하며 프로토콜 제한을 대신할 수 없습니다. 작업 완료 시 진입점 목록, 적용된 설정 및 검증 기록을 함께 남기고, 이후 마케팅 도메인을 추가하거나 CDN을 이전할 때도 동일한 기준으로 점검해야 합니다.