Apache TLS 1.0·1.1 차단 후 외부에서 다시 열리는 이유

TLS 1.0과 TLS 1.1을 끄라는 보안 요구는 이제 예외적인 일이 아니다. IETF는 2021년 RFC 8996에서 두 버전을 폐기 단계로 분류했고 NIST와 PCI DSS도 구버전 TLS 사용을 제한한다. 그런데 Apache 설정 한 줄을 바꾼 뒤 내부에서는 차단된 것처럼 보이는데, 외부 검사에서는 여전히 구버전 TLS가 발견될 때가 있다. 이 차이를 설명하려면 실제 서비스 경로에서 어느 장비가 TLS를 종료하는지부터 확인해야 한다. (datatracker.ietf.org)

TLS 1.0과 1.1을 끄는 이유는 분명하다

TLS 1.0과 TLS 1.1은 단순히 이름만 오래된 프로토콜이 아니다. RFC 8996에 따르면 두 버전은 최신 암호 알고리즘과 메커니즘을 충분히 지원하지 못한다. 유지해야 할 프로토콜 선택지가 늘어 오설정 가능성도 커진다. TLS 1.2는 2008년부터 권장됐고 TLS 1.3은 2018년에 표준화됐다. (datatracker.ietf.org)

브라우저와 결제 보안 기준도 같은 방향으로 움직였다. Mozilla는 Firefox에서 TLS 1.0과 1.1을 기본 비활성화하겠다고 발표했고 PCI DSS는 SSL과 초기 TLS를 강한 암호화로 인정하지 않는다. 구버전 차단은 특정 스캐너의 점수를 올리는 일이 아니다. 외부에 노출된 모든 TLS 종단점의 정책을 정리하는 작업이다. (blog.mozilla.org)

Apache 설정은 맞아도 적용 지점이 다를 수 있다

Apache mod_ssl의 SSLProtocol은 서버 설정과 가상호스트에서 사용할 수 있다. SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1은 구버전 프로토콜을 제외한다. 다만 all에 포함되는 버전은 Apache가 연결한 OpenSSL 버전에 따라 달라질 수 있다. Apache 문서도 all을 사용 가능한 프로토콜의 묶음으로 설명한다. (httpd.apache.org)

운영 환경에서는 허용 목록을 직접 쓰는 편이 더 읽기 쉽다. TLS 1.2와 1.3을 지원하는 환경이라면 SSLProtocol -all +TLSv1.2 +TLSv1.3처럼 정책을 명시할 수 있다. 단, TLS 1.3에는 OpenSSL 1.1.1 이상이 필요하다. Apache 버전만 보고 설정 가능 여부를 판단해서는 안 되며 구형 배포판에서는 TLS 1.2만 지정해야 할 수도 있다. (httpd.apache.org)

설정을 바꾼 뒤에는 apachectl configtest로 문법을 확인하고 apachectl -S로 실제 읽힌 가상호스트를 확인해야 한다. 첫 번째 가상호스트가 기본 서버로 선택되거나 예상과 다른 443 블록에 설정을 넣었다면, 파일 내용이 맞아도 요청에는 적용되지 않는다. Apache 공식 문서에 따르면 -S는 설정을 파싱한 결과와 IP·서버 이름 매핑을 보여준다. (httpd.apache.org)

내부와 외부 결과가 갈리는 핵심은 TLS 종단점이다

외부 사용자가 접속하는 주소가 곧 Apache라는 보장은 없다. DNS 앞에 CDN이나 외부 로드밸런서가 있고 그 뒤에 Apache가 있다면, 외부 클라이언트와 처음 TLS를 맺는 장비는 앞단일 수 있다. 앞단에서 TLS를 종료한 뒤 Apache에는 HTTP로 전달할 수도 있고 다시 HTTPS를 맺어 재암호화할 수도 있다. 두 구간은 서로 다른 TLS 세션이어서 허용 버전도 달라질 수 있다. Apache의 reverse proxy 문서도 프록시가 외부 요청을 백엔드로 전달하고 부하분산 그룹을 구성할 수 있다고 설명한다. (httpd.apache.org)

