TLS 검사 문제 해결

서론

이 문서는 TLS 검사에 대한 고급 문제 해결 시나리오를 다룹니다. 진행하기 전에 TLS 검사 구성 및 동작을 검토하여 트래픽이 어떻게 처리되고 적용되는지 이해하는 것이 권장됩니다.

일반적인 조건에서는 TLS 검사가 최종 사용자에게 보이지 않습니다. 트래픽이 검사되고 있는지 확인하려면 계정 이벤트의 TLS 검사 필드를 확인하세요 (1 = 검사됨, 0 = 우회됨), 브라우저에서 인증서 발급자를 검토하세요 (Cato Networks), 또는 TLS 검사 보고서를 사용하세요.

Cato는 유명 애플리케이션, 장치, 도메인에 대해 기본 우회 규칙을 포함합니다. 이 시스템 관리 규칙은 수정할 수 없으며 사용자 정의 규칙을 만들기 전에 항상 검토해야 합니다. 추가 세부 정보를 보려면 기본 우회 규칙을 참조하세요.

증상

가능한 원인

대부분의 TLS 검사 문제는 몇 가지 일반적인 조건과 관련이 있습니다.

  • 일부 애플리케이션은 TLS 검사와 호환되지 않습니다. 인증서 고정, 엄격한 TLS 검증, 상호 TLS를 사용하는 애플리케이션은 가로채기를 거부하고 연결을 실패합니다.

  • 클라이언트의 인증서 신뢰 문제는 또 다른 일반적인 원인입니다. Cato 루트 인증서가 누락되었거나 신뢰할 수 없거나 일관성 있게 배포되지 않은 경우, 정책이 올바르더라도 검사된 트래픽이 실패합니다.

  • 다른 경우에는 문제가 대상 서버에서 발생합니다. 만료된 인증서, 불완전한 체인, 호스트명 불일치, 또는 알 수 없는 인증 기관 같은 문제는 TLS 검사가 활성화되었을 때 브라우저에 항상 표시되지 않지만, PoP에 의해 적용됩니다.

  • 레거시 시스템은 TLS 프로토콜 또는 암호 불일치로 인해 실패할 수 있습니다. 구식 TLS 버전을 사용하거나 취약한 암호 스위트를 사용하는 애플리케이션은 TLS 검사 정책에 정의된 요구 사항을 충족하지 않을 수 있습니다.

  • 현대적인 웹사이트는 여러 종속적인 도메인으로 인해 문제를 일으킬 수 있습니다. 지원 도메인은 차단되거나 다르게 검사되는 동안 메인 도메인만 허용 또는 우회되면 사용자가 느린 로딩이나 누락된 콘텐츠를 경험할 수 있습니다.

  • 마지막으로, 플랫폼 특정 행동이 작용합니다. 모바일 장치, BYOD 엔드포인트 및 Linux 시스템은 인증서 신뢰 한계, 애플리케이션 특정 검증, 또는 기본 우회 규칙으로 인해 다르게 작동할 수 있습니다.

초기 문제 해결

TLS 관련 문제를 조사할 때 기본 목표는 문제가 클라이언트, 네트워크 (TLS 검토), 또는 대상 서버에서 발생하는지 여부를 결정하는 것입니다.

1. 범위를 구분하세요

문제가 클라이언트 특화인지 여부를 검증함으로써 시작하세요. 동일한 URL을 테스트하세요:

  • 다른 브라우저에서
  • 같은 네트워크에서 다른 기기에서
  • 같은 기기에서 다른 네트워크에서 (예: 핫스팟)

문제가 특정 브라우저나 장치에 국한된 경우, 이는 일반적으로 지역 신뢰 또는 구성 문제를 나타냅니다. 네트워크 밖에서 작동하는 경우 문제는 TLS 검사 또는 정책 강제 적용과 관련이 있을 가능성이 높습니다.

2. TLS 검토 / 인증서 발급자 확인

브라우저에서:

  • 개발자 도구 열기 → 보안 탭 또는 잠금 아이콘 클릭
  • 인증서 체인을 검사하세요

