호스트 헤더 기반 가상 호스팅(아래 주요 개념에 정의되어 있음)은 효율성이 뛰어나고 널리 사용되기 때문에 암호화되지 않은 HTTP의 IP 주소 기반 필터링이 제대로 작동하지 않지만, 호스트 헤더 기반 HTTPS 사이트는 드물기 때문에 HTTPS의 IP 필터링이 효율적으로 작동합니다. 그러나 이와 같은 신뢰는 HTTPS 서버 운영자의 청렴성에 따라 달라지며, SSL이 사기 행위에 사용되지 않는 것으로 가정합니다.

대부분의 경우 SSL은 합법적으로 적용되고 온라인 쇼핑/뱅킹 또는 개인 정보/중요 정보를 교환하는 세션 같이 중요한 통신을 보호하는 데 사용됩니다. 그러나 SSL의 비용과 복잡성이 갈수록 낮아짐에 따라 기본적으로 정보를 보호하는 것이 아니라 은폐하거나 모호화하기 위해 설계된 의심스러운 SSL 적용 사례도 크게 증가했습니다.

그중에서도 갈수록 흔하게 나타나는 위장 사례는 SSL로 암호화된 웹 기반 프록시 서버를 이용하여 검색 세부 정보를 숨기고 콘텐츠 필터를 바이패스하는 것입니다. 이 같은 종류의 잘 알려진 HTTPS 프록시 서비스는 해당 IP 주소를 기준으로 손쉽게 차단할 수 있지만, 간단한 웹 검색을 통해 즉시 사용 가능한 수많은 개인 호스팅 프록시 서버를 모두 차단하기란 사실상 불가능합니다. 즉 이러한 서비스가 갈수록 많아지는 데 문제가 있는 것이 아니라 해당 특징을 예측할 수 없다는 데 문제가 있습니다. 이러한 서비스는 보통 동적으로 주소가 지정되는 DSL 및 케이블 모뎀 연결을 사용하여 홈 네트워크에서 호스팅되므로 대상이 끊임없이 이동됩니다. 알려지지 않은 SSL 대상을 차단하려면 모든 SSL 트래픽을 차단해야 하는데, 실제로 이와 같이 차단하기란 어렵습니다.

SSL 컨트롤은 보안 관리자가 SSL 세션 설정을 분석하여 정책 기반 컨트롤을 적용할 수 있도록 함으로써 이 문제를 해결하는 다양한 방법을 제공합니다. 현재 구현에서는 SSL 응용 프로그램 데이터의 암호가 해독되지 않지만 게이트웨이 기반을 식별하고 의심스러운 SSL 트래픽을 거부할 수는 있습니다.

SSL 컨트롤의 주요 기능

SSL 컨트롤의 주요 개념

• SSL- Secure Sockets Layer의 약어로, 1995년에 Netscape에서 도입한 네트워크 보안 메커니즘입니다. SSL은 서로 통신하는 두 응용 프로그램(클라이언트와 서버) 간에 개인 정보 보호 기능을 제공하고 서버와 클라이언트(선택 사항)를 인증하기 위해 설계되었습니다. 가장 널리 알려진 SSL 응용 사례는 단순한 http://가 아닌 https://로 시작되는 URL로 지정된 HTTPS입니다. HTTPS는 인터넷의 웹 트래픽을 암호화하는 표준 방법으로 알려져 있습니다. SSL HTTP 전송에서는 보통 TCP 포트 443을 사용하고 일반 HTTP 전송에서는 TCP 포트 80을 사용합니다. 이처럼 가장 잘 알려진 SSL 적용 방식은 HTTPS이지만, SSL은 HTTP를 보호하는 데에만 사용되는 것이 아니라 SMTP, POP3, IMAP, LDAP 등의 기타 TCP 프로토콜을 보호하는 데에도 사용할 수 있습니다. 자세한 내용은 http://wp.netscape.com/eng/security/SSL_2.html을 참조하십시오. SSL 세션은 다음과 같이 설정됩니다.

• SSLv2 – 최초의 SSL 버전으로 현재도 널리 사용되고 있습니다. SSLv2는 몇 가지 취약점, 제한 및 이론적 단점(SSLv3 항목에서 비교 설명함)이 있는 것으로 확인되어 보안을 중요하게 고려하는 사용자들에게는 좋지 않은 평가를 받았습니다.

• SSLv3 – SSLv3은 이전 버전인 SSLv2와 계속해서 호환되도록 설계되었으며 다음과 같은 기능도 향상되었습니다.

– Diffie-Hellman 등의 대체 키 교환 방법

– 키 교환 및 대량 암호화에 필요한 하드웨어 토큰 지원

