SSL/TLS 인증서와 프록시 환경의 기업 네트워크 보안의 이해

1. SSL/TLS 인증서의 기본 원리

1.1 인증서의 개념과 역할

SSL/TLS 인증서는 웹사이트나 서버의 신원을 디지털 방식으로 증명하는 전자 문서입니다.
인증서는 다음과 같은 핵심 역할을 수행합니다.

• 신원 증명: 웹사이트가 실제로 주장하는 그 웹사이트임을 증명
• 암호화 키 제공: 안전한 통신을 위한 공개키를 제공
• 데이터 무결성 보장: 통신 내용이 변조되지 않았음을 보장

인증서에는 다음과 같은 중요 정보가 포함됩니다.

• 도메인 이름 (예: imtsoft.me)
• 공개 키
• 발급자 정보 (인증 기관)
• 유효 기간
• 디지털 서명

1.2 암호화의 기초: 대칭 및 비대칭 암호화

HTTPS 통신은 두 가지 암호화 방식을 조합하여 사용합니다.

비대칭 암호화 (공개키 암호화)

• 공개키와 개인키 쌍을 사용
• 공개키로 암호화한 데이터는 개인키로만 복호화 가능
• 주로 초기 연결 설정과 키 교환에 사용
• 연산이 복잡하여 속도가 느림

대칭 암호화

• 동일한 키로 암호화와 복호화를 수행
• 빠른 처리 속도가 장점
• 실제 데이터 전송에 사용
• 안전한 키 교환이 중요한 과제

1.3 인증서 체인과 신뢰 모델

SSL/TLS는 계층적 신뢰 구조를 기반으로 합니다.

루트 CA → 중간 CA → 최종 서버 인증서

• 루트 CA(Certificate Authority): 최상위 신뢰 기관으로, 자체 서명된 인증서를 가짐
• 중간 CA: 루트 CA에서 발급받은 인증서로 다른 인증서에 서명할 권한을 가짐
• 최종 서버 인증서: 웹사이트나 서버에 발급된 인증서

모든 운영체제와 브라우저는 신뢰할 수 있는 루트 CA 목록을 내장하고 있으며, 이를 통해 인증서 체인을 검증합니다.

2. SSL/TLS 통신 과정

2.1 TLS 핸드셰이크 과정

HTTPS 연결이 설정될 때 클라이언트와 서버는 다음과 같은 TLS 핸드셰이크 과정을 거칩니다.

1. 클라이언트 헬로: 클라이언트가 지원하는 암호화 방식과 난수값 전송
2. 서버 헬로: 서버가 선택한 암호화 방식과 자신의 인증서, 난수값 전송
3. 인증서 검증: 클라이언트가 서버 인증서를 검증
4. 키 교환: 클라이언트가 프리마스터 시크릿(pre-master secret)을 생성하여 서버의 공개키로 암호화해 전송
5. 세션 키 생성: 양측이 교환한 정보를 바탕으로 동일한 세션 키 생성
6. 암호화 통신 시작: 생성된 세션 키를 사용하여 암호화된 데이터 교환

2.2 인증서 검증 과정

클라이언트가 서버 인증서를 검증하는 과정은 다음과 같습니다.

1. 인증서의 디지털 서명을 발급자(CA)의 공개키로 확인
2. 발급자 인증서의 서명을 그 상위 발급자의 공개키로 확인
3. 루트 CA까지 이 과정을 반복하여 신뢰 체인 구축
4. 루트 CA가 신뢰할 수 있는지 확인 (클라이언트의 신뢰 저장소에 있는지)
5. 인증서의 유효 기간, 도메인 일치 여부, 해지 상태 등 추가 검증

이 과정에서 하나라도 실패하면 인증서 오류가 발생합니다.

3. 기업 네트워크의 SSL 중간자 검사

3.1 SSL 중간자 검사의 필요성

기업은 다음과 같은 이유로 암호화된 트래픽에 대한 검사가 필요합니다.

1. 보안 위협 탐지: 암호화된 트래픽에 숨겨진 악성코드 감지
2. 데이터 유출 방지: 민감한 정보가 외부로 유출되는 것을 방지
3. 규정 준수: 다양한 산업 규제 요구사항 충족
4. 사용자 활동 모니터링: 직원들의 인터넷 사용 모니터링