발급자를 확인하세요:

  • 프록시/엔터프라이즈 CA (예: Cato) → TLS 검사가 활성 중입니다
  • 공용 CA (예: DigiCert, Let’s Encrypt) → 직접 TLS 세션

3. 클라이언트에서 인증서 신뢰 검증

  • 엔드포인트에 Cato 루트 인증서가 올바르게 설치되어 있는지 확인하세요.

  • 루트 인증서가 OS 신뢰 저장소에 있는지 검증하세요:
    • Windows에서 컴퓨터 인증서 관리자를 열고 certlm.msc를 입력하여 신뢰할 수 있는 루트 인증 기관 아래 루트 인증서를 검색하세요
    • Mac에서 키체인 접근을 열고 시스템 키체인 아래 루트 인증서를 검색하세요
  • 시스템 시간과 날짜를 확인하세요
  • Cato 루트 인증서가 엔드포인트에 없으면 다운로드하여 장치에 Cato 인증서를 설치에서 설명한 대로 설치하세요

  • 누락되거나 잘못된 신뢰 구성은 즉각적인 TLS 실패를 일으킬 것입니다.

4. 클라이언트에서 TLS 핸드셰이크 테스트

클라이언트 측 도구를 사용하여 TLS 연결을 시뮬레이션하고 정확히 어디에서 그리고 왜 핸드셰이크가 실패하는지를 식별하세요. 이러한 도구는 종종 일반 브라우저 메시지 뒤에 숨겨진 오류를 노출합니다.

영향을 받은 엔드포인트에서 다음 또는 유사한 명령을 실행하세요:

curl.exe -v https://

OpenSSL을 사용할 수 있다면:

openssl s_client -connect :443 -servername

예상 출력 (성공)

* SSL 연결: TLS1.2 / TLS1.3
* 서버 인증서:
*  subject: CN=www.google.com
*  issuer: CN=GTS CA 1C3
> GET / HTTP/1.1
< HTTP/1.1 200 OK

먼저 이슈가 클라이언트, 대상 서버, 또는 TLS 검사 구성 자체와 관련이 있는지 여부를 결정하는 것이 중요합니다. 

일반 문제 해결

참고:
아래 나열된 문제는 TLS 검토 배포에서 관찰된 일반적인 시나리오를 나타냅니다. 이러한 많은 오류는 일반적이며 특정 환경에 직접 적용되거나 적용되지 않을 수도 있습니다.
설명된 증상이나 해결책이 케이스와 맞지 않으면 진단 데이터를 수집하는 것이 좋습니다 (예: SSS, HAR, 그리고 PCAP) 클라이언트 머신에서 지원 티켓을 생성하여 더 깊은 분석을 진행하세요.

실패하는 애플리케이션 문제 해결 

문제: 특정 애플리케이션이 안전한 연결을 설정하지 못하거나 TLS 검사가 활성화된 후 작동을 멈춥니다.

행동 기대:
엄격한 보안 제어가 있는 애플리케이션 (예: 뱅킹 앱, 엔드포인트 보안 툴)은 즉각적으로 연결에 실패하거나, 조용히 크래시하거나, 반복적으로 다시 연결을 시도할 수 있습니다. TLS 검사는 중간자 (MITM) 인증서를 도입하여 이러한 애플리케이션이 감지하고 거부하도록 설계된 것입니다.

해결책:
정책 상단에 있는 규칙을 사용하여 단일 사용자 또는 소스 IP에 대해 TLS 검사를 우회하여 검증하세요. 애플리케이션이 우회 시 작동한다면, 대상 제외 (도메인/FQDN 기반)를 만들어 넓은 규칙을 피하세요. 추가적으로, Cato의 TLS 검사 구성 마법사를 사용하여 최소한의 설정으로 민감한 도메인을 우회할 수 있습니다. 

애플리케이션이나 서버가 인증서 고정 또는 엄격한 TLS 요구사항을 적용하는 경우, TLS 검사를 적용할 수 없습니다. 그러한 경우에는 트래픽을 영구적으로 우회하는 것이 올바른 접근 방식입니다.

예시:
금융 앱이 로그인 실패 후 TLS 검사를 우회한 직후 작동되면, 불일치가 확인되고 앱 도메인을 우회 목록에 추가하세요. 

