KR102147917B1 - Ssl/tls 서비스 패킷 분류 방법 및 장치 - Google Patents

Ssl/tls 서비스 패킷 분류 방법 및 장치 Download PDF

Info

Publication number
KR102147917B1
KR102147917B1 KR1020190006830A KR20190006830A KR102147917B1 KR 102147917 B1 KR102147917 B1 KR 102147917B1 KR 1020190006830 A KR1020190006830 A KR 1020190006830A KR 20190006830 A KR20190006830 A KR 20190006830A KR 102147917 B1 KR102147917 B1 KR 102147917B1
Authority
KR
South Korea
Prior art keywords
packet
ssl
tls
service
database
Prior art date
Application number
KR1020190006830A
Other languages
English (en)
Other versions
KR20200089943A (ko
Inventor
김봉준
Original Assignee
주식회사 윈스
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 주식회사 윈스 filed Critical 주식회사 윈스
Priority to KR1020190006830A priority Critical patent/KR102147917B1/ko
Publication of KR20200089943A publication Critical patent/KR20200089943A/ko
Application granted granted Critical
Publication of KR102147917B1 publication Critical patent/KR102147917B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/19—Flow control; Congestion control at layers above the network layer
    • H04L47/193—Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2441—Traffic characterised by specific attributes, e.g. priority or QoS relying on flow classification, e.g. using integrated services [IntServ]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H04L67/28—
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

본 개시는 SSL/TLS(Secure Sockets Layer/ Transport Layer Security) 서비스 패킷 분류 방법 및 장치에 관한 것이다. SSL/TLS 서비스 패킷 분류 방법은 SSL/TLS 서비스 패킷 분류 장치의 외부로부터 패킷을 수신하는 단계; 패킷의 패킷 헤더를 추출하는 단계; 패킷 헤더에 포함된 복수의 정보를 조합하여, 조합된 정보가 데이터베이스 내에 존재하는지 검색하는 단계; 및 데이터베이스 내에 존재하며 조합된 정보와 매칭되는 서비스 정보가, 패킷이 SSL/TLS 서비스 패킷 임을 나타내는 것인지 판단하는 단계를 포함하고, 판단 결과 패킷이 SSL/TLS 서비스 패킷이면, 패킷을 사용자 영역에서 패킷의 복호화를 위해 동작하는 SSL/TLS 프록시 서버로 전달하고, 판단 결과 패킷이 SSL/TLS 서비스 패킷이 아니면, 패킷을 SSL/TLS 서비스 패킷 분류 장치의 외부로 출력할 수 있다.

Description

SSL/TLS 서비스 패킷 분류 방법 및 장치{METHOD AND APPARATUS FOR CLASSIFYING SSL/TLS SERVICE PACKET}
본 개시는 SSL/TLS(Secure Sockets Layer/ Transport Layer Security) 서비스 패킷 분류 방법 및 장치에 관한 것이고, 보다 상세하게 사용자 단말기와 서버간 송수신되는 패킷들에 대하여, 일반 패킷과 SSL/TLS 서비스 패킷을 빠르게 구분하고, SSL/TLS 서비스 패킷만을 SSL/TLS 프록시 서버로 전달할 수 있는 SSL/TLS 서비스 패킷 분류 방법 및 장치에 관한 것이다.
보안에 대한 요구사항으로, HTTP(HyperText Transfer Protocol) 보다는 HTTPS(HyperText Transfer Protocol Secure Socket)의 사용이 권고되고 있다. HTTPS는 기존의 HTTP에 보안 요소가 추가된 프로토콜이며, 서버와 사용자 단말기 사이의 통신 내용을 암호화하여 통신이 이루어지게 한다. HTTPS는 SSL/TLS 프로토콜을 사용하여 암호화를 수행하며, 따라서 SSL/TLS 프로토콜에 기반하여 암호화된 패킷의 사용량도 점차 증가하고 있다.
하지만, 암호화된 패킷은 서버에 연결된 보안 서버의 침입 탐지 기능을 어렵게 할 수 있다. 일반적으로, 네트워크 망에서 외부로부터 내부 시스템으로 들어오는 트래픽에는 네트워크 망을 위협하는 여러 공격들이 존재하며, 이러한 공격들을 차단하여 양호한 네트워크 망을 구성하기 위하여 보안 서버가 이용된다. 보안 서버는 패킷을 서버로 전달하거나, 또는 드랍(drop) 시키기 위하여 패킷을 분석하는 과정을 수반한다. 하지만, 보안 서버가 암호화된 패킷을 수신할 경우, 그 자체로는 패킷의 내용을 알 수가 없어서, IPS(Intrusion Prevention System) 엔진 및 IDS(Intrusion Detection System) 엔진, 애플리케이션 제어, 또는 안티 바이러스 기능으로 수신한 패킷의 유해성 여부를 판단할 수 없다.
RSA와 Fixed Diffie-Hellman 과 같이 고정키 방식으로 암호화된 경우 암호화된 패킷만 선별적으로 분리해서 복호화 한 후 보안서버에서 패킷의 유해성 여부를 판단할 수 있었다. 하지만, 고정키 방식을 사용하지 않는 Diffie-Hellman 방식에서는 프록시 서버(예를 들어, SSL/TLS 프록시 서버)를 이용하여, 사용자 단말기와 서버간 통신을 프록시 방식으로 연결하고, 사용자 단말기로부터 수신한 패킷을 복호화 하여 패킷 분석을 수행하며, 패킷을 다시 암호화 하여 서버로 패킷을 전달하는 중계 기능을 한다.
SSL/TLS 프로토콜을 사용하지만 Well-known 포트를 사용하지 않는 어플리케이션들이 많아, 포트 정보만으로는 SSL/TLS 프로토콜인지 판단 할 수 없어서, 프록시 방식을 채택한 보안 서버는 SSL/TLS 프로토콜로 암호화된 패킷 뿐만 아니라, 프록시 방식으로 처리될 필요가 없는 TCP 패킷에 대해서도 모두 프록시 처리를 하고 있다. 보안 서버로 유입되는 모든 패킷들에 대하여 프록시 방식을 사용하면 프록시 서버의 프로세서(예를 들어, CPU, MPU, GPU 등)의 부하가 높아지므로, 보안 장비의 전체적인 탐지 성능이 저하되는 문제가 있다.
한국등록특허 제1141919호
본 개시는 사용자 단말기와 서버 사이의 보안 서버에서 SSL/TLS 서비스 패킷을 고속으로 분류하고, 분류한 SSL/TLS 서비스 패킷만을 프록시 서버로 전달함으로써, 프록시 서버의 부하를 줄일 수 있는 SSL/TLS 서비스 패킷 분류 방법 및 장치를 제공하는데 그 목적이 있다.
상기와 같은 과제를 해결하기 위한 본 개시의 사용자 단말기와 서버 사이에 배치되어 커널 영역에서 동작하는 SSL/TLS(Secure Sockets Layer/ Transport Layer Security) 서비스 패킷 분류 장치의 SSL/TLS 서비스 패킷 분류 방법은 SSL/TLS 서비스 패킷 분류 장치의 외부로부터 패킷을 수신하는 단계; 패킷의 패킷 헤더를 추출하는 단계; 패킷 헤더에 포함된 복수의 정보를 조합하여, 조합된 정보가 데이터베이스 내에 존재하는지 검색하는 단계; 및 데이터베이스 내에 존재하며 조합된 정보와 매칭되는 서비스 정보가, 패킷이 SSL/TLS 서비스 패킷 임을 나타내는 것인지 판단하는 단계를 포함하고, 판단 결과 패킷이 SSL/TLS 서비스 패킷이면, 패킷을 사용자 영역에서 패킷의 복호화를 위해 동작하는 SSL/TLS 프록시 서버로 전달하고, 판단 결과 패킷이 SSL/TLS 서비스 패킷이 아니면, 패킷을 SSL/TLS 서비스 패킷 분류 장치의 외부로 출력할 수 있다.
일 실시예에서, SSL/TLS 서비스 패킷 분류 방법은 검색 결과 데이터베이스에 조합된 정보가 존재하지 않으면, 패킷 헤더를 이용하여, 패킷이 SSL/TLS 서비스 패킷인지의 여부를 판단하는 패킷 검사 단계를 더 포함하고, 패킷 검사 결과, 패킷이 SSL/TLS 서비스 패킷으로 판단되면, 데이터베이스에 조합된 정보와 매칭되는 패킷은 SSL/TLS 서비스 패킷 임을 나타내는 서비스 정보를 등록하고, 패킷이 SSL/TLS 서비스 패킷이 아닌 것으로 판단되면, 조합된 정보와 매칭되는 패킷은 SSL/TLS 서비스 패킷이 아님을 나타내는 서비스 정보를 등록할 수 있다.
일 실시예에서, 패킷 검사 단계는 패킷의 SSL/TLS 핸드셰이크 타입 필드에 저장된 정보가 패킷 내에 "Client Hello" 및 "Server Hello" 메시지가 존재함을 나타내는 정보이면, 패킷을 SSL/TLS 서비스 패킷으로 판단할 수 있다.
일 실시예에서, 조합된 정보는 목적지 IP 주소와 포트 번호가 조합된 정보를 의미할 수 있다.
본 개시의 일 실시예에 따른 SSL/TLS 서비스 패킷 분류 장치는 상술한 방법을 수행하는 제어부를 포함할 수 있다.
본 개시의 일 실시예에 따른 컴퓨터-판독가능 저장 매체는 컴퓨터 프로그램이 프로세서에 의해 실행될 때, 상술한 방법이 수행되는 컴퓨터 프로그램을 저장할 수 있다.
일 실시예에 따른 SSL/TLS 서비스 패킷 분류 방법 및 장치는 목적지 IP 주소와 포트 번호의 조합에 기반한 데이터베이스 검색 방식을 이용한다. 본 개시의 일 실시예는 데이터베이스에 저장된 정보들을 활용하므로, 전체 패킷들에 대해 검사를 수행하는 방식에 비해, SSL/TLS 서비스 패킷을 빠르게 분류할 수 있고, 보안 서버 또는 SSL/TSL 프록시 서버의 부담을 감소시킬 수 있다. 또한, 프록시 서버는 SSL/TLS 서비스 패킷으로 분류된 패킷들을 수신하고 복호화를 수행하므로, 탐지 효율을 높일 수 있는 장점이 있다.
또한, 일 실시예에 따른 SSL/TLS 서비스 패킷 분류 방법 및 장치는 커널(Kernel) 영역에서 제어를 수행한다. NIC를 통해 패킷을 수집한 후 바로 처리가 가능하기 때문에 사용자(User) 영역에서 제어를 수행하는 것보다 효율성이 높다.
또한, 일 실시예에 따른 SSL/TLS 서비스 패킷 분류 방법 및 장치는 데이터베이스에서 서비스 정보가 검색되지 않은 패킷들에 대해서만 패킷 검사를 수행하고, 데이터베이스를 갱신할 수 있다. 또한, 패킷 검사와 데이터베이스 갱신 과정은 모두 앞서 설명한 커널 영역에서 이루어져서 빠른 처리가 가능하고, 데이터베이스의 갱신을 통하여 패킷 검사 과정을 최소화시킬 수 있다.
도 1a 및 도 1b는 일반적인 보안 서버에 대한 개념도이다.
도 2는 일 실시예에 따른 SSL/TLS 서비스 패킷 분류 장치에 대한 개념도이다.
도 3 및 도 4는 일 실시예에 따른 SSL/TLS 서비스 패킷 분류 장치에 대한 블록도이다.
도 5는 클라이언트와 서버간 이루어지는 핸드셰이크 방법을 설명하기 위한 개념도이다.
도 6 내지 도 8은 일 실시예에 따른 SSL/TLS 서비스 패킷 분류 장치를 통한 패킷의 흐름을 설명하기 위한 개념도이다.
도 9는 일 실시예에 따른 SSL/TLS 서비스 패킷 분류 방법에 대한 흐름도이다.
본 개시의 실시예들은 기능적인 블록 구성들 및 다양한 처리 단계들로 나타내어질 수 있다. 이러한 기능 블록들의 일부 또는 전부는, 본 개시에서 설명하는 특정 기능들을 실행하는 다양한 개수의 하드웨어 및/또는 소프트웨어 구성들로 구현될 수 있다. 예를 들어, 본 개시의 기능 블록들은 하나 이상의 마이크로프로세서들에 의해 구현되거나, 소정의 기능을 위한 회로 구성들에 의해 구현될 수 있다. 또한, 예를 들어, 본 개시의 기능 블록들은 다양한 프로그래밍 또는 스크립트 언어로 구현될 수 있다. 기능 블록들은 하나 이상의 프로세서들에서 실행되는 알고리즘으로 구현될 수 있다. 또한, 본 개시는 전자적인 환경 설정, 신호 처리, 및/또는 데이터 처리 등을 위하여 종래 기술을 채용할 수 있다.
또한, 도면에 도시된 구성 요소들 간의 연결 선 또는 연결 부재들은 기능적인 연결 및/또는 물리적 또는 회로적 연결들을 예시적으로 나타낸 것일 뿐이다. 실제 장치에서는 대체 가능하거나 추가된 다양한 기능적인 연결, 물리적인 연결, 또는 회로 연결들에 의해 구성 요소들 간의 연결이 나타내어질 수 있다. 각 구성요소 간의 연결은 직접적, 물리적, 회로적인 연결뿐만 아니라 무선 네트워크를 통한 연결도 가능하다.
또한, 본 명세서에 기재된 "...부", "모듈" 등의 용어는 적어도 하나의 기능이나 동작을 처리하는 단위를 의미하며, 이는 하드웨어 또는 소프트웨어로 구현되거나 하드웨어와 소프트웨어의 결합으로 구현될 수 있다. "부", "모듈"은 어드레싱될 수 있는 저장 매체에 저장되며 프로세서에 의해 실행될 수 있는 프로그램에 의해 구현될 수도 있다.
예를 들어, "부", "모듈" 은 소프트웨어 구성 요소들, 객체 지향 소프트웨어 구성 요소들, 클래스 구성 요소들 및 태스크 구성 요소들과 같은 구성 요소들과, 프로세스들, 함수들, 속성들, 프로시저들, 서브루틴들, 프로그램 코드의 세그먼트들, 드라이버들, 펌웨어, 마이크로 코드, 회로, 데이터, 데이터베이스, 데이터 구조들, 테이블들, 어레이들 및 변수들에 의해 구현될 수 있다.
도 1a는 일반적인 보안 서버(10)에 대한 개념도이다.
보안 서버(10)는 사용자 단말기(1a, 1b)와 서버(2) 간 통신에서, 사용자 단말기(1a, 1b)로부터의 패킷을 수신 및 분석하고, 정상 패킷으로 판단된 패킷을 서버(2)에 전달하는 기능을 한다. 상술한 바와 같이, HTTPS의 사용 등으로 인하여, 네트워크에서 SSL/TLS로 암호화된 패킷(이하, SSL/TLS 서비스 패킷)의 빈도가 증가하는 추세이다. 다만, 보안 서버(10)는 SSL/TLS 서비스 패킷의 내용을 확인할 수 없으므로, 암호 해독을 위하여 패킷을 SSL/TLS 프록시 서버(미도시)에 전달한다. 여기서, 프록시 서버는 하드웨어 또는 소프트웨어의 형태로 구현될 수 있으며, 보안 서버(10)에 연결 또는 내장될 수 있다.
도 1b는 일반적인 보안 서버(10)에 대한 개념도이며, 도 1b에서 SSL/TLS 프록시 서버는 프록시 모듈(11)의 형태로 보안 서버(10) 내에 내장된 상황을 가정한다.
SSL/TLS 프록시 모듈(11)은 제1 통신부(12)를 통하여 클라이언트(1)가 송신한 암호화 패킷을 수신할 경우, 패킷을 복호화한다. 그 후, SSL/TLS 프록시 모듈(11)은 복호화한 패킷을 보안 모듈(미도시)에 전달한다. 보안 모듈은 소프트웨어 또는 하드웨어의 형태로 구현될 수 있고, 보안 기능에 따라(예를 들어, 검사 종류에 따라) 사용자 영역 또는 커널 영역에서 복호화된 패킷을 검사하며, 해킹 등과 같은 공격 패킷을 드랍 시킴으로써, 서버(2)를 외부의 위협으로부터 보호할 수 있다. 그 후, 보안 모듈은 복호화된 패킷을 다시 SSL/TLS 프록시 모듈(11)로 전달할 수 있다.
위 방식은 제1 통신부(12)를 통하여 수신된 모든 TCP 패킷이 SSL/TLS 프록시 모듈(11)로 전달되는 점에서 문제점이 있다. 상술한 것처럼, SSL/TLS 프록시 모듈(11)은 SSL/TLS 서비스 패킷의 복호화와 암호화를 수행하기 위함인데, SSL/TLS 서비스 패킷이 아닌 다른 TCP 패킷은 SSL/TLS 프록시 모듈(11)로 전달될 필요가 없다. 하지만, 현재 방식은 SSL/TLS 서비스 패킷의 특수성으로 인하여, 모든 패킷이 SSL/TLS 프록시 모듈(11)로 전달되므로, 네트워크 및 장비의 자원이 비효율적으로 관리되는 문제가 있다.
이러한 문제점을 해소하기 위한 하나의 방법으로서, 443(HTTPS), 22(SSH)와 같이 SSL/TLS 서비스임이 명백한 TCP 포트만 SSL/TLS 프록시 모듈(11)로 전달하면 보안 서버의 부하를 상당히 줄일 수 있다. 하지만, 최근에는 SSL/TLS 프로토콜을 사용하지만 Well-known 포트를 사용하지 않는 애플리케이션들이 많아져서, 포트 정보만으로는 SSL/TLS 프로토콜인지 판단할 수 없다. 따라서, 포트 정보만을 이용할 경우 SSL/TLS 프로토콜인지 판단할 수 없으며, 그로 인해 모든 TCP 패킷에 대한 프록시 처리가 여전히 요구되고 있는 실정이다.
도 2는 일 실시예에 따른 SSL/TLS 서비스 패킷 분류 장치(100)에 대한 개념도이다. SSL/TLS 서비스 패킷 분류 장치(100)는 사용자 단말기(1a, 1b)와 서버(2) 사이에 배치될 수 있다. 도 2에는 보안 서버가 네트워크 내에 존재하지 않는 것으로 도시되었으나 이는 예시일 뿐이며, SSL/TLS 서비스 패킷 분류 장치(100)는 보안 서버에 직접 연결되거나 보안 서버 내에 소프트웨어의 형태로 탑재될 수 있다. 또한, 도 2에서 SSL/TLS 프록시 서버(30)는 SSL/TLS 서비스 패킷 분류 장치(100)와 분리된 하드웨어의 구성으로 도시되었으나 이는 예시일 뿐이며, SSL/TLS 프록시 서버(30)는 SSL/TLS 서비스 패킷 분류 장치(100) 또는 보안 서버 내에서 소프트웨어의 형태로 탑재될 수 있다. 또한, 도 2는 서버(2)가 한 개만 존재하는 것으로 도시하고 있으나, 이는 본 개시의 이해를 돕기 위해 간략화하여 도시한 것이며, 하나 또는 그 이상의 서버가 SSL/TLS 서비스 패킷 분류 장치(100)에 연결될 수 있다. 또한, 아래에서 언급되는 패킷이란 용어는 TCP(Transmission Control Protocol) 패킷을 나타낼 수 있다.
SSL/TLS 서비스 패킷 분류 장치(100)는 SSL/TLS 프록시 서버(30)에 가해지는 부하를 최소화하고, 전반적인 탐지 효율을 최적화하기 위한 것이다. 이를 위하여, SSL/TLS 서비스 패킷 분류 장치(100)는 네트워크에서 송, 수신되는 패킷(예를 들어, TCP 패킷) 중 SSL/TLS 서비스 패킷을 추출하고, SSL/TLS 서비스 패킷이 아닌 다른 패킷이 SSL/TLS 프록시 서버(30)에 전달되지 않도록 제어하는 기능을 한다.
상술한 바와 같이, 네트워크에는 암호화되지 않은 일반 패킷과 특정 알고리즘 또는 프로토콜에 따라 암호화된 암호화 패킷이 송신 또는 수신될 수 있다. 그 중에서도 HTTPS에 따른 SSL/TLS 서비스 패킷은 복호화를 위해 특수한 처리가 요구되므로 별도로 관리되어야 하지만, 통상적으로 SSL/TLS 서비스 패킷을 복호화할 수 있는 SSL/TLS 프록시 서버(30)가 모든 패킷을 처리하여, SSL/TLS 프록시 서버(30)의 부하가 높아지는 문제가 있다.
이 문제를 해소하기 위하여 SSL/TLS 서비스 패킷 분류 장치(100)는 사용자 단말기(1a, 1b)로부터 송신된 패킷을 분석하고, 일반 패킷 또는 SSL/TLS 서비스 패킷으로 분류하는 기능을 한다. 그 후, SSL/TLS 서비스 패킷 분류 장치(100)는 분류 결과에 따라, 서버(2) 또는 보안 서버(미도시)에 일반 패킷을 전달하고, SSL/TLS 프록시 서버(30)에 SSL/TLS 서비스 패킷을 전달한다.
일 실시예에서, SSL/TLS 서비스 패킷 분류 장치(100)는 패킷 헤더를 이용하여 패킷을 분류할 수 있다. 구체적으로, SSL/TLS 서비스 패킷 분류 장치(100)는 패킷 헤더를 기초로 데이터베이스(20)에서 정보들을 검색함으로써 패킷을 고속으로 분류할 수 있다. 여기서, 데이터베이스(20)에는 목적지 IP 주소와 포트 번호의 조합에 따라 분류된 서비스 정보들이 저장될 수 있다.
통상적으로, 서버와 사용자 단말기간의 통신에서 패킷의 암호화 및 암호화 방식은 서버가 제공하는 애플리케이션이 결정할 수 있다. 예를 들어, SSL/TLS 서비스 패킷 분류 장치(100)에 세 개의 서버가 연결되고, 제1 서버가 SSL/TLS 프로토콜을 사용하지만 Well-known 포트를 사용하지 않는 애플리케이션을 제공하고, 제2 서버가 HTTPS 프로토콜을 이용하는 애플리케이션을 제공하며, 제3 서버가 HTTP 프로토콜을 이용하는 애플리케이션을 제공하는 상황을 가정한다. 이 경우, 사용자 단말기는 서버에 의해 지정된 애플리케이션에 따라 패킷을 구성하므로, 제1 및 제2 서버에 데이터를 요청할 때 SSL/TLS 서비스 패킷을 발송하고, 제3 서버에 데이터를 요청할 때엔 암호화되지 않은 일반 패킷을 발송할 것이다.
또한, 제3 서버가 HTTP 프로토콜을 이용하는 애플리케이션 외에, 필요에 따라 포트 번호를 임의로 생성하는 애플리케이션을 제공하는 상황을 더 가정한다. 이 예시에서 사용자 단말기와 제1 서버 간, 그리고 사용자 단말기와 제3 서버 간 통신에 이용된 포트 번호는 필요에 따라 임의로 지정될 수 있다. 이 경우, 사용자 단말기와 제1 서버 간 통신에, 그리고 사용자 단말기와 제3 서버 간 통신에 동일한 포트 번호가 사용되는 상황을 배제할 수는 없으며, 포트 번호 만으로 패킷의 서비스 종류를 판단할 수 없음을 나타낸다. 하지만, 목적지 IP 주소와 포트 번호의 조합을 고려하거나, 목적지 IP 주소와 포트 번호의 조합과 각 목적지와 사용자 단말기간의 패킷 송수신 이력을 함께 고려한다면, 패킷 헤더를 이용한 패킷의 서비스 종류 판단이 가능해진다.
따라서, SSL/TLS 서비스 패킷 분류 장치(100)는 포트 번호는 물론, 목적지 IP 주소도 함께 고려한다. 다시 말해, SSL/TLS 서비스 패킷 분류 장치(100)는 데이터베이스(20)에 목적지 IP 주소와 포트 번호의 조합에 따라 서비스 종류에 대한 정보를 나타내는 서비스 정보를 저장한다. SSL/TLS 서비스 패킷 분류 장치(100)는 데이터베이스(20)에 저장된 정보들을 이용하여, 수신한 패킷의 서비스 종류를 빠르게 판단할 수 있다.
일 실시예에서, SSL/TLS 서비스 패킷 분류 장치(100)는 데이터베이스(20)에 저장되지 않은 패킷을 수신한 경우, 패킷에 대한 검사를 수행하며, 검사 결과를 이용하여 데이터베이스(20)를 갱신할 수 있다.
일 실시예에서, SSL/TLS 서비스 패킷 분류 장치(100)는 커널 영역에서 패킷 분석 및 분류를 수행할 수 있다. 상술한 것처럼, 메모리는 커널 영역과 사용자 영역으로 구분될 수 있고, 커널 영역은 프로세서가 커널 모드를 통해 접근하는 메모리 영역이다. 커널 영역은 프로세서에 의해 사용될 때, NIC를 통해 패킷을 수집한 후 바로 처리가 가능한 영역이기 때문에 사용자(User) 영역에서 제어를 수행하는 것보다 효율성이 높다.
도 3은 일 실시예에 따른 SSL/TLS 서비스 패킷 분류 장치(100)에 대한 블록도이다. SSL/TLS 서비스 패킷 분류 장치(100)는 서버(2) 및 SSL/TLS 프록시 서버에 연결될 수 있다. 본 예시에서는 SSL/TLS 프록시 서버의 기능을 하는 SSL/TLS 프록시 모듈(31)이 SSL/TLS 서비스 패킷 분류 장치(100)에 연결된 상황을 가정한다. 또한, 도 3에는 보안 서버가 도시되어 있지 않지만, SSL/TLS 서비스 패킷 분류 장치(100)는 보안 서버 내부에 소프트웨어의 형태로 탑재될 수도 있다.
제1 통신부(120)는 외부로부터 패킷(예를 들어, TCP 패킷)을 수신하고, 수신한 패킷을 제어부(110)에 전달하고, 제2 통신부(130)는 패킷을 제어부(110) 또는 SSL/TLS 프록시 모듈(31)로부터 수신하여 외부로 전달한다. 예를 들어, 제1 통신부(120)는 사용자 단말기(1)로부터 패킷을 수신할 수 있고, 제2 통신부(130)는 서버(2)로 패킷을 송신할 수 있다. 도면에 도시되진 않았지만, 다른 예시에서 서버(2)가 데이터를 송신하는 경우, 제1 통신부(120)는 패킷을 제어부(120)에 전달하고, 제2 통신부(130)는 패킷을 제어부(110) 또는 SSL/TLS 프록시 모듈(31)로부터 사용자 단말기(1)로 전달할 수도 있다.
제어부(110)는 커널 영역에서의 제어를 통해 제1 통신부(120)로부터 수신한 패킷의 서비스 종류를 판단하고, 판단 결과에 따라 패킷을 SSL/TLS 서비스 모듈(31) 또는 외부에 전달한다. 예를 들어, 제어부(110)는 판단 결과, 패킷이 SSL/TLS 서비스 패킷이면, 패킷을 사용자 영역에서 패킷의 복호화를 위해 동작하는 SSL/TLS 프록시 모듈(31)로 전달하고, 판단 결과 패킷이 SSL/TLS 서비스 패킷이 아니면, 패킷을 상기 SSL/TLS 서비스 패킷 분류 장치의 외부로 출력할 수 있다. 여기서, 외부란 용어는 제2 통신부(130)를 통해 패킷을 송신하는 대상을 특정 대상으로 한정하지 않기 위해 사용되었으며, 제어부(110)는 패킷이 SSL/TLS 서비스 패킷이 아니면, 패킷 송신 주체에 따라 서버(2), 보안 서버(미도시), 사용자 단말기(1) 중 하나에 패킷을 보낼 수 있다.
또한, 제어부(110)는 수신한 패킷의 패킷 헤더를 확인하고, 패킷 헤더에서 목적지 IP 주소 및 포트 번호를 추출하고, 목적지 IP 주소와 포트 번호을 조합하며, 데이터베이스(20)에서 조합된 정보를 검색함으로써 패킷의 서비스 종류에 대한 판단을 수행할 수 있다. 데이터베이스(20)에서 패킷에 대한 정보가 검색되지 않은 경우, 제어부(110)는 패킷 검사를 통하여 패킷의 SSL/TLS 서비스 패킷 여부를 판단한다. 판단 결과 패킷이 SSL/TLS 서비스로 판단되면, 데이터베이스(20)를 갱신한다. 제어부(110)를 통하여 이루어지는 동작은 도 4를 참조로 더 상세히 설명된다.
도 4는 일 실시예에 따른 제어부(110)에 대한 블록도이다. 제어부(110)는 패킷 수신부(111), 정보 추출부(112), 데이터베이스 검색부(113), 판단부(114) 및 패킷 검사부(115)를 포함할 수 있다. 제어부(110)에 포함된 각 구성은 본 개시의 이해를 돕기 위하여 기능적으로 구분한 것이고, CPU, MPU, GPU 등과 같은 하나의 처리 장치로 구현될 수 있다. 또한, 제어부(110)는 커널 영역을 통하여 제어를 수행할 수 있다.
패킷 수신부(111)는 제1 통신부(120)를 통하여, 외부(예를 들어, 사용자 단말기(1) 또는 서버(2))로부터 패킷(예를 들어, TCP 패킷)을 수신하는 기능을 한다.
정보 추출부(112)는 수신한 패킷의 패킷 헤더를 추출한다. 패킷은 패킷 헤더와 데이터로 구분될 수 있으며, 정보 추출부(112)는 아래에서 설명되는 데이터베이스 검색을 위하여 패킷 헤더 중 목적지 IP 주소 및 포트 번호를 추출하고, 이들을 조합할 수 있다. 또한, 정보 추출부(112)는 패킷의 SSL/TLS 핸드셰이크 타입을 더 추출할 수 있다. TCP 패킷을 이용한 통신은 서버와 클라이언트 간 3-웨이 핸드셰이크(3-way handshake) 과정이 필요하며, SSL/TLS 서비스 패킷을 이용한 통신은 3-웨이 핸드셰이크 과정 이후, SSL/TLS 핸드셰이크 과정이 더 필요하다. 여기서, 핸드셰이크의 개념은 도 5에 도시된다.
도 5는 클라이언트와 서버간 이루어지는 핸드셰이크 과정을 설명하기 위한 개념도이다. SSL/TLS 서비스 패킷의 전송을 위해서는, 도 5에 도시된 바와 같이 일반적인 TCP 핸드셰이크(예를 들어, 3-웨이 핸드셰이크) 이후, SSL/TLS 핸드셰이크 과정이 추가적으로 수행되어야 한다. SSL/TLS 핸드셰이크는 1) 서버와 클라이언트 간 상호 인증, 2) 암호 키 교환 및 암호화 알고리즘의 협상 및 확립을 도모하기 위한 정보 교환, 및 3) DES(Data Encryption Standard) 알고리즘 등에 기반한 세션키 생성을 위해 이루어진다. 이를 위해, SSL/TLS 핸드셰이크는 클라이언트가 서버로 "Client Hello" 메시지를 송신하고, 이후 서버가 클라이언트로 "Server Hello" 메시지를 송신하는 과정을 요구한다. 한편, 패킷에는 "SSL/TLS 핸드셰이크 타입" 필드가 포함될 수 있으며, SSL/TLS 핸드셰이크 타입 필드는 본 패킷에 "Client Hello" 메시지 및 "Server Hello" 메시지가 포함되어 있는지 여부를 나타낼 수 있다. 정보 추출부(112)는 패킷의 "SSL/TLS 핸드 셰이크 타입"의 필드 값을 확인함으로써 핸드셰이크 타입이 SSL/TLS 핸드셰이크인지 판단할 수 있고, 나아가 패킷이 SSL/TLS 서비스 패킷에 해당되는지 여부도 판단할 수 있다.
한편, 본 실시예에서는 패킷에 포함된 SSL/TLS 핸드셰이크 타입 필드에 기초하여, 패킷이 SSL/TLS 서비스 패킷에 해당되는지 여부를 판단하는 것으로 설명하였으나, 본 개시는 SSL/TLS 서비스 패킷에 해당되는지 여부를 판단하기 위해, 패킷 내의 어떠한 필드도 활용할 수 있다.
도 4를 다시 참조하면, 데이터베이스 검색부(113)는 정보 추출부(112)를 통해 추출된 패킷의 목적지 IP 주소 및 포트 번호를 기초로 데이터베이스(20)를 검색한다. 구체적으로, 데이터베이스 검색부(113)는 패킷의 목적지 IP 주소와 포트 번호의 조합이 데이터베이스(20)에 있는지 검색한다. 상술한 바와 같이, 데이터베이스(20)에는 목적지 IP 주소와 포트 번호의 조합에 따라 분류된 서비스 정보들이 저장될 수 있다.
판단부(114)는 패킷의 목적지 IP 주소와 포트 번호의 조합이 데이터베이스(20)에서 검색되었는지 판단한다. 판단 결과, 패킷의 목적지 IP 주소 와 포트 번호의 조합이 데이터베이스(20)에서 검색된 경우, 판단부(114)는 데이터베이스(20)에 저장된 정보를 기반으로 패킷이 SSL/TLS 서비스 패킷인지를 판단한다. 판단 결과, 패킷의 목적지 IP 주소와 포트 번호의 조합이 데이터베이스(20)에서 검색되어, 패킷이 SSL/TLS 서비스 패킷으로 판단된 경우, 판단부(114)는 패킷을 SSL/TLS 프록시 모듈(31)로 전달한다. 판단 결과, 패킷의 목적지 IP 주소와 포트 번호의 조합이 데이터베이스(20)에서 검색되었으나, 패킷이 SSL/TLS 서비스 패킷이 아닌 것으로 판단된 경우, 판단부(114)는 패킷을 제2 통신부(130)를 통해 외부(예를 들어, 패킷의 송신 주체에 따라 결정되는 서버(2) 또는 사용자 단말기(1), 또는 보안 서버(미도시) 등)로 전달한다. 판단 결과, 패킷의 목적지 IP 주소와 포트 번호의 조합이 데이터베이스(20)에서 검색되지 않은 경우, 패킷 검사부(115)를 통한 제어가 수행된다.
패킷 검사부(115)는 데이터베이스(20)에서 패킷에 대한 서비스 정보가 검색되지 않은 경우, 패킷을 검사하는 기능을 한다. 구체적으로, 패킷 검사부(115)는 패킷 헤더를 분석하여, 패킷이 SSL/TLS 서비스 패킷인지의 여부를 판단하는 패킷 검사를 수행한다. 일 실시예에 따른 패킷은 SSL/TLS 핸드셰이크 타입 필드를 포함할 수 있으며, SSL/TLS 핸드셰이크 타입 필드는 본 패킷이 Client Hello 메시지 또는 Server Hello 메시지를 포함하는지 여부를 의미할 수 있다. 따라서, 패킷 검사부(115)는 SSL/TLS 핸드셰이크 타입 필드에 기초하여, 본 패킷이 SSL/TLS 서비스 패킷인지 판단할 수 있다. 그 후, 패킷 검사부(115)는 데이터베이스(20)에 패킷의 목적지 IP 주소와 포트 번호의 조합 및 서비스 정보(예를 들어, 일반 패킷 또는 SSL/TLS 서비스 패킷)를 등록할 수 있다. 즉, 패킷 검사부(115)는 데이터베이스(20)에 저장된 데이터들을 갱신하고, SSL/TLS 서비스 패킷 분류 장치(100)는 패킷 검사부(115)를 통해 갱신된 데이터에 기반하여 패킷을 더욱 빨리 분류할 수 있다.
SSL/TLS 프록시 모듈(31)이 사용자 영역에서 제어를 수행하는 한편, SSL/TLS 서비스 패킷 분류 장치(100)는 커널 영역에서 제어를 수행한다. 즉, SSL/TLS 서비스 패킷 분류 장치(100)는 더욱 빠른 분류 작업을 위하여 커널 영역에서 제어를 수행할 수 있다. 따라서, SSL/TLS 서비스 패킷 분류 장치(100)는 SSL/TLS 프록시 모듈(31) 또는 SSL/TLS 프록시 서버의 부하를 최소화하고, SSL/TLS 서비스 패킷이 최대 효율로 복호화될 수 있도록 더욱 빠르게 상술한 분류 작업을 할 수 있다. 한편, SSL/TLS 프록시 모듈(31)은 커널 영역 상에서 구현이 어려운 점에 기인하여 통상적으로 사용자 영역에서 동작되도록 설계된다. 본 개시의 일 실시예는 SSL/TLS 프록시 모듈(31)의 알고리즘 또는 실행 방식을 변경하지 않고, SSL/TLS 서비스 패킷 분류 장치(100)만 추가하면 되기 때문에, 다양한 보안 설비에 적용 가능한 추가적인 장점이 있다.
또한, 위의 설명에선 데이터베이스(20)에 목적지 IP 주소와 포트 번호의 조합에 따라 서비스 정보가 저장되며, 판단부(114)는 데이터베이스(20)에 저장된 서비스 정보를 근거로 패킷의 서비스 종류를 판단하는 것으로 설명하였다. 다만, 본 개시는 이 방식에 제한되지 않으며, 다른 실시예에서는 데이터베이스(20)에 목적지 IP 주소와 포트 번호의 조합에 따라 발행되는 티켓에 관한 정보가 저장될 수 있다. 예를 들어, 데이터베이스(20)는 목적지 IP 주소와 포트 번호의 조합 별로 티켓의 발행 여부를 나타내는 티켓 발행 정보를 저장할 수 있다. 이 실시예에서 판단부(114)는 데이터베이스(20)에 저장된 티켓 발행 정보를 근거로, 패킷의 서비스 종류를 판단할 수 있다. 또한, 데이터베이스(20)에서 패킷의 목적지 IP 주소와 포트 번호의 조합이 검색되지 않은 경우, 상술한 패킷 검사부(115)를 통해, 추가적인 동작이 수행될 수 있다. 패킷 검사부(115)가 패킷 검사 결과에 따라 목적지 IP 주소와 포트 번호의 조합에 따라 티켓을 발행하는 점, 그리고 서비스 정보와 대체될 수 있는 티켓 발행 정보가 데이터베이스(20)에 등록된다는 점을 제외하곤 실질적으로 앞선 내용과 동일하므로, 중복되는 설명을 생략한다. 또한, 본 발명의 또 다른 실시예에서 티켓 발행 정보는 티켓이 발행된 목적지 IP 주소와 포트 번호의 조합을 구분하기 위해서만 사용될 수도 있다. 이 경우, 판단부(114)는 데이터베이스(20)에 저장된 티켓 발행 정보를 근거로 패킷의 목적지 IP 주소 및 포트 번호의 조합에 티켓이 발행되었는지 판단할 수 있고, 티켓이 발행된 패킷인 경우 이를 SSL/TLS 프록시 모듈(31)에 전달하고, 티켓이 발행되지 않은 패킷인 경우 패킷 검사부(115)를 통한 제어가 수행되게 할 수 있다.
도 6 내지 도 8은 일 실시예에 따른 SSL/TLS 서비스 패킷 분류 장치(100)를 통한 패킷의 흐름을 설명하기 위한 개념도이다. 아래의 설명에서 언급되는 패킷은 TCP 패킷일 수 있다.
도 6은 사용자 단말기(1)가 서버(2)로 암호화되지 않은 일반 패킷 또는 SSL/TLS 프로토콜이 아닌 다른 방식으로 암호화된 패킷을 송신할 때의 상황을 가정한다. 그리고, 패킷의 목적지 IP 주소와 포트 번호의 조합이 데이터베이스(20)에 등록되어 있는 상황을 가정한다.
제1 통신부(120)는 사용자 단말기(1)에 의해 송신된 패킷을 수신하고, 제어부(110)로 전달한다. 제어부(110)는 패킷의 목적지 IP 주소 및 포트 번호를 추출하고, 추출된 목적지 IP 주소와 포트 번호를 조합하며, 조합된 정보가 데이터베이스(20)에 존재하는지 검색한다. 검색 결과, 패킷의 목적지 IP 주소와 포트 번호의 조합이 데이터베이스(20)에 존재하는 경우, 제어부(110)는 데이터베이스(20)에 저장된 목적지 IP 주소와 포트 번호의 조합에 대한 서비스 정보에 기반하여, 패킷이 SSL/TLS 서비스 패킷인지의 여부를 판단할 수 있다. 본 예시의 경우 사용자 단말기(1)가 송신한 패킷은 일반 패킷이거나 또는 SSL/TLS 프로토콜이 아닌 다른 방식으로 암호화된 패킷인 상황을 가정하므로, 제어부(110)는 패킷이 SSL/TLS 서비스 패킷이 아니라고 결정할 수 있다. 그 후 제어부(110)는 제2 통신부(130)를 통하여 패킷을 외부(예를 들어, 서버(2) 또는 보안 서버)에 전달할 수 있다. 즉, 사용자 단말기(1)로부터 수신된 패킷이 SSL/TLS 서비스 패킷이 아닌 경우, 패킷은 SSL/TLS 프록시 모듈(31)에 전달되지 않는다. 도 6에서, 제2 통신부(130)가 패킷을 서버(2)로 송신하는 것으로 도시되었지만 이는 예시일 뿐이고, 패킷을 보안 서버(미도시)로 전달할 수 있다.
도 7은 사용자 단말기(1)가 서버(2)로 SSL/TLS 서비스 패킷을 송신할 때의 상황을 가정한다. 그리고, 패킷의 목적지 IP 주소와 포트 번호의 조합이 데이터베이스(20)에 등록되어 있는 상황을 가정한다. 제어부(110)는 사용자 단말기(1)로부터 수신된 패킷의 목적지 IP 주소와 포트 번호의 조합이 데이터베이스(20)에 존재하는지 검색한다. 본 예시는 수신한 패킷이 데이터베이스(20)에 등록된 상황을 가정하므로, 제어부(110)는 데이터베이스(20)에 저장된 데이터에 기반하여, 패킷이 SSL/TLS 서비스 패킷이라고 결정할 수 있으며, 패킷을 복호화하기 위해 SSL/TLS 프록시 모듈(31)로 전달한다.
도 8은 사용자 단말기(1)가 서버(2)로 송신한 패킷의 목적지 IP 주소와 포트 번호의 조합이 데이터베이스(20)에 등록되지 않은 상황을 가정한다. 제어부(110)는 사용자 단말기(1)로부터 수신된 패킷의 목적지 IP 주소와 포트 번호의 조합이 데이터베이스(20)에 존재하는지 검색한다. 본 예시는 사용자 단말기(1)로부터 수신된 패킷이 데이터베이스(20)에 등록되지 않은 상황을 가정하므로, 제어부(110)는 패킷에 포함된 SSL/TLS 핸드셰이크 타입 필드를 통해 패킷에 "Client Hello" 및 "Server Hello" 메시지가 있는지 판단한다. 판단 결과, 패킷에 "Client Hello" 및 "Server Hello" 메시지가 포함된 경우, 제어부(110)는 패킷을 SSL/TLS 서비스 패킷으로 판단하며, 데이터베이스(20)에 패킷의 목적지 IP 주소와 포트 번호의 조합, 그리고 패킷이 SSL/TLS 서비스 패킷임을 나타내는 서비스 정보를 등록한다. 또한, 패킷에 "Client Hello" 및 "Server Hello" 메시지가 포함되지 않은 경우, 제어부(110)는 패킷을 SSL/TLS 서비스 패킷이 아닌 일반 패킷으로 판단하며, 데이터베이스(20)에 패킷의 목적지 IP 주소와 포트 번호의 조합, 그리고 패킷이 암호화되지 않았거나, 또는 SSL/TLS가 아닌 다른 방식으로 암호화된 패킷임을 나타내는 서비스 정보를 등록한다. 여기서 제어부(110)는 데이터베이스(20)에 암호화되지 않은 패킷과 SSL/TLS 아닌 다른 방식으로 암호화된 패킷을 하나의 서비스 정보로 등록할 수도 있고, 각각 다른 서비스 정보로 등록할 수도 있다. 그 후, 제어부(110)는 패킷을 제2 통신부(130)로 전달한다.
도 6 내지 도 8을 참조로 한 설명은 데이터베이스(20) 내에 서비스 정보가 저장된 상황을 가정하였다. 다만 이는 예시일 뿐이고, 도 3 및 도 4를 참조로 설명한 것처럼 데이터베이스(20) 내에는 서비스 정보 대신 티켓 발행 정보가 저장될 수 있으며, 제어부(110)는 티켓 발행 정보를 이용하여 판단 및 데이터베이스 갱신을 할 수 있다. 여기서, 티켓 발행 정보는 사용자의 설정에 따라 목적지 IP 주소 및 포트 번호의 조합에 대한 티켓 발행 여부를 나타내는 정보이거나, 티켓이 발행된 목적지 IP 주소 및 포트 번호의 조합에 대한 정보일 수 있다.
도 9는 일 실시예에 따른 SSL/TLS 서비스 패킷 분류 방법에 대한 흐름도이다. SSL/TLS 서비스 패킷 분류 방법은 사용자 단말기와 서버 사이에 배치되고, 제어부를 포함하는 SSL/TLS 서비스 패킷 분류 장치에 의해 수행되며, 커널 영역에서 수행될 수 있다. 여기서, 제어부는 CPU, MPU, GPU 등과 같은 하나의 처리 장치로 구현될 수 있다. 상술한 바와 같이, SSL/TLS 서비스 패킷 분류 장치는 보안 서버에 직접 연결되거나 보안 서버 내에 소프트웨어의 형태로 탑재될 수 있다. 또한, SSL/TLS 서비스 패킷 분류 장치는 SSL/TLS 프록시 서버에 연결되거나, 그 내부에 하드웨어 또는 소프트웨어의 형태로 구현된 SSL/TLS 프록시 모듈을 포함할 수 있다.
S110 단계는 외부로부터 예를 들어, 제1 통신부를 통하여 패킷을 수신하는 단계이다. S110 단계를 통해 수신되는 패킷은 사용자 단말기로부터 서버로 송신되는 패킷이거나, 서버로부터 사용자 단말기로 송신되는 패킷일 수 있고, TCP 패킷일 수 있다.
S120 단계는 S110 단계를 통해 수신된 패킷의 패킷 헤더를 추출하는 단계이다. 구체적으로, S120 단계는 패킷의 패킷 헤더 중 목적지 IP 주소 및 포트 번호를 추출하고, 목적지 IP 주소와 포트 번호를 조합할 수 있다. 목적지 IP 주소 및 포트 번호는 조합되어 데이터베이스의 검색에 사용되며, 핸드셰이크 타입은 패킷 검사에 이용될 수 있다. 또한, S120 단계는 패킷에서 SSL/TLS 핸드셰이크 타입을 더 추출할 수 있다.
S130 단계는 패킷 헤더를 기초로 데이터베이스로부터 패킷에 대한 서비스 정보를 검색하는 단계이다. 구체적으로, S130 단계는 목적지 IP 주소와 포트 번호의 조합이 데이터베이스 내에 저장되어있는지 검색하는 단계이다. 상술한 바와 같이, 본 개시의 일 실시예는 데이터베이스에 목적지 IP 주소와 포트 번호의 조합에 따라 서비스 정보가 데이터베이스에 저장될 수 있다. 다른 실시예에서, 데이터베이스에는 서비스 정보를 대체할 수 있는 정보인 티켓 발행 여부에 대한 티켓 발행 정보가 데이터베이스에 저장될 수 있다. 또 다른 실시예에서, 티켓 발행 정보는 티켓이 발행된 목적지 IP 주소 및 포트 번호의 조합을 구분하기 위한 정보일 수 있다.
S140 단계는 패킷의 목적지 IP 주소와 포트 번호의 조합이 데이터베이스 내에 존재하는지 판단하는 단계이다. 패킷의 목적지 IP 주소와 포트 번호의 조합이 데이터베이스 내에 존재하는 경우, S140 단계는 패킷의 서비스 정보 또는 서비스 정보를 대체할 수 있는 정보인 티켓 발행 정보를 확인하는 단계를 더 수행할 수 있다.
S150 단계는 서비스 정보 또는 티켓 발행 정보의 확인을 통하여, S110 단계를 통해 수신한 패킷이 SSL/TLS 서비스 패킷인지 판단하는 단계이다. 판단 결과 패킷이 SSL/TLS 서비스 패킷인 것으로 판단된 경우, S160 단계에서 패킷을, 사용자 영역에서 복호화를 수행하는 프록시 모듈(예를 들어, SSL/TLS 프록시 모듈)에 전달하는 과정이 수행된다. 판단 결과, 패킷이 SSL/TLS 서비스 패킷이 아닌 것으로 판단된 경우, S170 단계에서 패킷을 제2 통신부를 통해 외부(예를 들어, 서버 또는 보안 서버 등)에 전달하는 과정이 수행된다.
S180 단계는 데이터베이스에 패킷의 목적지 IP 주소와 포트 번호의 조합이 존재하지 않을 때 수행되는 단계로서, 패킷을 분석하고, 패킷이 SSL/TLS 서비스 패킷인지의 여부를 판단하는 패킷 검사 단계이다. S180 단계는 패킷의 패킷 헤더를 분석하여, 패킷 내에 "Client Hello" 및 "Server Hello" 메시지가 존재하는지 여부를 확인하는 단계이다.
S190 단계는 S180 단계에서의 패킷 검사 결과에 기반하여, 패킷이 SSL/TLS 서비스 패킷인지 여부를 나타내는 서비스 정보를 데이터베이스에 등록하는 단계이다. 다른 실시예에서, S190 단계는 패킷 검사 결과에 기반하여, 패킷의 목적지 IP 주소 및 포트 번호에 티켓을 등록하고, 이에 대한 티켓 발행 정보를 데이터베이스에 등록할 수 있다.
본 개시에 속하는 기술 분야에서 통상의 지식을 가진 자는 본 개시가 본 개시의 본질적인 특성에서 벗어나지 않는 범위에서 변형된 형태로 구현될 수 있음을 이해할 수 있을 것이다. 그러므로 개시된 실시예들은 한정적인 관점이 아니라 설명적인 관점에서 고려되어야 한다. 본 개시의 범위는 전술한 설명이 아니라 특허청구범위에 나타나 있으며, 그와 동등한 범위 내에 있는 모든 차이점은 본 개시에 포함된 것으로 해석되어야 할 것이다.
한편, 상술한 본 개시의 실시예들은 컴퓨터에서 실행될 수 있는 프로그램으로 작성가능하고, 컴퓨터로 읽을 수 있는 기록매체를 이용하여 상기 프로그램을 동작시키는 범용 디지털 컴퓨터에서 구현될 수 있다. 상기 컴퓨터로 읽을 수 있는 기록매체는 마그네틱 저장매체(예를 들면, 롬, 플로피 디스크, 하드디스크 등), 광학적 판독 매체(예를 들면, 시디롬, 디브이디 등)와 같은 저장매체를 포함한다.
100: SSL/TLS 서비스 패킷 분류 장치
110: 제어부 111: 패킷 수신부
112: 정보 추출부 113: 데이터베이스 검색부
114: 판단부 115: 패킷 검사부
120: 제1 통신부 130: 제2 통신부