3.2 SSL 중간자 검사의 기술적 작동 원리

SSL 중간자 검사는 다음과 같은 방식으로 작동합니다.

클라이언트 <--암호화 터널 1--> 프록시 <--암호화 터널 2--> 웹사이트

1. 클라이언트가 웹사이트에 HTTPS 연결 시도
2. 기업 프록시가 이 요청을 가로챔
3. 프록시는 웹사이트에 별도로 연결하여 원본 인증서 획득
4. 프록시는 새로운 인증서를 생성
   • 도메인: 원본 웹사이트와 동일
   • 발급자: 기업 CA
   • 서명: 기업 CA의 개인키로 서명
5. 프록시는 이 새 인증서를 클라이언트에게 제공
6. 이후 두 개의 별도 암호화 채널 형성
   • 클라이언트-프록시 간 통신
   • 프록시-웹사이트 간 통신

프록시는 모든 데이터를 복호화, 검사한 후 다시 암호화하여 전송합니다.

3.3 인증서 대체 메커니즘

기업 프록시가 인증서를 대체하는 방식은 다음과 같습니다.

1. 실시간 인증서 생성: 접속하는 각 도메인마다 즉석에서 인증서 생성
2. 인증서 캐싱: 자주 방문하는 도메인의 인증서를 생성하여 재사용
3. 와일드카드 인증서: *.google.com과 같은 와일드카드 인증서를 미리 생성
4. 인증서 풀 사전 생성: 자주 사용되는 도메인의 인증서를 미리 생성

대규모 기업 환경에서는 성능을 위해 이러한 방식을 조합하여 사용합니다.

4. 안드로이드 앱의 인증서 신뢰 메커니즘

4.1 안드로이드 인증서 저장소

안드로이드는 세 가지 인증서 저장소를 가집니다.

1. 시스템 저장소: Android OS에 내장된 신뢰할 수 있는 CA 목록
2. 사용자 저장소: 사용자가 직접 설치한 CA 인증서
3. 앱 저장소: 앱 자체에 포함된 인증서

Android 7.0(API 24) 이후부터는 기본적으로 사용자 설치 인증서를 신뢰하지 않습니다.
이는 보안을 강화하기 위한 조치이지만, 기업 환경에서는 문제가 될 수 있습니다.

4.2 앱의 SSL 연결 처리

안드로이드 앱이 SSL 연결을 처리하는 방식은 사용하는 네트워킹 라이브러리에 따라 다릅니다.

1. 기본 HttpsURLConnection: 시스템 인증서 저장소 사용
2. OkHttp, Retrofit: 기본적으로 시스템 인증서 저장소 사용, 커스터마이징 가능
3. Ktor: 기본적으로 시스템 인증서 저장소 사용, 엔진 설정으로 커스터마이징 가능

앱은 다음과 같은 SSL 검증 과정을 수행합니다.

• 서버 인증서의 유효성 검증
• 인증서 체인 구축 및 검증
• 호스트명 일치 확인
• 신뢰 앵커(Trust Anchor) 확인

4.3 "Trust anchor for certification path not found" 오류

이 오류는 인증서 체인의 신뢰 앵커를 찾을 수 없을 때 발생합니다. 다음과 같은 상황에서 나타날 수 있습니다.

1. 루트 CA가 신뢰 저장소에 없음
2. 중간 CA 인증서가 누락되어 체인을 완성할 수 없음
3. 서버가 자체 서명 인증서를 사용함

기업 네트워크 환경에서는 SSL 중간자 검사로 인해 기업 CA가 신뢰 저장소에 없을 경우 이 오류가 발생합니다.

5. Android 네트워크 보안 설정

5.1 네트워크 보안 설정(Network Security Configuration)

Android 7.0부터 도입된 네트워크 보안 설정은 앱의 네트워크 보안 정책을 XML로 구성할 수 있게 해줍니다.

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config>
        <trust-anchors>
            <certificates src="system" />
            <certificates src="user" />  <!-- 사용자 추가 인증서 신뢰 -->
        </trust-anchors>
    </base-config>
</network-security-config>