브라우저 인증서 경고 문제 해결

문제:사용자는 인증서 경고를 보거나 TLS 검사를 활성화한 후 애플리케이션이 실패합니다.

행동 기대:
사용자는 브라우저 경고 (예: “연결되지 않음”)를 경험하거나 완전한 연결 실패를 경험할 수 있습니다. 행동은 Cato 인증서가 올바르게 설치되었는지 여부에 따라 장치 간에 다를 수 있습니다.

해결책:
Cato TLS 검사 루트 인증서가 모든 엔드포인트에 설치되고 신뢰받고 있는지 확인하세요. GPO/MDM을 사용하여 배포하고 클라이언트의 전체 인증서 체인을 확인하세요.

개인/내부 인증서를 사용하는 경우, 이들이 올바르게 신뢰받았는지 확인하거나 TLS 검사 인증서 처리 절차를 따르세요.

행동이 일관성이 없는 경우, TLS 검사를 단일 사용자 또는 장치에 대해 우회하여 인증서 관련 영향을 검증하세요.

개인 인증서를 조직 내에서 사용하는 경우 개인 인증서를 사용하여 TLS 검사로 트래픽 보호를 참조하세요. 

호스트명 불일치 문제 해결

문제:사용자는 특정 웹사이트에 접근할 때 호스트명 불일치 때문에 인증서 오류나 차단된 연결을 경험합니다, 특히 TLS 검사가 활성화되었을 때.

행동 기대:
서버가 요청한 호스트명과 일치하지 않는 일반 이름(CN) 또는 SAN을 가진 인증서를 제공할 때, 연결은 유효하지 않다고 간주됩니다.

TLS 검사가 없는 경우 브라우저는 즉시 이 불일치를 감지하고 인증서 경고를 표시합니다.

TLS 검사가 활성화되면 브라우저는 원본 서버 대신 Cato PoP와 TLS 세션을 설정합니다. PoP는 Cato 루트 CA를 사용하여 인증서를 다시 서명하여 클라이언트에게 유효하게 보이도록 만듭니다. 결과적으로 브라우저에 불일치를 표시하는 것이 없습니다, 백엔드에서 문제가 여전히 존재하더라도.

해결책:
특정 사용자 또는 소스 IP에 대해 TLS 검사를 우회하여 행동을 검증하세요. 브라우저가 호스트명 불일치 오류를 설정한다면, 이는 문제가 대상 서버에서 발생한다는 것을 확인합니다.

불일치가 서버의 인증서 구성으로 인한 것이므로, TLS 검사는 이를 수정할 수 없습니다. 적절한 조치는 다음 중 하나입니다:

  • 특정 도메인에 대해 TLS 검사를 우회하여 접근을 허용하거나,
  • 정책에 기반하여 트래픽을 차단하십시오, 불일치가 보안 위험으로 간주될 경우

넓은 우회 규칙을 피하고 필요한 경우 대상 도메인/FQDN 제외를 사용하세요.

예시:
https://www.testingmcafeesites.com/에 접근할 때, 서버는 platformsplat1.mcafee.com에 대한 인증서를 제공합니다.

TLS 검사가 없는 경우 브라우저는 즉시 호스트명 불일치를 경고합니다.

TLS 검사가 활성화된 경우, 브라우저는 www.testingmcafeesites.com에 대해 Cato 루트 CA가 발급한 유효한 인증서를 확인하여 오류가 표시되지 않습니다. 그러나 Cato PoP는 백그라운드에서 불일치를 감지하고 설정된 정책(차단 또는 경고)을 시행합니다.

웹사이트 또는 애플리케이션 로딩 문제 해결

문제:웹사이트가 로드되지 않거나, 부분적으로 렌더링되거나, TLS 검사가 활성화되었을 때 의외로 작동할 수 있습니다.

행동 기대:

  • 페이지가 멈춤, 무한정 로드되거나 부분적으로 렌더링됨
  • 로그인/인증 흐름이 실패하거나 반복됨
  • TLS 복호화/다시 암호화 과부하로 인해 일부 사이트가 느리게 나타날 수 있습니다
  • 행동이 일관성이 없을 수 있습니다 (예: 한 네트워크에서 작동하고, Cato에서는 실패함)