– SHA, DSS 및 Fortezza 지원

– 대역 외 데이터 전송

– TLS – Transport Layer Security(버전 1.0)의 약어로 SSLv3.1이라고도 합니다. SSLv3과 매우 비슷하지만 SSLv3에 비해 다음과 같은 기능이 향상되었습니다.

• MAC – 메시지 인증 코드의 약어로, MD5 또는 SHA1 같은 알고리즘을 데이터에 적용하여 계산됩니다. MAC는 매우 계산하기 쉬운 메시지 다이제스트 또는 단방향 해시 코드지만 사실상 되돌릴 수는 없습니다. 즉 MAC만 사용하면 이론상 다이제스트의 기준이 되는 메시지를 확인하기가 불가능합니다. 마찬가지로 MAC가 동일한 서로 다른 두 메시지도 찾기가 어렵습니다. 지정된 데이터 부분에 대해 받는 사람의 계산이 보낸 사람의 MAC 계산과 일치하면, 받는 사람이 전송 중에 데이터가 변경되지 않았음을 확인할 수 있습니다.

• 클라이언트 Hello – TCP 세션이 설정된 후 클라이언트가 서버로 보내는 첫 번째 메시지입니다. 이 메시지는 SSL 세션을 시작하며, 다음과 같은 요소로 구성되어 있습니다.

– 버전 – 클라이언트가 통신에 사용하려는 SSL의 버전입니다. 일반적으로 클라이언트가 지원하는 최신 SSL 버전입니다.

– 임의 – 28바이트 임의 구조와 결합된 32비트 타임스탬프입니다.

– 세션 ID – 세션 ID 데이터가 없는 경우 비어 있거나(최종적으로는 새 세션 요청) 이전에 발급된 세션 ID를 참조할 수 있습니다.

– 암호화 제품군 – 클라이언트에서 지원하는 암호화 알고리즘의 목록(우선 순위 순서)입니다.

– 압축 방법 – 클라이언트에서 지원하는 압축 방법의 목록(보통 null)입니다.

• 서버 Hello – 클라이언트 Hello에 대한 SSL 서버의 응답입니다. SSL 컨트롤은 이 부분의 SSL 교환 작업을 검사합니다. 서버 Hello는 세션에서 협상되는 SSL 버전과 암호화, 세션 ID 및 인증서 정보를 포함합니다. SSL 교환에서는 별도의 단계이기는 하지만, 실제 X.509 서버 인증서 자체가 보통 서버 Hello와 같은 패킷에서 시작되고 해당 패킷에서 종료되는 경우가 많습니다.

• 인증서 - X.509 인증서는 변경할 수 없는 전자 보안 승인의 디지털 스탬프입니다. 인증서에는 다음과 같은 네 가지 주요 특성이 있습니다.

– CN(일반 이름) 또는 DN(고유 이름)으로 인증서 제목 식별

– 통신 주체 간에 교환하는 메시지를 암호화하고 암호를 해독하는 데 사용할 수 있는 공용 키 포함

– 인증서를 발급한 신뢰할 수 있는 조직(인증 기관)의 디지털 서명 제공

– 유효한 인증서 날짜 범위 표시

• 제목 – CN(일반 이름)으로 식별되는 인증서에 대한 보증입니다. 클라이언트가
https://www.mysonicwall.com 같은 SSL 사이트로 이동할 때 서버가 해당 인증서를 보내면 클라이언트가 인증서를 평가합니다. 클라이언트는 인증서의 날짜가 유효하고, 신뢰할 수 있는 CA가 인증서를 발급했으며, 제목 CN이 요청한 호스트 이름과 일치하는지(두 이름이 모두 "www.mysonicwall.com"인지) 확인합니다. 제목 CN이 일치하지 않으면 브라우저 경고가 표시되지만, 이것이 항상 사기를 의미하는 것은 아닙니다. 예를 들어 클라이언트가 www.mysonicwall.com 같은 IP 주소로 확인되는 https://mysonicwall.com으로 이동하면 서버가 제목 CN에 www.mysonicwall.com이 포함된 인증서를 제공합니다. 이 경우 연결은 합법적이지만 클라이언트에 경고가 표시됩니다.