Claims (6)

  1. SSL/TLS(Secure Sockets Layer/ Transport Layer Security) 서비스 패킷 분류 장치의 SSL/TLS 서비스 패킷 분류 방법으로서,
    상기 SSL/TLS 서비스 패킷 분류 장치의 외부로부터 패킷을 수신하는 단계;
    상기 패킷의 패킷 헤더를 추출하는 단계;
    상기 패킷 헤더를 기반으로 상기 패킷과 관련된 목적지 IP 주소 및 포트 번호를 확인하는 단계;
    상기 목적지 IP 주소 및 상기 포트 번호를 기반으로 대응되는 정보가 데이터베이스 내에 존재하는지 검색하는 단계; 및
    상기 대응되는 정보에 포함되는 서비스 정보가, 상기 패킷이 SSL/TLS 서비스 패킷 임을 나타내는 것인지 판단하는 단계를 포함하고,
    상기 판단 결과 상기 패킷이 SSL/TLS 서비스 패킷이면, 상기 패킷을 사용자 영역에서 상기 패킷의 복호화를 위해 동작하는 SSL/TLS 프록시 서버로 전달하고,
    상기 판단 결과 상기 패킷이 SSL/TLS 서비스 패킷이 아니면, 상기 패킷을 상기 SSL/TLS 서비스 패킷 분류 장치의 외부로 출력하고,
    상기 SSL/TLS 서비스 패킷 분류 장치는 사용자 단말기와 서버 사이에 배치되어 커널 영역에서 동작하는 것인 SSL/TLS 서비스 패킷 분류 방법.
  2. 제1항에 있어서,
    상기 검색 결과 상기 데이터베이스에 상기 대응되는 정보가 존재하지 않으면,
    상기 패킷 헤더를 이용하여, 상기 패킷이 SSL/TLS 서비스 패킷인지의 여부를 판단하는 패킷 검사 단계를 더 포함하고,
    상기 패킷 검사 결과,
    상기 패킷이 SSL/TLS 서비스 패킷으로 판단되면, 상기 데이터베이스에 상기 목적지 IP 주소 및 상기 포트 번호에 대응하는 패킷은 SSL/TLS 서비스 패킷 임을 나타내는 서비스 정보를 등록하고,
    상기 패킷이 SSL/TLS 서비스 패킷이 아닌 것으로 판단되면, 상기 데이터베이스에 상기 목적지 IP 주소 및 상기 포트 번호에 대응하는 패킷은 SSL/TLS 서비스 패킷이 아님을 나타내는 서비스 정보를 등록하는 것인 SSL/TLS 서비스 패킷 분류 방법.
  3. 제2항에 있어서,
    상기 패킷 검사 단계는,
    상기 패킷의 SSL/TLS 핸드셰이크 타입 필드에 저장된 정보가 상기 패킷 내에 "Client Hello" 및 "Server Hello" 메시지가 존재함을 나타내는 정보이면, 상기 패킷을 SSL/TLS 서비스 패킷으로 판단하는 것인 SSL/TLS 서비스 패킷 분류 방법.
  4. 제1항에 있어서,
    상기 포트 번호를 기반으로 상기 패킷과 관련된 서비스가 확인되며,
    상기 패킷이 SSL/TLS 서비스 패킷임을 나타내는 것인지 판단하는 단계는 상기 패킷이 TCP 패킷인 경우에 수행되는 것인 SSL/TLS 서비스 패킷 분류 방법.
  5. 제1항 내지 제4항 중 어느 한 항에 따른 방법을 수행하는 제어부를 포함하는 SSL/TLS 서비스 패킷 분류 장치.
  6. 컴퓨터 프로그램이 프로세서에 의해 실행될 때, 제1항 내지 제4항 중 어느 한 항에 따른 방법이 수행되는, 컴퓨터 프로그램을 저장한 컴퓨터-판독가능 저장 매체.