이 구조에서는 내부망에서 백엔드 IP를 직접 검사한 결과와 외부 도메인을 검사한 결과가 달라도 이상하지 않다. 내부 검사는 Apache의 443 포트를 보고 외부 검사는 로드밸런서의 리스너나 CDN의 정책을 보는 셈이다. DNS가 여러 IP를 반환하거나 IPv4와 IPv6가 서로 다른 장비로 연결될 때도 검사 위치가 달라진다.

운영자들의 경험담도 비슷하다. 설정을 바꿨는데 외부 스캔 결과가 그대로라면 앞단 CDN의 정책이 남아 있거나 다른 도메인·포트·IP를 검사했을 가능성을 먼저 의심한다는 반응이 많다. 점수보다 어떤 IP와 TLS 종단점이 응답했는지 확인해야 한다는 의견도 있다. 경험담만으로 원인을 확정할 수는 없지만 “Apache 파일이 바뀌었으니 외부도 같아야 한다”는 가정은 경계할 만하다. (reddit.com)

외부에서 열린다는 주장을 재현하는 방법

같은 이름을 놓고 내부와 외부에서 각각 검증해야 한다. dig 또는 nslookup으로 도메인의 A·AAAA 레코드와 응답 IP를 확인한다. 여러 IP가 나오면 각각 검사하고 필요하면 SNI를 유지한 채 특정 IP에 접속한다. 도메인 이름 없이 IP만 검사하면 기본 가상호스트가 선택돼 실제 사용자 경로와 다른 결과가 나올 수 있다.

프로토콜별 연결은 OpenSSL이나 testssl.sh로 나눠 확인할 수 있다. openssl s_client -connect example.com:443 -servername example.com -tls1과 -tls1_1로 각각 연결을 시도하고 성공 여부와 서버 인증서의 주체를 기록한다. 다만 최신 OpenSSL 자체가 안전하지 않은 프로토콜을 거부할 수 있다. 실패 메시지가 서버 차단을 뜻하는지 클라이언트 정책 때문인지 구분해야 한다.

testssl.sh는 서버가 지원하는 TLS 프로토콜과 암호군을 명령줄에서 점검할 수 있고 내부망에서도 실행할 수 있다. Nmap의 ssl-enum-ciphers도 여러 TLS 연결을 만들어 서버가 받아들이는 프로토콜과 암호군을 열거한다. 두 도구 모두 외부 도메인과 내부 IP를 같은 조건으로 비교할 때 유용하다. (nmap.org)

차단 작업은 설정 변경보다 경로 확인이 먼저다

점검 순서는 간단하다. 외부 도메인의 DNS 응답을 확인하고 외부 IP별로 TLS 버전을 검사한다. 이어 로드밸런서·CDN·방화벽·Apache의 443 리스너를 순서대로 대조한다. Apache에서는 apachectl -S로 대상 가상호스트를 찾고 apachectl configtest 후 graceful reload를 수행한다. 그다음 내부 백엔드 주소와 외부 도메인을 다시 검사해 어느 구간에서 결과가 달라지는지 기록한다.

Apache가 reverse proxy로 백엔드에 HTTPS 연결을 만드는 구조라면 클라이언트 구간과 별도로 SSLProxyProtocol 정책도 살펴야 한다. 외부 클라이언트 연결을 TLS 1.2 이상으로 제한했더라도 Apache와 백엔드 사이의 정책은 별도일 수 있다. 외부에서 TLS 1.0이 보인다면 Apache 내부 설정만 반복해서 고치지 말고 가장 바깥쪽 TLS 종료 장비의 보안 정책과 리스너를 확인해야 한다. (httpd.apache.org)

이번 문제의 답은 특정 설정 문자열 하나가 아니다. SSLProtocol은 필요한 출발점이지만 외부 사용자가 실제로 만나는 장비와 가상호스트, IP 경로를 함께 확인해야 차단 결과를 증명할 수 있다. 내부와 외부의 검사 결과가 다르다면 “설정이 실패했다”보다 “서로 다른 TLS 종단점을 검사했다”는 가설을 먼저 세우는 편이 빠르다.