이는 엄격한 보안 제어 또는 복잡한 TLS 종속성을 사용하는 현대 웹 앱에서 일반적으로 관찰됩니다.

해결방안:
TLS 검사를 우회하여 특정 사용자 또는 소스 IP에 대해 검증합니다. 사이트가 우회하여 작동하는 경우 대상 도메인/FQDN 제외를 생성하십시오.

광범위한 우회 규칙을 피하고 필요에 따라 도메인만 제외하십시오.

애플리케이션이 엄격한 보안 메커니즘(e.g., 상수 인증서 또는 고급 TLS 처리를 이용)이 필요하다면 검사가 지원되지 않을 수 있으며, 우회가 올바른 방법입니다.

시나리오 – 현대 웹 애플리케이션 (SaaS):
일부 SaaS 플랫폼(e.g., 다중 백엔드 도메인/CDN이 포함된 앱)은 부분적으로 로드될 수 있습니다(UI 작동, API 실패). 이러한 경우 HAR/DevTools를 통해 모든 필요한 도메인을 식별하고 우회 규칙에 대해 전체 범위를 보장하십시오.

Cato 인증서 검증 오류 문제 해결

문제: 브라우징 또는 애플리케이션 사용 중 Cato TLS 관련 오류가 나타납니다.

행동적 기대

사용자들이 다음과 같은 일반적인 오류를 경험할 수 있습니다. 

  • "보안 연결 실패"
  • "인증서가 신뢰되지 않음"
  • 예상치 않은 연결 재설정 또는 연결 끊김

이러한 오류는 일반적으로 구체적이지 않으며 문제가 클라이언트, 서버 또는 TLS 검사 과정에서 발생했는지를 명확히 나타내지 않습니다.

해결방안:
특정 사용자 또는 소스 IP에 대해 TLS 검사를 일시적으로 우회함으로써 행동을 검증하십시오.

  • 문제가 우회할 때 해결된다면 검사 동안 인증서 검증 실패를 확인할 수 있습니다.
  • 중간 또는 발행 CA가 인정되지 않는 경우, 이는 Cato의 신뢰된 인증서 번들에 포함되지 않았기 때문일 수 있습니다.

임시 해결책으로 영향을 받은 도메인/애플리케이션에 대해 TLS 검사를 우회할 것을 권장합니다 지원 케이스를 열면서.

Cato는 업계 표준에 따라 신뢰된 인증서 번들을 계속 업데이트합니다. 인증서가 유효하고 널리 신뢰되면 향후 업데이트에 추가될 가능성이 높습니다.

영구적 해결은 다음에 집중해야 합니다.

  • 서버가 완전하고 유효한 인증서 체인을 제공하도록 보장합니다.
  • 잘 알려진 신뢰받는 CA가 발급한 인증서를 사용합니다.

서버가 잘못된 또는 불완전한 인증서 체인을 제공한다면 TLS 검사는 연결을 올바르게 차단할 것입니다. 해결은 서버 측에서 이루어져야 하며, 필요시 TLS 검사를 우회하십시오.

새롭게 신뢰받거나 최근에 게시된 도메인

인터넷에서 새롭게 게시되거나 최근 업데이트되거나 재분류된 도메인은 모든 평판 엔진, 인증 기관 또는 신뢰 저장소에서 일관되게 인식되지 않을 수 있습니다.

이는 트래픽이 차단되거나 플래그가 표시되는 경우를 초래할 수 있으며 — TLS 실패 때문만이 아니라 — 인터넷 방화벽 정책에 따른 보안 시행 또는 불완전한 인증서 신뢰의 결과로 발생할 수 있습니다.

행동적 기대
이와 같은 도메인은 다음과 같습니다.

  • 잘못 분류되거나 보안 엔진에 걸쳐 불일치하게 분류되거나
  • 글로벌하게 전파되거나 신뢰받지 못하는 인증서를 제공합니다.
  • 트러스트 체인의 불완전으로 인해 검사 중 TLS 오류를 발생시킵니다.
  • 실제 연결 문제보다는 정책에 기반해 차단됩니다.