KR1020190006830A 2019-01-18 2019-01-18 Ssl/tls 서비스 패킷 분류 방법 및 장치 KR102147917B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020190006830A KR102147917B1 (ko) 2019-01-18 2019-01-18 Ssl/tls 서비스 패킷 분류 방법 및 장치

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020190006830A KR102147917B1 (ko) 2019-01-18 2019-01-18 Ssl/tls 서비스 패킷 분류 방법 및 장치

Publications (2)

Publication Number Publication Date
KR20200089943A KR20200089943A (ko) 2020-07-28
KR102147917B1 true KR102147917B1 (ko) 2020-08-25

Family

ID=71831479

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020190006830A KR102147917B1 (ko) 2019-01-18 2019-01-18 Ssl/tls 서비스 패킷 분류 방법 및 장치

Country Status (1)

Country Link
KR (1) KR102147917B1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102321934B1 (ko) 2021-07-05 2021-11-04 주식회사 두두아이티 보안성 향상을 위한 ssl 기반의 프록시 서버

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102657165B1 (ko) * 2023-06-09 2024-04-15 인스피언 주식회사 데이터 관리 장치, 데이터 관리 방법 및 데이터 관리 프로그램을 저장하는 컴퓨터로 판독 가능한 저장 매체

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5233731B2 (ja) * 2009-02-19 2013-07-10 大日本印刷株式会社 Ｓｓｌ／ｔｌｓ接続方法及びコンピュータプログラム

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101141919B1 (ko) 2010-10-26 2012-05-07 주식회사 윈스테크넷 에스에스엘/티엘에스 트래픽의 다중 복호화 구성에 따른 고성능 네트워크장비 및 고성능 네트워크 데이터 처리방법
KR101429687B1 (ko) * 2013-01-25 2014-08-13 주식회사 시큐아이 프록시를 탐지하기 위한 장치 및 방법
KR102080280B1 (ko) * 2017-04-12 2020-02-21 주식회사 지티웨이브 가상 사설 네트워크 서버

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5233731B2 (ja) * 2009-02-19 2013-07-10 大日本印刷株式会社 Ｓｓｌ／ｔｌｓ接続方法及びコンピュータプログラム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102321934B1 (ko) 2021-07-05 2021-11-04 주식회사 두두아이티 보안성 향상을 위한 ssl 기반의 프록시 서버