• CA(인증 기관) - CA(인증 기관)는 신뢰할 수 있는 엔터티로, 기본적으로 올바른 인증서에 서명하여 인증서 주체의 신원 유효성을 검사할 수 있습니다. 잘 알려진 인증 기관으로는 VeriSign, Thawte, Equifax, Digital Signature Trust 등이 있습니다. 일반적으로 SSL 프레임워크 내에서 CA를 신뢰하려면 CA 인증서를 신뢰할 수 있는 저장소 내에 저장해야 합니다. 대부분의 웹 브라우저, 운영 체제 및 런타임 환경에서 이러한 방법이 사용됩니다. SonicOS 신뢰할 수 있는 저장소는 시스템 > 인증서 페이지에서 액세스할 수 있습니다. CA 모델은 결합형 신뢰를 기반으로 구축됩니다. 여기서는 클라이언트가 해당 신뢰할 수 있는 저장소에 CA 인증서를 저장하여 CA를 신뢰하고, CA는 주체에게 인증서를 발급하여 주체를 신뢰합니다. 따라서 클라이언트가 주체를 신뢰할 수 있습니다.

• 신뢰할 수 없는 CA – 클라이언트의 신뢰할 수 있는 저장소에 포함되지 않은 CA입니다. SSL 컨트롤에서 신뢰할 수 없는 CA는 시스템 > 인증서에 인증서가 없는 CA입니다.

• 자체 서명 인증서 – 발급자의 일반 이름 및 주체의 일반 이름이 같은 인증서(인증서가 자체 서명되었음을 나타냄)입니다.

• 가상 호스팅 – 웹 서버가 단일 서버에서 여러 웹 사이트를 호스팅하는 데 사용하는 방법입니다. 일반적인 가상 호스팅 구현은 이름 기반(호스트-헤더) 가상 호스팅으로, 이 구현에서는 단일 IP 주소에서 여러 웹 사이트를 호스팅할 수 있습니다. 호스트-헤더 가상 호스팅을 사용하는 경우 서버는 클라이언트에서 전송한 "Host:" 헤더를 평가하여 요청된 사이트를 확인합니다. www.website1.com과 www.website2.com이 모두 64.41.140.173으로 확인되는 경우를 예로 들어 보겠습니다. 클라이언트가 "Host: www.website1.com"과 함께 "GET /"을 보내면 서버에서 이 사이트에 해당하는 콘텐츠를 반환할 수 있습니다.

호스트-헤더 가상 호스팅은 보통 HTTPS에서 사용되지 않습니다. SSL이 연결될 때까지는 호스트 헤더를 읽을 수 없는데, 서버가 인증서를 보내야 SSL을 연결할 수 있기 때문입니다. 서버는 클라이언트가 요청할 사이트를 확인할 수 없으므로(SSL 핸드셰이크 중에는 IP 주소밖에 알 수 없음) 전송하기에 적절한 인증서를 결정할 수 없습니다. 임의의 인증서를 보내면 SSL 핸드셰이크를 시작할 수는 있지만 인증서 이름(주체)이 일치하지 않아 브라우저 경고가 표시됩니다.

• 약한 암호화 – 비교적 약한 대칭 암호화 기술입니다. 64비트 미만의 암호화는 약한 암호화로 분류됩니다. 대부분의 경우 내보내기 암호화는 약한 암호화입니다. 아래 일반적인 약한 암호화 목록이 나와 있습니다.

경고 및 공지

1. 자체 서명 및 신뢰할 수 없는 CA 적용 - 이 두 옵션 중 하나를 적용하는 경우 조직 내의 SSL로 보호된 네트워크 어플라이언스의 일반 이름을 화이트 리스트에 추가하여 해당 장치에 대한 연결이 중단되지 않도록 하는 것이 좋습니다. 예를 들어 Dell SonicWALL 네트워크 보안 어플라이언스의 기본 주체 이름은 "192.168.168.168"이고 Dell SonicWALL SSL VPN 어플라이언스의 기본 일반 이름은 "192.168.200.1"입니다.

2. 조직에서 자체 개인 CA(인증 기관)를 사용하는 경우 개인 CA 인증서를 시스템 > 인증서 저장소로 가져오는 것이 좋은데, 특히 신뢰할 수 없는 CA에서 발급한 인증서를 차단하려는 경우에 그렇습니다. 이 프로세스에 대한 자세한 내용은 SonicOS 관리자 가이드의 시스템 > 인증서 섹션을 참조하십시오.

3. 현재 SSL 컨트롤 검사는 TCP 포트 443 트래픽에 한해서만 수행됩니다. 비표준 포트에서 수행되는 SSL 협상은 현재 검사되지 않습니다.

4. 서버 Hello 조각화 – 드물지만 SSL 서버가 서버 Hello를 조각화하는 경우가 있습니다. 이러한 경우 현재 SSL 컨트롤 구현에서는 서버 Hello의 암호를 해독하지 않습니다. SSL 컨트롤 정책은 SSL 세션에 적용되지 않고 SSL 세션이 허용됩니다.