도메인이 활성화되거나 변경된 직후에 이러한 행동이 일반적입니다.

해결방안:

  • 직접 엔드포인트에서 인증서를 검증하여 정당성을 확인하십시오
  • 도메인이 안전하다고 확인되면
    • 정책 요구 사항에 따라 허용된 카테고리로 재분류하거나
    • 대상 허용/우회 규칙을 생성하십시오(광범위한 제외는 피하십시오).
  • 가능한 경우 우회 규칙을 임시로 취급하십시오.
  • 어느 정도 시간이 지난 후 도메인이 글로벌하게 평판과 인증서 신뢰를 확립한 후 다시 평가하세요.

주요 노트:
도메인이 정당하더라도 인증서 전파가 불완전할 경우 TLS 관련 오류를 발생시킬 수 있습니다. 이러한 경우 행동이 예상될 수 있으며 잘못된 설정이라고 가정하기보다는 통제된 정책 조정을 통해 처리해야 합니다.

시나리오 – 불완전한 인증서 체인:
사이트는 브라우저에서 직접 (캐시된 중간 노드 덕분에) 작동할 수도 있지만 TLS 검사에서는 실패할 수 있습니다. 이는 서버가 전체 인증서 체인을 제공하지 않음을 나타냅니다. 해결방안은 서버 구성을 수정하거나 도메인을 우회하는 것입니다.

지원되지 않는 프로토콜 및 레거시 시스템

문제:
오래된 TLS 버전이나 약한 암호화 스위트를 사용하는 애플리케이션 또는 시스템의 연결이 실패하며 TLS 검사에서는 지원되지 않습니다.

행동적 기대:
TLS 핸드셰이크 중 실패가 발생하며 브라우저 또는 클라이언트에서 직접 보일 수 있습니다.

일반적인 브라우저 오류는 다음을 포함합니다.

  • ERR_SSL_PROTOCOL_ERROR
  • ERR_EMPTY_RESPONSE
  • ERR_SSL_VERSION_OR_CIPHER_MISMATCH
  • ERR_CONNECTION_CLOSED
  • 400 Bad Request
필수 SSL 인증서가 전송되지 않았습니다.

일부 경우:

  • 페이지가 완전히 로드되지 않을 수 있습니다.
  • 연결이 즉시 재설정될 수 있습니다.
  • 두꺼운 클라이언트 또는 레거시 앱이 조용히 실패하거나 일반적인 연결 오류를 표시할 수 있습니다.

이는 클라이언트 또는 서버가 MITM으로 작동하는 Cato PoP과 호환 가능한 TLS 버전 또는 암호화 스위트를 협상할 수 없다는 것을 의미합니다.

이벤트에서는 TLS 오류 설명 필드에 구체적인 정보가 제공됩니다. 

오류에 대한 추가 정보는 TLS 오류 이해하기를 방문하십시오 

해결방안:

  • 특정 사용자 또는 소스 IP에 대해 TLS 검사를 일시적으로 우회하여 행동을 검증합니다.
  • 애플리케이션이 우회할 때 작동하는 경우 검사 중 TLS 협상 불일치를 확인할 수 있습니다.

다음으로 외부 도구를 사용하여 TLS 기능을 검증하십시오 – https://www.ssllabs.com/ssltest/

TLS 검사 정책과의 결과를 비교하세요:

  • 허용된 최소 TLS 버전
  • 암호 스위트 시행 수준

확인된 경우:

  • 애플리케이션 또는 서버를 최신 TLS 버전 및 강력한 암호 스위트를 지원하도록 업데이트 또는 업그레이드합니다.
  • 업그레이드가 불가능한 경우 영향을 받는 애플리케이션 또는 도메인을 위해 대상 TLS 검사 우회를 구성합니다.

참고:
기본적으로 Cato는 광범위한 TLS 버전 및 암호 스위트를 허용합니다. 그러나 관리자는 TLS 검사 정책에서 더 엄격한 통제를 시행할 수 있으며(e.g., 최소 TLS 버전 또는 암호 강도), 이는 레거시 애플리케이션이 실패하게 만들 수 있습니다. 자세한 내용은 여기를 읽으십시오.

 