Also Published As

Publication number Publication date
KR20200089943A (ko) 2020-07-28

Similar Documents

Publication Publication Date Title
JP6188832B2 (ja) データベース・クライアント要求を処理するための方法、コンピュータ・プログラム製品、データ処理システム、およびデータベース・システム
CN111034150B (zh) 选择性地解密ssl/tls通信的方法和装置
US10243928B2 (en) Detection of stale encryption policy by group members
US8595818B2 (en) Systems and methods for decoy routing and covert channel bonding
EP3691217B1 (en) Web traffic logging system and method for detecting web hacking in real time
CN114145004B (zh) 用于使用dns消息以选择性地收集计算机取证数据的系统及方法
US20150007250A1 (en) Interception and Policy Application for Malicious Communications
US6944762B1 (en) System and method for encrypting data messages
CN110198297B (zh) 流量数据监控方法、装置、电子设备及计算机可读介质
Merget et al. Scalable scanning and automatic classification of {TLS} padding oracle vulnerabilities
US10834131B2 (en) Proactive transport layer security identity verification
CN111447232A (zh) 一种网络流量检测方法及装置
US11233777B2 (en) Efficient SSL/TLS proxy
KR102147917B1 (ko) Ssl/tls 서비스 패킷 분류 방법 및 장치
CN115801442A (zh) 一种加密流量的检测方法、安全系统及代理模块
CN113507482A (zh) 数据安全传输方法、安全交易方法、系统、介质和设备
KR20160123416A (ko) 정보 보안 장치 및 이의 정보 보안 방법, 단말기 및 이를 구비한 네트워크 시스템
US11310142B1 (en) Systems and methods for detecting network attacks
KR101881279B1 (ko) 보안 소켓 계층 통신을 이용하는 패킷을 검사하는 방법
KR101881278B1 (ko) 보안 소켓 계층 통신을 이용하는 패킷을 선택적으로 검사하는 방법
CN113645176B (zh) 一种检测伪造流量的方法、装置及电子设备
Patel et al. Security Issues, Attacks and Countermeasures in Layered IoT Ecosystem.
KR20170051043A (ko) 정보유출방지 장치 및 방법
CN113630367B (zh) 一种匿名流量的识别方法、装置及电子设备
EP3923146B1 (en) Communication system, information providing device, program, and information providing method

Legal Events

Date Code Title Description
E701 Decision to grant or registration of patent right
GRNT Written decision to grant