5. 세션 종료 처리 – SSL 컨트롤은 보안 위반을 감지하여 SSL 세션을 종료할 때 단순히 TCP 계층에서 세션을 종료합니다. SSL 세션은 아직 초기 단계이므로 현재 클라이언트를 리디렉션하거나 클라이언트에 종료 정보 알림을 제공하지 않습니다.

6. 화이트 리스트 우선 순위 – 화이트 리스트는 기타 모든 SSL 컨트롤 요소보다 우선 적용됩니다. 화이트 리스트의 항목과 일치하는 SSL 서버 인증서는 SSL 세션의 다른 요소가 구성된 정책을 위반하더라도 SSL 세션을 계속 진행하도록 허용합니다. 이는 정상적인 현상입니다.

7. 미리 설치된(알려진) CA 인증서는 93입니다. 결과 리포지토리는 대부분의 웹 브라우저에서 제공되는 것과 매우 비슷합니다. 기타 인증서 관련 변경 내용은 다음과 같습니다.

a. CA 인증서의 최대 수가 6개에서 256개로 늘어났습니다.

b. 개별 인증서의 최대 크기가 2,048에서 4,096으로 증가했습니다.

c. 화이트 리스트와 블랙 리스트의 최대 항목 수는 각각 1,024개입니다.

SSL 컨트롤 구성

SSL 컨트롤은 방화벽 패널의 SSL 컨트롤 폴더에 있으며, 전역 설정과 영역별 설정을 모두 포함합니다. 기본적으로 SSL 컨트롤은 전역 또는 영역 수준에서 사용하도록 설정되지 않습니다. 개별 페이지 컨트롤은 다음과 같습니다. 아래 사용된 용어에 대한 자세한 내용은 SSL 컨트롤의 주요 개념 섹션을 참조하십시오.

일반 설정

• SSL 컨트롤 사용 - SSL 컨트롤에 대한 전역 설정입니다. 이 옵션을 사용하도록 설정해야 영역에 적용한 SSL 컨트롤이 유효한 상태가 됩니다.

작업

• 이벤트 로깅 – 아래 구성 섹션에 정의된 대로 SSL 정책 위반이 감지되면 이벤트가 로깅됩니다. 단 SSL은 계속 연결할 수 있습니다.

• 연결 차단 및 이벤트 로깅 – 정책 위반 시 연결이 차단되고 이벤트가 로깅됩니다.

구성

• 블랙 리스트 사용 – 아래의 목록 구성 섹션에 구성된 대로 블랙 리스트의 항목 감지 기능을 제어합니다.

• 화이트 리스트 사용 – 아래의 목록 구성 섹션에 구성된 대로 화이트 리스트의 항목 감지 기능을 제어합니다. 화이트 리스트 항목은 기타 모든 SSL 컨트롤 설정보다 우선 적용됩니다.

• 만료된 인증서 검색 – 해당 시작 날짜가 현재 시스템 시간 이전이거나 종료 날짜가 현재 시스템 시간 이후인 인증서 감지 기능을 제어합니다. 날짜 유효성은 방화벽의 시스템 시간에 따라 달라집니다. 시스템 > 시간 페이지에서 시스템 시간이 올바르게 설정되어 있는지 확인하십시오.

• SSLv2 검색 – SSLv2 교환 감지 기능을 제어합니다. SSLv2는 핸드셰이크에 대한 무결성 검사를 수행하지 않으므로 암호화 다운그레이드 공격에 취약한 것으로 알려져 있습니다. SSLv2 대신 SSLv3 또는 TLS를 사용하는 것이 가장 좋습니다.

• 자체 서명된 인증서 검색 – 발급자와 주체의 일반 이름이 같은 인증서 감지 기능을 제어합니다.

• 미인증 CA에서 서명한 인증서 검색 – 발급자 인증서가 방화벽의 시스템 > 인증서 신뢰할 수 있는 저장소에 포함되지 않은 인증서 감지 기능을 제어합니다.

• 약한 암호화(64비트 미만) 검색 – 64비트 미만의 대칭 암호화를 통해 협상된 SSL 세션 감지 기능을 제어합니다(보통 내보내기 암호화 사용 현황을 나타냄).

• MD5 다이제스트 감지 – MD5 해시를 사용하여 만든 인증서 감지 기능을 제어합니다.

사용자 지정 목록

• 블랙 리스트 및 화이트 리스트 구성 – 관리자가 SSL 인증서에서 일반 이름을 일치시키기 위한 문자열을 정의할 수 있습니다. 항목은 대소문자를 구분하지 않으며 다음과 같은 패턴 일치 방식에 사용됩니다.