시나리오 – 레거시 내부 애플리케이션:
내부 또는 제3자 레거시 애플리케이션은 TLS 검사가 활성화된 상태로 Cato를 통해 라우팅할 때 실패할 수 있으며, 우회할 때 작동합니다. 이는 일반적으로 사용이 중단된 TLS 버전에 대한 종속성을 나타내며 애플리케이션 업그레이드 또는 영구적인 우회가 필요합니다.

OS 구체적 TLS 문제 문제 해결(예상 제한 사항)

문제: 연결 문제, 불일치한 행동, 특정 운영 체제 및 장치 유형(e.g., 모바일, BYOD, Linux)에서 TLS 검사 가시성 부족 또는 없음.

행동적 기대

행동은 운영 체제 및 애플리케이션 설계에 따라 크게 다릅니다.

Android 및 Linux 장치에 대해서는 인증서 신뢰 제한 및 애플리케이션 행동의 이유로 기본적으로 TLS 검사가 우회됩니다. 그러나 최신 구성(고급 설정을 통해 CMA에서) 관리자가 이 플랫폼에서 TLS 검사를 시행할 수 있도록 허용하며 인증서 신뢰가 적절히 구축될 수 있는 경우입니다.

iOS 장치에 대해서는 TLS 검사가 지원되지만 일부 애플리케이션(e.g., Instagram, Facebook 같은 소셜 미디어 플랫폼 및 유사 앱)이 기본적으로 우회됩니다 이는 인증서 고정 및 알려진 비호환성 때문입니다. 엄격한 검증을 시행하는 기타 애플리케이션은 실패할 수 있으며 수동 우회 구성이 필요합니다.

일반적으로:

  • Cato 인증서가 설치되면 브라우저가 예상대로 작동할 수 있습니다.
  • 네이티브/모바일 애플리케이션은 인증서 고정 또는 제한된 신뢰 저장소에 의해 즉시 실패할 수 있습니다.
  • 애플리케이션마다 행동이 다를 수 있으며 동일한 장치에서도 다를 수 있습니다.

해결방안:

이러한 행동은 일반적으로 예상되고 플랫폼 주도며, 잘못된 구성의 징후가 아닙니다.

  • TLS 검사를 주로 인증서 배포가 통제되는 관리 장치에 적용하십시오.
  • 시스템 수준에서 Cato 인증서를 설치할 수 있도록 MDM 솔루션을 사용하세요(지원되는 경우).
  • 잘 알려진 애플리케이션과 플랫폼에 대한 기본 우회 규칙을 인식하세요.
  • 엄격한 검증 또는 인증서 고정으로 인해 실패하는 애플리케이션에 대해 대상 TLS 검사 우회를 구성합니다.
  • Android 또는 Linux와 같은 플랫폼에서 TLS 검사 시행 시 광범위한 배포 전에 호환성을 신중히 검증하세요.

시나리오 – 모바일 애플리케이션 실패:
모바일 앱(e.g., 은행 또는 보안 앱)이 브라우저가 작동하는 동안 Cato를 통해 연결에 실패합니다. 앱은 인증서 고정을 시행하며 Cato 인증서를 신뢰하지 않습니다. 이는 예상된 것이며 — 올바른 행동은 그 애플리케이션 또는 서비스에 대해 TLS 검사를 우회하는 것입니다.

Cato 지원에 케이스 제기

애플리케이션에 대해 TLS 검사가 규정 준수 또는 규제 이유로 필수이거나 TLS 차단이 예정된 것보다 뜻밖이라면 위의 문제 해결 단계를 포함한 지원 티켓을 제출하십시오. 티켓에 다음 정보를 포함하십시오.

  • 경험한 문제에 대한 세부 정보 및 사용자에게 미치는 전반적 영향. 문제를 경험하는 사용자의 타임스탬프/시간대. 
  • 관련 이벤트 및 방화벽/TLS 규칙 구성.
  • 문제를 재현하고 지원 자가 서비스를 실행하세요. 툴에 의해 생성된 티켓 번호를 포함하십시오.

 

도움이 되었습니까?

0명 중 0명이 도움이 되었다고 했습니다.

댓글 0개