이 설정은 AndroidManifest.xml에 다음과 같이 적용됩니다:

<application
    android:networkSecurityConfig="@xml/network_security_config"
    ... >

5.2 사용자 인증서 신뢰 설정의 중요성

기업 환경에서 앱을 사용할 때는 기업 CA를 신뢰하도록 설정하는 것이 중요합니다.

1. 기업 네트워크 호환성: SSL 중간자 검사를 사용하는 기업 네트워크에서 작동
2. 일관된 사용자 경험: 브라우저와 앱이 동일한 네트워크에서 일관되게 작동
3. 개발 및 테스트 환경: 개발 중 사용하는 자체 서명 인증서 지원

그러나 보안과 사용성 사이의 균형이 중요합니다. 모든 사용자 인증서를 무조건 신뢰하는 것은 보안 위험을 증가시킬 수 있습니다.

6. 데이터 유출 방지와 SSL 중간자 검사의 관계

6.1 암호화된 트래픽에서의 데이터 유출 위험

HTTPS 트래픽이 암호화되어 있기 때문에, SSL 중간자 검사 없이는 다음과 같은 데이터 유출 위험을 탐지하기 어렵습니다.

• 암호화된 이메일 첨부파일을 통한 기밀 정보 유출
• HTTPS 웹사이트를 통한 데이터 업로드
• 클라우드 스토리지 서비스로의 데이터 전송
• 암호화된 메신저를 통한 정보 공유

6.2 SSL 중간자 검사의 데이터 유출 방지 메커니즘

SSL 중간자 검사는 다음과 같은 방식으로 데이터 유출을 방지합니다.

1. 콘텐츠 필터링: 복호화된 트래픽에서 민감한 정보를 식별
2. 패턴 매칭: 정규표현식으로 주민등록번호, 신용카드 번호 등 패턴 탐지
3. 문맥 인식 분석: 단순 패턴이 아닌 문맥을 고려한 분석으로 유출 시도 탐지
4. DLP 통합: 데이터 유출 방지(DLP) 시스템과 연동하여 정책 기반 차단

6.3 SSL 검사 없는 제한적 데이터 유출 방지

SSL 중간자 검사 없이 가능한 제한적 방법.

1. 엔드포인트 DLP: 데이터가 암호화되기 전에 단말에서 검사
2. 네트워크 메타데이터 분석: 트래픽 패턴, 볼륨 등 분석
3. DNS 및 IP 기반 필터링: 위험 사이트 접근 차단
4. 접근 제어 정책: 민감 데이터에 대한 접근 자체를 제한

그러나 이러한 방법들은 암호화된 콘텐츠를 직접 분석할 수 없어 효과가 제한적입니다.

결론

SSL/TLS 인증서와 기업 네트워크 보안은 복잡하게 상호작용합니다.
한편으로는 HTTPS를 통한 암호화로 데이터를 보호하면서도, 다른 한편으로는 기업이 보안 위협으로부터 내부 네트워크를 보호하기 위해 이 암호화를 일시적으로 해제해야 하는 역설적인 상황이 존재합니다.

안드로이드 앱 개발자는 이러한 기업 환경을 고려하여 네트워크 보안 설정을 구성해야 합니다.
특히 기업용 앱을 개발할 때는 사용자 인증서를 신뢰하도록 설정하는 것이 중요합니다.
이를 통해 "Trust anchor for certification path not found"와 같은 오류를 방지하고 다양한 네트워크 환경에서 일관된 사용자 경험을 제공할 수 있습니다.

SSL/TLS와 인증서의 기본 원리를 이해하면 네트워크 보안 문제를 더 효과적으로 진단하고 해결할 수 있습니다. 또한 기업의 보안 요구사항과 사용자 경험 사이의 균형을 맞추는 데도 도움이 됩니다.

 

아래는 위 이론들과 관련하여 안드로이드 솔루션 개발 중 직접 경험한 트러블 슈팅 포스팅 입니다.

 

2025.03.24 - [개발 경험 기록/안드로이드] - 안드로이드 앱의 SSL 인증서 오류 트러블슈팅: "Trust anchor for certification path not found"

안드로이드 앱의 SSL 인증서 오류 트러블슈팅: "Trust anchor for certification path not found"