OpenSSL API를 이용한 보안 프로그래밍

보안 통신용 오픈 라이브러리인 OpenSSL용 API를 사용하는 방법을 배운다는 것은 힘든 일입니다. 문서화가 아직 덜 되어있기 때문입니다. 이 글을 통해서 이를 극복해 봅시다. 기본 연결을 설정한 후에, OpenSSL의 BIO 라이브러리를 사용하여 보안/비보안 연결을 구축하는 방법을 배워봅시다. 에러 탐지에 대한 부분도 설명합니다.

OpenSSL API와 관련한 문서는 약간 모호하다. OpenSSL의 사용법에 대한 튜토리얼도 많지 않으므로, 애플리케이션에서 이를 실행하는 것은 초보자에게는 힘든 일이다. 그렇다면, OpenSSL을 사용하여 기본 보안 연결을 어떻게 구현할 것인가? 이 가이드에서 이러한 문제를 풀어보자.

OpenSSL을 구현하는 방법을 배우는 것과 관련된 문제 중 하나는 문서화가 덜 되어있다는 점이다. 불완전한 API 문서는 개발자가 API를 사용할 수 없게 한다. 하지만, OpenSSL은 여전히 존재하고 강력하다. 왜일까?

OpenSSL은 보안 통신용 오픈 라이브러리로 유명하다. Google에서 "SSL library"를 검색하면 OpenSSL이 상위로 리턴된다. Eric Young과 Tim Hudson이 개발한 SSLeay 라이브러리에서 파생하여, 1998년에 시작되었다. 다른 SSL 툴킷으로는 GNU General Public License하에서 배포되는 GNU TLS와, Mozilla Network Security Services (NSS) (참고자료)가 있다.

그렇다면, OpenSSL이 GNU TLS, Mozilla NSS 등 보다 나은 점은 무엇인가? 라이센싱이 한 몫을 한다. (참고자료) 게다가, GNS TLS는 TLS v1.0과 SSL v3.0만 지원한다. 그 이상은 지원하지 않는다.

Mozilla NSS는 Mozilla Public License와 GNU GPL 하에서 배포되고, 개발자가 선택할 수 있다. Mozilla NSS는 OpenSSL보다 크고, 라이브러리를 구현하려면 다른 외부 라이브러리가 필요하다. 하지만 OpenSSL은 독립적이다. OpenSSL과 마찬가지로, 대부분의 NSS API는 문서화가 되어있지 않다. Mozilla NSS는 PKCS #11 지원을 갖고 있는데, 이는 Smart Cards 같은 암호 토큰에 사용된다. OpenSSL은 이러한 지원이 부족하다.

조건

이 글을 충분히 활용하려면,

• C 프로그래밍에 능숙해야 한다.
• 인터넷 통신에 대해 잘 알고 있어야 하고, 인터넷에서 실행되는 애플리케이션을 작성할 수 있어야 한다.

OpenSSL에 대한 완벽한 이해가 전적으로 필요한 것은 아니다. SSL에 대한 간략한 설명은 나중에 제공하겠다. SSL에 대한 상세한 설명은 참고자료 섹션을 참조하라. 암호법에 대해 알고 있어도 도움이 되지만, 필수적인 것은 아니다.

SSL이란 무엇인가?

SSL은 Secure Sockets Layer의 약자이다. 인터넷 상의 보안 통신 표준이고, 데이터 암호화와 프로토콜을 통합한다. 데이터는 컴퓨터를 떠나기 전에 암호화 되고, 목적지에 도착하면 암호가 해독된다. 인증과 암호 알고리즘이 뒤를 받치고 있고, OpenSSL에서는 이 두 가지 모두를 사용할 수 있다.

이론상으로, 암호화된 데이터가 목적지에 도착하기 전에 인터셉트 되거나 도청되면, 그 데이터를 크래킹 할 희망이 없다. 컴퓨터 속도가 빨라지고, 암호 해독법이 진보하면서 SSL에 사용되는 암호 프로토콜을 크래킹 할 기회가 늘어나고 있다.

SSL과 보안 통신은 인터넷 상의 모든 프로토콜(HTTP, POP3, FTP)에 사용될 수 있다. SSL은 텔넷 세션을 보안화 하는데 사용될 수 있다. SSL을 사용하여 연결이 보안화 될 수 있지만, 모든 종류의 연결에 SSL을 사용할 필요는 없다. 연결이 중요한 정보를 전달할 경우에만 사용되어야 한다.

OpenSSL이란 무엇인가?

OpenSSL은 단순한 SSL 이상이다. 메시지 다이제스트, 파일의 암호 및 암호 해독, 디지털 인증, 디지털 서명, 랜덤 넘버를 수행한다. 이 외에도 OpenSSL 라이브러리에는 더 많은 것들이 있지만, 이 글에 다 소개할 수는 없다.

OpenSSL은 단순한 API 이상이고, 명령행 톨이다. 명령행 툴은 API와 같은 일을 할 수 있지만, SSL 서버와 클라이언트를 테스트하는 기능도 있다. 개발자에게 OpenSSL의 기능에 대한 아이디어도 제공한다. OpenSSL 명령행 툴을 사용하는 방법에 대한 내용은 참고자료 섹션을 참조하라.

여러분에게 필요한 것

먼저, 최신 버전의 OpenSSL이 필요하다. 참고자료 섹션에서 여러분이 직접 컴파일 할 최신 소스 코드를 얻거나, 컴파일 하는데 시간을 낭비하고 싶지 않다면 최신 버전의 바이너리 라이브러리를 얻을 수 있다. 안전을 생각한다면, 최신 소스 코드를 다운로드 하여, 여러분이 직접 컴파일 하는 것이 좋다. 바이너리 배포판은 OpenSSL 개발자가 아닌 서드 파티에 의해 컴파일 및 배포된다.

일부 리눅스 배포판에는 바이너리 버전의 OpenSSL이 포함되는데, 이는 라이브러리 사용법을 배울 때 편리하다. 하지만, 최신 버전인지를 확인해야 한다.

RPM (Red Hat, Mandrake)에서 설치된 리눅스 배포판의 경우, 배포판 제작자가 만든 RPM 패키지를 통해 OpenSSL 배포판을 업데이트 한다. 안전을 위해서, 최신 버전의 배포판으로 업데이트 하는 것이 중요하다. 최신 버전의 OpenSSL을 배포판에 사용할 수 없다면, 여러분이 오버라이트 한 파일들은 실행 파일이 아닌 라이브러리들이다. OpenSSL의 FAQ 문서를 참조하라.

OpenSSL은 모든 플랫폼에서 공식적으로 지원이 되는 것은 아니다. 크로스 플랫폼 호환성을 위한 노력이 진행 중이지만, OpenSSL은 컴퓨터 또는 OS에서 작동하지 않을 수 있다. 지원되는 플랫폼을 알아보려면 OpenSSL 웹 사이트(참고자료)를 참조하라.

OpenSSL을 사용하여 인증 요청 및 디지털 인증을 만든다면, 설정 파일이 생성되어야 한다. openssl.cnf라고 하는 템플릿 파일이 OpenSSL 패키지의 apps 폴더에서 사용할 수 있다. 이 글에서는 설명하지 않겠다. 하지만, 이 템플릿 파일은 주석이 잘 달려있고 인터넷 검색을 통해 많은 튜토리얼을 찾을 수 있다.

헤더와 초기화

본 튜토리얼에서 사용될 헤더는 단 세 가지이다. (ssl.h, bio.h, err.h) 이 모든 것이 openssl 하위 디렉토리에 있고, 세 개 모두 프로젝트를 개발하는데 필요한 것들이다. OpenSSL 라이브러리를 초기화 하는데 필요한 단 세 라인들이 있다. Listing 1에 모두 리스팅 되어 있다. 기타 헤더 및 초기화 함수들은 다른 기능들에 필요하다.

/* OpenSSL headers */

#include "openssl/bio.h"
#include "openssl/ssl.h"
#include "openssl/err.h"

/* Initializing OpenSSL */

SSL_load_error_strings();
ERR_load_BIO_strings();
OpenSSL_add_all_algorithms();

비보안 연결 구축하기

OpenSSL은 BIO라고 하는 추상화 라이브러리를 사용하여 파일과 소켓을 포함한 다양한 종류의 통신을 보안 또는 비보안 방식으로 처리한다. 또한 UU 또는 Base64 코딩용 필터로서도 설정될 수 있다.

BIO 라이브러리는 이 글에서 설명하기에는 약간 복잡하기 때문에, 필요한 부분만 설명하기로 하겠다. 먼저, 표준 소켓 연결을 설정하는 방법을 설명하겠다. BSD 소켓 라이브러리를 사용하는 것 보다 적은 라인이 들어간다.

보안이든 비보안이든 연결을 구축하기 전에, BIO 객체용 포인터가 생성되어야 한다. 이는 표준 C의 파일 스트림용 FILE 포인터와 비슷하다.

BIO * bio;

연결하기

새로운 연결을 만들려면 BIO_new_connect를 호출해야 한다. 같은 호출에 호스트네임과 포트를 설정해야 한다. (Listing 3) 이것으로 연결을 시도할 것이다. 또한 이것을 두 개의 개별 호출로 나눌 수 있다. BIO_new_connect는 연결을 만들고 호스트네임을 설정하고, BIO_set_conn_port (또는 BIO_set_conn_int_port)는 포트 넘버를 설정한다.

일단 호스트네임과 포트 넘버가 BIO에 설정되면, 연결을 시도할 것이다. 방법은 없다. BIO 객체를 생성하는데 문제가 있다면, 포인터는 NULL이 될 것이다. BIO_do_connect로 호출하여 연결이 성공했는지를 확인하게 될 것이다.

bio = BIO_new_connect("hostname:port");
if(bio == NULL)
{
    /* Handle the failure */
}

if(BIO_do_connect(bio) <= 0)
{
    /* Handle failed connection */
}

첫 번째 라인은 지정된 호스트네임과 포트로 새로운 BIO 객체를 생성한다. 예를 들어, www.ibm.com에서 포트 80으로 연결하려면, 스트링은 www.ibm.com:80이 될 것이다. BIO_do_connect를 호출하여 연결이 성공했는지 여부를 검사한다. 에러 시 0 또는 -1을 리턴한다.

서버와 통신하기

소켓이든 파일이든 상관없이, BIO 객체를 읽고 쓰는 것은 두 개의 함수, BIO_read와 BIO_write를 사용하여 수행된다. 간단하지 않은가?

BIO_read는 서버에서 특정 숫자를 읽는다. 바이트가 읽는 숫자, 또는 0 또는-1을 리턴한다. Blocking connection에서, 0이 리턴되었다는 것은 연결이 닫혔다는 것을 의미하고, -1은 에러가 발생했다는 것을 의미한다. Non-blocking connection에서, 0의 리턴은 어떤 데이터도 사용할 수 없음을 나타내고, -1은 에러를 나타낸다. 에러가 복구 가능한 것인지 여부를 파악하려면 BIO_should_retry를 호출한다.

int x = BIO_read(bio, buf, len);
if(x == 0)
{
    /* Handle closed connection */
}
else if(x < 0)
{
   if(! BIO_should_retry(bio))
    {
        /* Handle failed read here */
    }

    /* Do something to handle the retry */
}

BIO_write는 소켓에 바이트를 작성한다. 실제로 작성된 바이트 숫자, 또는 0 또는 -1을 리턴한다. BIO_read와 마찬가지로, 0 또는 -1이 반드시 에러를 나타내는 것은 아니다. BIO_should_retry는 이를 파악하는 방법이다. 쓰기 연산이 재시도 되면, 전과 똑 같은 매개변수가 있어야 한다.

if(BIO_write(bio, buf, len) <= 0)
{
    if(! BIO_should_retry(bio))
    {
        /* Handle failed write here */
    }

    /* Do something to handle the retry */
}

연결 닫기

연결을 닫는 것도 단순하다. 두 가지 방법(BIO_reset 또는 BIO_free_all) 중, 하나를 사용하여 연결을 닫을 수 있다. 객체를 재사용 하려면, 첫 번째 것을 사용한다. 재사용 하지 않으려면 두 번째를 사용한다.

BIO_reset은 연결을 닫고 BIO 객체의 내부 상태를 리셋하여 연결이 재사용 될 수 있도록 한다. 애플리케이션 전체에 같은 객체를 사용하고자 한다면 이것이 유용하다. 이것은 값을 리턴하지 않는다.

BIO_free_all은 명칭 그대로이다. 내부 구조를 풀고 모든 관련 메모리들을 릴리스 한다. 여기에는 제휴 소켓을 닫는 것도 포함된다. BIO가 클래스에 삽입되면, 이는 클래스의 디스트럭터에 사용된다.

/* To reuse the connection, use this line */

BIO_reset(bio);

/* To free it from memory, use this line */

BIO_free_all(bio);

보안 연결 설정하기

이제 보안 연결을 설정하는데 필요한 것을 알아보자. 달라진 유일한 부분은 연결 설정 및 연결을 만드는 것이다. 다른 모든 것은 똑같다.

보안 연결은 연결이 구축된 후에 핸드쉐이크(handshake)를 필요로 한다. 헨드쉐이크 동안, 서버는 인증을 클라이언트에 보내는데, 클라이언트는 트러스트 인증에 준하여 이를 확인한다. 또한, 인증을 검사하여 만기가 되었는지를 확인한다. 인증이 신뢰를 받는 것인지를 확인하려면 트러스트 인증 스토어가 연결을 구축하기 전에 로딩되어야 한다.

클라이언트는 서버가 인증을 요청할 경우에만 서버로 인증을 보낸다. 이것은 클라이언트 인증으로 알려져 있다. 인증을 사용하여, 암호 매개변수들이 클라이언트와 서버 사이에 전달되어 보안 연결을 구축한다. 핸드쉐이크가 연결이 구축된 후에 수행되더라도, 클라이언트나 서버는 어떤 지점에서라도 새로운 핸드쉐이크를 요청할 수 있다.

핸드쉐이크와 보안 연결을 설정하는 다른 측면들은 Netscape 기술자료와 RFC 2246에 설명되어 있다. (참고자료)

보안 연결 설정하기

보안 연결을 설정하기 위해 서는 두 줄 이상의 코드가 필요하다. 또 다른 포인터가 SSL_CTX 유형에 필요하다. 이것은 SSL 정보를 포함하고 있는 구조이다. BIO 라이브러리를 통해 SSL 연결을 구축하는데도 사용된다. 이 구조는 SSL 메소드 함수, SSLv23_client_method와 SSL_CTX_new를 호출함으로써 생성된다.

또 다른 포인터 유형의 SSL 역시 SSL 연결 구조를 보유하는데 필요하다. SSL 포인터는 나중에 사용되어 연결 정보를 검사하거나 추가 SSL 매개변수를 설정한다.

SSL_CTX * ctx = SSL_CTX_new(SSLv23_client_method());
SSL * ssl;

트러스트 인증 스토어 로딩하기

콘텍스트 구조가 생성된 후에, 트러스트 인증 스토어가 로딩되어야 한다. 이는 피어(peer) 인증의 확인이 성공하기 위해 절대적으로 필요하다. 인증서가 입증을 받지 못하면, OpenSSL은 그 인증서를 무효한 것으로 플래그를 단다. (하지만, 연결은 지속된다.)

OpenSSL에는 트러스트 인증서 세트가 포함되어 있다. 소스 트리의 certs 디렉토리에 있다. 각 인증서는 개별 파일이고, 각각은 개별적으로 로딩되어야 한다. certs 밑에는 만기된 인증서가 있는 하위 폴더도 있다. 이것을 로딩하면 에러가 발생한다.

원한다면 각 파일을 개별적으로 로딩할 수 있지만, 단순함을 위해 최신 OpenSSL 배포판의 트러스트 인증서는 "TrustStore.pem"이라고 하는 파일의 소스 코드 압축 파일에 포함되어 있다. 특정 프로젝트에 사용될 트러스트 스토어 파일이 있다면, Listing 8의 "TrustStore.pem"을 여러분의 파일로 대체한다. (또는 이 두 가지 모두를 개별 함수 호출로 로딩한다.)

SSL_CTX_load_verify_locations를 호출하여 트러스트 스토어 파일을 로딩한다. 세 개의 매개변수가 필요하다: 콘텍스트 포인터, 트러스트 스토어 파일의 경로와 파일 이름, 인증서 디렉토리로 가는 경로. 트러스트 스토어 파일 중 하나 또는 인증서 디렉토리가 지정되어야 한다. 성공 시 1이 리턴되고, 문제가 있다면 0을 리턴한다.

if(! SSL_CTX_load_verify_locations(ctx, "/path/to/TrustStore.pem", NULL))
{
    /* Handle failed load here */
}

트러스트 스토어를 저장 할 디렉토리를 사용한다면, 이 파일은 특정 방식으로 이름을 정해야 한다. OpenSSL 문서에서는 이를 상세히 설명하고 있지만, c_rehash라고 하는 OpenSSL에 포함된 툴이 있는데, SSL_CTX_load_verify_locations에 대한 경로 매개변수로서 사용할 수 있도록 폴더를 준비시킨다.

/* Use this at the command line */

c_rehash /path/to/certfolder

/* Then call this from within the application */

if(! SSL_CTX_load_verify_locations(ctx, NULL, "/path/to/certfolder"))
{
    /* Handle error here */
}

여러분이 필요로 하는 확인 인증서들 모두를 지정하는데 필요한 파일이나 폴더의 이름을 정할 수 있다. 동시에 하나의 파일과 폴더를 지정할 수도 있다.

연결 생성하기

BIO 객체는 BIO_new_ssl_connect를 사용하여 생성된다. 유일한 매개변수로서 SSL 콘텍스트에 대한 포인터를 취한다. SSL 구조에 대한 포인터는 검색되어야 한다. 이 글에서, 이 포인터는 SSL_set_mode 함수로만 사용된다. 이 함수는 SSL_MODE_AUTO_RETRY 플래그를 설정하는데 사용된다. 이 옵션을 설정한 상태에서, 서버가 갑자기 새로운 핸드쉐이크를 원하면, OpenSSL은 이를 뒤에서 핸들한다. 이 옵션이 없이, 읽기 또는 쓰기 연산은 서버가 새로운 핸드쉐이크를 원할 경우 에러를 리턴하면서, 프로세스에서 재시도 플래그를 설정한다.

bio = BIO_new_ssl_connect(ctx);
BIO_get_ssl(bio, & ssl);
SSL_set_mode(ssl, SSL_MODE_AUTO_RETRY);

SSL 콘텍스트 구조가 설정된 상태에서 연결이 생성될 수 있다. 호스트네임은 BIO_set_conn_hostname 함수를 사용하여 설정된다. 호스트네임과 포트는 위와 같은 포맷으로 지정된다. 이 함수는 또한 호스트로 연결을 개방한다. BIO_do_connect로의 호출 역시 수행되어 연결이 성공적으로 열렸는지를 확인한다. 이와 똑 같은 호출이 핸드쉐이크를 수행하여 보안 통신을 설정한다.

/* Attempt to connect */

BIO_set_conn_hostname(bio, "hostname:port");

/* Verify the connection opened and perform the handshake */

if(BIO_do_connect(bio) <= 0)
{
    /* Handle failed connection */
}

연결이 이루어지면, 이것이 유효한지 여부를 확인하기 위해 인증서가 검사된다. 실제로는 OpenSSL이 이를 수행한다. 인증서에 치명적인 문제가 있다면(이를 테면, 해시 값이 무효한 경우), 연결이 이루어지지 않는다. 그러나, 그렇게 중요하지 않은 문제가 있다면(만기 또는 무효) 연결이 여전히 사용될 수 있다.

OpenSSL에서 인증서가 제대로 되었는지를 확인하려면, 유일한 매개변수로서 SSL 매개변수로 SSL_get_verify_result를 호출한다. OpenSSL의 내부로 전달된 인증서가 확인되면(트러스트 체크 포함) X509_V_OK가 리턴된다. 잘못되었다면, 명령행 툴용 verify 옵션 밑에 문서화 된 에러 코드를 리턴한다.

실패했다고 해서 연결이 사용될 수 없는 것은 아니다. 연결이 사용되는지의 여부는 확인 결과와 보안 고려 사항에 의존한다. 예를 들어, 실패한 트러스트 확인은 트러스트 인증서를 사용할 수 없다는 것을 의미한다. 더 강화된 보안으로 연결은 지속된다.

if(SSL_get_verify_result(ssl) != X509_V_OK)
{
    /* Handle the failed verification */
}

이것이 필요한 모든 것이다. 서버와의 통신은 BIO_read와 BIO_write을 사용하여 이루어진다. 연결을 닫을 때에는 BIO_free_all 또는 BIO_reset을 호출하는데, 이는 BIO가 재사용되는지 여부에 따라 다르다.

애플리케이션이 끝나기 전 특정 지점에서, SSL 콘텍스트 구조가 릴리스 되어야 한다. 구조를 해제하려면 SSL_CTX_free를 호출한다.

SSL_CTX_free(ctx);

에러 탐지

OpenSSL은 에러도 던진다. 이것은 무엇을 의미하는가? 에러 코드를 먼저 받아야 한다. ERR_get_error가 바로 그것이다. 그 코드를 에러 스트링으로 변환하는데, 이는 SSL_load_error_strings 또는 ERR_load_BIO_strings에 의해 메모리로 영구 로딩되는 스트링에 대한 포인터이다. 이는 중첩 호출에서 수행될 수 있다.

표 1은 에러 스택에서 에러를 가져오는 방법을 정리한 것이다. Listing 14는 텍스트 스트링에서 마지막 에러 메시지를 출력하는 방법을 보여주고 있다.

표 1. 스택에서 에러 가져오기

printf("Error: %s\n", ERR_reason_error_string(ERR_get_error()));

이 라이브러리는 사전 포맷된 에러 스트링도 제공한다. ERR_error_string을 호출하면 된다. 에러 코드와 매개변수로서 사전 할당된 버퍼를 취한다. 이 버퍼는 256 바이트여야 한다. 이 매개변수가 NULL이면, OpenSSL은 256 바이트인 정적 버퍼에 스트링을 작성하고 그 버퍼에 대한 포인터를 리턴한다. 그렇지 않으면, 여러분이 제공했던 포인터를 리턴한다. 정적 버퍼 옵션을 선택하면, 그 버퍼는 ERR_error_string에 대한 호출로 오버라이트 될 것이다.

printf("%s\n", ERR_error_string(ERR_get_error(), NULL));

전체 에러 큐를 파일 또는 BIO로 덤핑할 수 있다. ERR_print_errors 또는 ERR_print_errors_fp를 사용한다. 이 큐는 가독성 포맷으로 덤핑된다. 첫 번째 것은 큐를 BIO로 보내고, 두 번째 것은 큐를 FILE로 보낸다. 이 스트링은 다음과 같은 방식으로 포맷된다. (OpenSSL 문서 발췌)

[pid]:error:[error code]:[library name]:[function name]:[reason string]:[file name]:[line]:[optional text message]

여기에서 [pid]는 프로세스 ID, [error code]는 8 자리수로 된 16진수 코드, [file name]은 OpenSSL 라이브러리에 있는 소스 코드 파일,[line]은 소스 파일의 라인 넘버이다.

ERR_print_errors_fp(FILE *);
ERR_print_errors(BIO *);

시작하기

OpenSSL을 사용하여 기본 연결을 생성하는 것은 어렵지 않지만, 이것이 어떻게 작동하는지를 파악하기 위해 문서를 참조하는 것이 까다롭다. 이 글에서는 기초적인 부분을 설명했지만, OpenSSL의 다양한 측면 모두를 설명하지 못했다. 프로젝트에서 SSL 기능을 적절하게 수행하는데 필요한 고급 설정 부분도 설명하지 못했다.

이 글에는 두 개의 샘플이 포함되어 있다. 하나는 http://www.verisign.com/에 대한 비보안 연결이고, 다른 하나는 https://www.verisign.com/에 대한 보안 SSL 연결이다. 두 개 모두 서버로 연결된다. 보안 확인이 없고, 라이브러리 내 모든 설정들은 기본 사항이다. 교육 용도로 쓰기에 적합하다.

이 소스 코드는 지원 시스템에서는 컴파일 되지만, 최신 버전의 OpenSSL을 사용해야 한다. 이 글을 쓰고 있는 현재, 최신 버전은 0.9.7d이다.

Secure Sockets Layer (SSL) 세션 중에 핸드쉐이크(handshake)를 보안화 하는 것은 중요합니다. 이 연결에 개입된 모든 보안들이 핸드쉐이크 내부에서 설정되기 때문입니다. 믿을 수 있는 소스인 것처럼 가장하여 침입하는 man in the middle (MITM) 공격에서 SSL 핸드쉐이크를 보안화 하는 방법을 배워봅시다. 디지털 인증서 개념과 OpenSSL API가 이들을 다루는 방법도 설명합니다.

얼마 전까지만 해도, 안전한 핸드쉐이크는 두 당사자들간 비즈니스가 건전한 토대에서 진행되고 있다는 표시었다. 결국, 핸드쉐이크는 잠재적인 파트너를 평가하는 기회였다. 안전하고 믿을 수 있는 핸드쉐이크는 두 트랜잭션 당사자들이 서로에게 유익이 되는 무엇인가를 수행하고 있다는 것을 의미했다. 안전하지 않은 핸드쉐이크는 한 쪽만 이 트랜잭션을 이해하고 있다는 것을 의미했다.

핸드쉐이크는 온라인 트랜잭션에서도 똑같이 적용된다.

developerWorks의 이전 기술자료인, "OpenSSL API를 이용한 보안 프로그래밍, Part 1: API의 개요에서는 OpenSSL을 사용한 기본적이고 단순한 보안 연결을 생성하는 방법을 설명했다. 하지만, 기본 설정에 포함된 기초적인 부분만 설명했다. 커스터마이징 방법에 대해서는 설명하지 못했다. 이전 글에서는 디지털 인증서의 개념을 설명했고, OpenSSL의 인증서 확인이 성공 또는 실패했는지를 확인하는 방법을 설명했다.

이 글에서는 OpenSSL에 대해 좀더 자세히 살펴볼 예정이다. man in the middle (MITM) 공격에 대비하도록 핸드쉐이크를 보안화 하는 방법을 설명할 것이다.

디지털 인증서

이 글 후반에, 디지털 인증서를 검색하고 확인하는 방법을 설명할 것이므로, 여기에서는 디지털 인증서가 무엇이고 어떻게 작동하는지에 대해서 간략히 설명하겠다. 여러분이 데이터 암호화와 SSL에 대해 익숙하다면, 이 섹션을 읽지 않아도 좋다. 암호와 SSL 실행에 대해 배우고 싶다면 참고자료 섹션에 소개된 기술자료와 튜토리얼을 참조하라.

간단히 말해서, 디지털 인증서는 비대칭적으로 암호화 된 키(asymmetric cryptography key)이다. 디지털 인증서와 관련한 현재의 표준은 이 키와 함께 정보를 포함시켰다. 전형적인 디지털 인증서에는 소유자의 이름(인증서가 웹 서버에서 사용될 경우 전체 도메인 이름)과 연락처 정보가 포함된다. 유효 데이터 범위와 보안 서명이 있어서 그 인증서가 오염되었는지 여부를 확인할 수 있다.

디지털 인증서는 명령어 OpenSSL 툴 또는 이와 같은 목적에 맞게 만들어진 기타 툴을 사용하여 쉽게 생성될 수 있다. 누군가에 의해 생성된 디지털 인증서는 신뢰도에 문제가 생길 것이다. 디지털 인증서는 단순한 암호 키 이상이다. 이것은 온라인 증명서이다. 인증서는 여러분과 통신을 시도하는 누구든 확인한다. 신뢰를 보여주려면 디지털 인증서는 Certificate Authority (CA)에 의해 서명이 되어야 한다.

인증서 기구는 디지털 보안 세계에서 신임을 받는 서드 파티로서 작동한다. 온라인에서 정체를 확인하는 것은 어렵기 때문에, 인증서 기구가 그 일을 떠맡는다. 인증서를 구매하거나 인증서 서명에 지불을 하는 사람의 신원을 확인한다. 인증서를 신임하려면, 사용자는 인증서 기구를 신임해야 한다. 사용자는 CA의 트러스트 인증서를 처리 및 사용함으로써 인증서 기구의 신뢰성에 서명한다. Verisign과 Thawte가 잘 알려진 인증서 기구이다.

인증서의 보안이 노출되면, 취소된다. 다시 말해서 무효한 것으로 선언된다. 인증서가 무효한 것으로 선언되면, CA는 그 인증서 카피를 소유하고 있는 모든 사람들에게 공지를 보내야 한다. 대신, CA는 Certificate Revocation List (CRL)를 발행한다. 디지털 인증서를 사용하는 브라우저와 기타 보안 애플리케이션들은 그 인증서가 소유자 또는 CA에 의해 취소되었는지를 확인할 수 있다.

인증서 철회는 OCSP 프로토콜을 사용하여 검사될 수 있다. OCSP는 Online Certificate Status Protocol을 뜻하는 말로서, RFC 2560에서 정의된다. OpenSSL은 OCSP와 CRL 기능 모두를 갖고 있지만, 그 기능까지는 이 글에서는 설명하지 않겠다. 디지털 인증서에 대한 현재 표준은 X.509이다. (RFC 3280에서 정의됨)

비즈니스를 시작하는 핸드쉐이크

이 글은 핸드쉐이크 하는 사이에 서버의 디지털 인증서를 처리하는 것에 초점을 맞추므로 핸드쉐이크가 어떻게 작동하는지를 상세히 살펴보고자 한다. 여러분이 SSL 프로시저에 익숙하다면, 이 섹션은 무시해도 좋다.

연결에서 개방(opening) 핸드쉐이크는 서버에 "Hello"라고 말하는 클라이언트로 시작된다. Hello 메시지에는 클라이언트의 보안 매개변수들이 포함되어 있다.

• SSL 버전 넘버
• 무작위로 생성된 데이터
• 암호 설정
• 통신에 필요한 기타 사항

서버는 클라이언트가 제공한 것과 같은 유형의 정보인 서버의 보안 매개변수들을 포함하고 있는 고유의 Hello 메시지에 응답한다. 바로 이때 서버도 디지털 인증서를 보낸다. 클라이언트 권한이 연결에 사용되면 서버는 클라이언트의 인증서에 대한 요청을 보낸다.

서버의 Hello 메시지를 받으면, 디지털 인증서가 확인된다. 인증서의 다양한 매개변수들을 확인하여 인증서가 원래 그대로 보존되었는지를 확인하고, 유효 기간 내에 인증서가 사용되고 있는지를 확인한다.

여기에서 수행되어야 하는 한 가지 단계는 연결에 사용되는 호스트 네임과 비교하여 인증서 상의 이름을 검사하는 것이다. 이는 SSL 표준의 일부는 아니지만, man in the middle attack (MITM)을 방지하기 위해서 권장된다. 이 단계는 인증서가 여러분이 생각하고 있는 엔터티에서 온 것임을 확인한다. 이 두 개가 이 지점에서 매치되지 않으면, 인증서는 무효한 것이 아닌, 의심의 대상이 된다.

클라이언트와 서버 간 공유되었던 랜덤 데이터는 서버와 클라이언트에게만 알려진 공유 비밀 값으로서 이 세션에만 사용되는 premaster secret을 생성하는데 사용된다. 이 비밀 값은 서버의 디지털 인증서로 암호화 되고 확인을 위해 서버로 보내진다.

서버가 클라이언트 인증을 요청하면, 클라이언트는 핸드쉐이크 동안 무작위로 생성되고 서버와 클라이언트에게만 알려진 데이터의 단방향 해시(hash)를 생성한다. 클라이언트는 클라이언트의 개인 키(private key)를 사용하여 해시에 서명을 하고 서명된 데이터와 디지털 인증서를 서버로 보낸다. 서버는 그 정보를 사용하여 클라이언트를 인증한다.

인증이 성공하면, 서버와 클라이언트 모두 공유된 랜덤 데이터를 알고리즘을 통해 실행하여 master secret을 생성한다. master secret에서, 클라이언트와 서버는 세션 키(session keys)를 생성한다. 이것은 선택된 시메트릭 암호 안에 있는 대칭 키로서 세션 데이터를 암호화 하는데 사용된다.

클라이언트는 종료되었다는 메시지를 서버로 보냄으로써 핸드쉐이크를 종료한다. 이것은 서버에 의해 확인되어야 하는 암호화 된 단방향 해시 값 세트이다. 서버는 비슷한 메시지를 클라이언트로 보낸다. 클라이언트와 서버는 핸드쉐이크를 종료하고 통신을 시작하기 전에 데이터가 정확한지를 확인한다.

Man in the middle

이것은 아이들이 하는 게임이지만, public key infrastructures (PKI)에서도 발생할 수 있는 심각한 공격이다. 디지털 인증서에 대해 이야기 할 때, SSL 연결 뒤의 보안 매개변수와 관계 없이 man in the middle 공격은 이러한 사전 주의 사항들을 실행하기 때문에 반드시 고려해야 한다.

Casey와 Samantha가 SSL을 사용하여 통신한다고 생각해 보자. 삼자인 Isabel은 연결 시도를 가로채서 이들 간 프록시로서 역할을 한다. Isabel이 SSL 연결이 설정되었다는 것을 알면, Samantha에게는 Casey인 것처럼, Casey에게는 Samantha인 것처럼 가장한다. Isabel은 중간에서 양 측의 대화를 가로챈다. 대화에 계좌 번호와 개인 정보가 포함되어 있다면 Isabel은 아이디 도용도 할 수 있다.

이 부분에서 인증서에 대한 트러스트 체인과 공통 이름들이 이를 방지할 수 있다. 핸드쉐이크 동안, 인증서가 교환된다. 인증서의 유효성이 분석될 때, 트러스트 서명도 검사된다. 서버 인증서 상의 공통 이름이 나머지 인증서와 함께 검사되면 공격은 실패하지 않겠는가? 전적으로 그런 것은 아니다.

Isabel이 Samantha의 이름을 가진 인증서를 갖고 있다고 가정해 보자. 이것은 또한 Casey의 트러스트 모델 내에서 CA에 의해 서명도 되었다. 여기에서 MITM 공격은 공통 이름을 검사한다고 해서 실패되지 않는다. 이 인증서와 트러스트는 유효하고, 이름이 체크된다. 이제 큰 문제가 생긴 것이다.

하지만, 인증서 기구를 보면 이것은 별개의 문제이다. 대부분의 인증서 기구는 개인의 이름을 가진 디지털 인증서를 발행하기 전에 개인의 신분을 확인한다. 이것 때문에, Isabel이 잘 알려진 매우 명성이 높은 인증서 기구에서 Samantha의 이름을 가진 디지털 인증서를 얻을 가능성은 희박하다.

CA를 사용하면 이러한 보안 문제들을 보다 쉽게 해결할 수 있다. 예를 들어, CA와 Isabel이 같은 컴퍼니에 적용한다면 (다시 말해서, "inside job"). 이렇게 되면, 거의 모든 사람들의 이름을 가진 임의의 인증서를 생성할 수 있는 CA의 작업 공간 내에서 서명 키가 누군가에 의해서 도난 당할 수 있다. 인증서의 개인적인 부분은 서명을 생성하는데 사용되는 반면, 패스워드는 소셜 엔지니어링 또는 기타 비슷한 기술을 사용하여 도난 당할 수 있다.

MITM 공격은 프록시 서버(proxy servers)를 논할 때 특히 중요하다. 보안 연결은 프록시 서버를 통해 의도한 목적지로 "터널링" 되어야 하므로, 악의적인 프록시 서버들은 어떤 대화라도 쉽게 엿들을 수 있다. 악의적인 프록시는 연결이 실제로 이루어 지지 않을 때도 연결이 된 것처럼 보이게 할 수 있다. 인터넷을 통해 "익명 프록시(anonymous proxy)" 서비스를 사용할 때 특히 주의를 기울여야 한다. 그들의 시스템을 통해 사용자 이름과 패스워드를 보낸다고 해서 충분히 신뢰할 수 있겠는가?

이러한 공격은 컴퓨터 및 디지털 보안의 세계에서만 발생하는 것이 아니다. 한 여성이 MITM 공격과 비슷한 기술을 사용하여 가족들에게서 많은 돈을 훔쳤다. (참고자료).

OpenSSL과 디지털 인증서

OpenSSL은 디지털 인증서 전용의 내부 라이브러리를 갖고 있다. 여러분이 OpenSSL의 소스 코드를 사용하고 있다고 가정하고, 이 소스 코드는 crypto/x509와 crypto/x509v3 디렉토리 밑에 있다. 이 소스 코드는 디지털 인증서를 다루는 여러 구조들을 정의한다. 표 1을 보자.

표 1. X.509 인증서와 관련한 OpenSSL 구조

이는 구조의 일부일 뿐이다. OpenSSL 내에서 사용되는 대부분의 X.509 구조들은 애플리케이션에서는 사용되지 않는다. 위에 열거된 구조들 중에서, 이 글에 사용되는 두 가지는 X509와 X509_NAME이다.

디지털 인증서를 다루고 처리하는데 사용되는 다양한 함수들이 구조에 존재한다. 이 함수들은 이 함수들이 적용되는 구조의 이름을 따른다. 예를 들어, X509_NAME으로 시작되는 이름을 가진 함수는 X509_NAME 구조에 적용된다. 이러한 함수들은 필요한 만큼 사용될 것이다.

고유의 트러스트 인증서 제공하기

인증서의 신뢰성을 검사하기 전에 기본적인 신용 인증서 세트가 보안 연결을 위해 OpenSSL을 설정하는 동안 생성된 SSL_CTX 객체에 제공되어야 한다. 이것은 여러 가지 방식으로 제공될 수 있지만, 가장 쉬운 방법은 인증서를 PEM 파일 인증서를 사용하고 SSL_CTX_load_verify_locations(ctx, file, path);를 사용하여 OpenSSL에 로딩한다. file은 PEM 포맷으로 한 개 이상의 인증서를 포함하고 있는 파일에 대한 경로이다. path는 PEM 포맷으로 된 한 개 이상의 파일들에 대한 디렉토리 경로이지만, 파일 이름은 특정 포맷이어야 한다. 하나의 PEM 파일로 트러스트 인증서를 갖는 것이 더 쉬우며, 경로 인자를 NULL로서 유지한다: SSL_CTX_load_verify_locations(ctx, "/path/to/trusted.pem", NULL);.

하나의 폴더에 개별 파일일 때 트러스트 인증서를 추가 및 업데이트 하는 것이 더 쉽지만, 트러스트 인증서를 그렇게 자주 업데이트 하지는 않는다.

인증서 확인하기

통신이 지속되거나 인증서가 검색되기 전에, SSL_get_verify_result()를 사용하여 OpenSSL의 내부 인증서 확인의 결과를 확인한다. SSL_get_verify_result()가 X509_V_OK 이외의 코드를 리턴한다면, 인증서가 무효하다는 것을 의미하는 것일까? 이는 리턴 코드에 따라 다르다.

일반적으로 리턴 코드가 X509_V_OK가 아니라면, 이 인증서와 관련하여 인증서 또는 보안에 문제가 있는 것이다. 한 가지만 명심하라. 인증서를 확인할 때 OpenSSL이 수행하지 않는 몇 가지 보안 체크가 있다. 인증서의 공용 이름을 체크 및 확인하는 취소도 여기에 포함된다.

SSL_get_verify_result()에 대한 리턴 코드는 apps 밑에 있는 verify에 문서화 되어 있다. 일부 코드들은 사용되지 않는 것으로 리스팅 되는데, 이들은 절대로 리턴되지 않음을 의미한다. 일부 코드들은 매우 중요하고, 일부는 그렇지 않다. 예를 들어, 트러스트 인증서 스토어가 로딩되지 않았기 때문에 트러스트가 확인될 수 없다면, 통신의 지속 여부는 개발자에 달려있다.

확인의 결과가 어떻든지 간에, 잠재적으로 불안한 보안 매개변수들로 지속하는 것은 개발자의 몫이다. 인증서가 매우 불안하면 에러 리턴 코드들이 주어진다.

피어(peer) 인증서 검색하기

인증서를 사용자에게 디스플레이 하거나 호스트 네임 또는 인증서 기구에 비교하여 이를 확인해야 한다면 피어(peer) 인증서를 가져와야 한다. 테스트 결과를 확인한 후에 인증서를 가져오려면, SSL_get_peer_certificate()를 호출한다. 이것은 X509 포인터를 인증서에 리턴하고, 어떤 인증서도 제공되지 않을 경우 NULL을 리턴한다. (Listing 1).

                
X509 * peerCertificate;


if(SSL_get_verify_result(ssl) == X509_V_OK)
    peerCertificate = SSL_get_peer_certificate(ssl);
else
{
    /* Handle verification error here */
}

피어 인증서 확인하기

핸드쉐이크에서 제공된 서버의 인증서는 서버의 호스트 네임과 매치하는 것에 대한 이름을 가져야 한다. 그렇지 않다면, 인증서는 의심스러운 것으로 표시되어야 한다. 내부 확인 절차는 이미 트러스트와 종료에 대해 인증서를 검사한다. 인증서가 종료되었거나 믿을 수 없는 서명을 포함하고 있다면 무효로 표시된다. 이것은 SSL 표준의 일부가 아니므로 OpenSSL은 호스트 네임에 대해 인증서의 이름을 검사하지 않는다.

인증서의 "이름"은 실제로 인증서 상의 Common Name 필드이다. 이 필드는 인증서에서 가져온 것이어야 하며 호스트 네임에 비교하여 확인되어야 한다. 이 두 가지가 매치되지 않으면, 인증서는 무효가 아닌 의심 상태가 된다. Yahoo! 같은 일부 기업들은 다양한 호스트에 같은 인증서를 사용한다. 그 인증서에 대한 Common Name이 단 한 개의 호스트를 위한 것인데도 말이다. 인증서가 같은 회사에서 온 것인지를 확인하기 위해 보다 심도 깊은 체크가 수행되지만, 이는 프로젝트의 보안 필요에 따라 수행한다.

인증서에서 공통 이름을 가져오는 단계는 다음과 같다.

• 인증서 구조에서 X509_NAME 객체를 가져온다.
• X509_NAME 객체에서 이름을 가져온다.

X509_get_subject_name()을 사용하여 인증서에서 X509_NAME 구조를 가져온다. 이것은 X509_NAME 객체에 대한 포인터를 리턴한다. 여기서부터 X509_NAME_get_text_by_NID()를 사용하여 공통 이름을 스트링으로 가져온다. (Listing 2).

char commonName [512]; X509_NAME * name = X509_get_subject_name(peerCertificate); X509_NAME_get_text_by_NID(name, NID_commonName, commonName, 512); /* More in-depth checks of the common name can be used if necessary */ if(stricmp(commonName, hostname) != 0) { /* Handle a suspect certificate here */ 보안 서버 애플리케이션이 없이는, 보안 클라이언트 애플리케이션도 존재하지 않습니다. OpenSSL을 사용하여 보안 서버 애플리케이션들을 생성할 수 있고, 문서화가 완전하지 않아도 어렵지는 않습니다. 본 3개 시리즈의 Part 1에서 설명한 개념을 기반으로 보안 서버 애플리케이션을 구현하는 방법을 배워봅시다. 본 시리즈의 두 Part에서는 OpenSSL을 이용한 클라이언트 측 애플리케이션 구현에 대해 설명했다. Part 1에서는 OpenSSL을 사용한 기본 보안 클라이언트를 구현하는 방법을 설명했고, Part 2에서는 디지털 인증서에 대해 자세히 설명했다. 본 기술자료에 대해 이메일과 긍정적인 피드백을 받고 나서, 다음에는 어떤 논의를 이어가야 할지 명확해 졌다. 서버는 네트워크와 인터넷에 파일과 장치와 같은 리소스로의 액세스를 제공한다. 가끔씩, 이러한 서비스들을 보안 채널을 통해서 제공해야 할 때도 있다. OpenSSL을 사용하여 보안 및 오픈 채널을 사용하여 서비스를 만들 수 있다. OpenSSL을 이용하여 기본적인 서버 애플리케이션을 생성하는 것은 기본적인 클라이언트 애플리케이션을 구현하는 것과 본질적으로 거의 같다. 차이점은 비교적 적다. 분명한 것은 서버는 아웃고잉 연결을 생성하는 대신 인커밍 연결을 수락하도록 설정되어야 한다는 점이다. 본 시리즈 Part 2의 디지털 인증서에 대한 글을 기억해 보면 알겠지만, 서버는 핸드쉐이크 동안 사용되는 보안 인증서도 제공해야 한다. 기다리기 서버들은 인커밍 연결을 그저 기다리는 것이 전부이다. 결국, 이것은 서버가 존재하는 이유이다. 웹 서버들은 브라우저가 페이지를 요청하기를 기다리고, FTP 서버들은 클라이언트가 파일을 요청하기를 기다리며, 채팅 서버는 인커밍 채팅 클라이언트 연결을 기다린다. 서버는 그저 기다릴 뿐이다. 핸드쉐이크의 관점에서 서버가 동전의 다른 쪽에 있다는 것을 제외하고는 보안 클라이언트와 서버 통신간에는 거의 차이가 없다. 모든 것이 같다. 따라서, 여러분이 OpenSSL을 이용하여 클라이언트 애플리케이션을 작성하는 방법만 알고 있다면 OpenSSL을 사용하여 보안 서버 애플리케이션을 구현하는 것은 식은죽 먹기다. (그렇지 않다면, 본 시리즈 Part 1, "API의 개요"에서 OpenSSL 라이브러리 설정 방법을 배우기 바란다.) 두 가지 형태의 식별 SSL 콘텍스트 이 글에서 사용할 SSL 콘텍스트를 설정하려면 다음 코드를 사용하라. 이 함수는 에러 시 NULL을 리턴할 것이다. SSL_CTX *ctx = SSL_CTX_new(SSLv23_server_method()); 또는 두 개의 식별 방법이라고도 할 수 있다. 서버는 핸드쉐이크 동안 사용될 보안 인증서를 제공할 책임이 있다. 완전한 서버 인증서는 두 부분, 공개 키(public key)와 개인 키(private key)로 구성된다. 공개 키는 클라이언트로 보내지는 것이고, 개인 키는 비밀로 유지된다. 트러스트 인증서가 클라이언트 애플리케이션용 라이브러리에 제공되어야 하는 것처럼, 서버 키들도 서버 애플리케이션용 라이브러리에 제공되어야 한다. 이를 제공하는 여러 함수들이 있다. Listing 1. 서버 인증서를 로딩하는 함수들 SSL_CTX_use_certificate(SSL_CTX *, X509 *) SSL_CTX_use_certificate_ASN1(SSL_CTX *ctx, int len, unsigned char *d); SSL_CTX_use_certificate_file(SSL_CTX *ctx, const char *file, int type); ASN1 함수는 ASN1-encoded 디지털 인증서를 지정된 메모리 위치에서 SSL 콘텍스트로 로딩한다. 첫 번째 함수는 주어진 메모리 구조에 제공된 X.509 인증서를 로딩하지만, 마지막 함수, _file은 PEM-encoded 디지털 인증서를 파일에서 로딩한다. 이 함수의 type 매개변수는 DER-encoded 인증서가 로딩되도록 한다. 개인 키를 로딩하려면, 다음 함수들 중 하나를 사용한다. Listing 2. 개인 키 로딩을 위한 함수들 SSL_CTX_use_PrivateKey(SSL_CTX *ctx, EVP_PKEY *pkey); SSL_CTX_use_PrivateKey_ASN1(int pk, SSL_CTX *ctx, unsigned char *d, long len); SSL_CTX_use_PrivateKey_file(SSL_CTX *ctx, const char *file, int type); SSL_CTX_use_RSAPrivateKey(SSL_CTX *ctx, RSA *rsa); SSL_CTX_use_RSAPrivateKey_ASN1(SSL_CTX *ctx, unsigned char *d, long len); SSL_CTX_use_RSAPrivateKey_file(SSL_CTX *ctx, const char *file, int type); 몇 가지 필수 인터랙션 어떤 개인 키라도 암호화 되어 저장된다. 문제는, 인증서를 로딩하는 함수들이 암호화 된 인증서에 패스워드를 요청하지 않는다는 점이다. 대신, OpenSSL은 패스워드를 얻을 때 콜백 메커니즘을 제공한다. 콜백의 포맷은 다음과 같다. Listing 3. 콜백 포맷 int password_callback(char *buf, int size, int rwflag, void *userdata); 이 글의 목적상, 마지막 매개변수, userdata는 필요하지 않다. 함수가 호출되기 전에 버퍼가 할당되기 때문에 여러분에게는 버퍼의 크기에 대한 제어권이 없다. 서버 개인 키 서버 인증서의 경우, 개인 키는 암호화 되어 저장되어서는 안된다. 그렇지 않으면, 관리자가 패스워드를 너무 자주 입력해야 한다. 매개변수 rwflag는 읽기/쓰기 플래그이다. 패스워드가 정보를 암호화 하는데 사용되는지(rwflag = 1) 아니면 정보를 해독하는데 사용되는지(rwflag = 0) 여부를 프로그래밍 방식으로 결정하기 위해 사용된다. 데이터를 암호화 하기 위해 패스워드를 요청하기 위해 콜백이 사용된다면, 패스워드를 두 번 요청하여 오타를 방지할 수 있다. 패스워드는 인증서가 로딩될 때 단 한번 요청되기 때문에, 해독되고 메모리에 저장될 수 있다. 사용자에게서 패스워드를 획득하는 방법은 구현에 전적으로 달려있다. 패스워드 콜백 함수를 생성했다면, 이것을 SSL_CTX_set_default_passwd_cb를 사용하여 SSL 콘텍스트에 설치한다. Listing 4. 콜백 함수 설치하기 /* ctx is a pointer to a previously created SSL context, and cb is the pointer * to the callback function you created. */ SSL_CTX_set_default_passwd_cb(ctx, cb); 키 실행하기 콜백 함수가 생성되어 사용자에게 패스워드를 묻는 프롬프트가 생겼으니, 인증서를 실제로 가져오는 함수가 사용될 수 있다. 인증서는 기존 메모리 구조나 파일에서 가져올 수 있다. Apache HTTP Server Project의 디지털 인증서처럼, 디지털 인증서를 다루는 일반적인 방식에 더하여 인증서를 로딩하는 방법을 설명하겠다. 본 시리즈의 Part 1을 읽었다면, 인증서를 로딩하는 것은 트러스트 스토어가 이전 기술 자료의 데모에서 로딩된 방식과 비슷하다는 것을 알 수 있을 것이다. 클라이언트로 보내지는 것 중 하나인 공개 인증서로 시작하겠다. Listing 5. 공개 인증서 로딩하기 /** * ctx is the SSL context created earlier */ if(SSL_CTX_use_certificate_file(ctx, "/path/to/certificate.pem", SSL_FILETYPE_PEM) < 1) { /* Handle failed load here */ } 공개 인증서가 로딩된 후에, 개인 인증서도 로딩되어야 한다. 이 부분은 핸드쉐이크 동안 필요하다. 클라이언트는 공개 인증서로 암호화 된 정보를 서버로 보낼 것이기 때문이다. 이 데이터는 개인 키를 사용해서 해독될 수 있다. 일관성을 유지하기 위해, 파일에서 키를 로딩한다. Listing 6. 개인 키 로딩하기 if(SSL_CTX_use_PrivateKey_file(ctx, "/path/to/private.key", SSL_FILETYPE_PEM) < 1) { /* Handle failed load here */ } 설정 끝내기 콘텍스트(SSL 콘텍스트 사이드바 참조)를 설정하고 키를 로딩했다면, 이제는 BIO 객체를 생성하여 설정을 끝낼 차례이다. Part 1에서는 OpenSSL의 BIO 라이브러리를 사용하여 SSL과 비 SSL 통신 모두를 구축하는 방법을 설명했다. 일관성을 유지하기 위해, 같은 것이 이 곳에서도 수행된다. Listing 7. BIO 포인터 BIO *bio, *abio, *out; 세 개의 BIO 객체들? 왜 세 개씩이나 필요한가? 다 이유가 있다. 나를 믿어라. (기억하는가? 신뢰와 보안은 함께 한다는 것을..) 우선, bio는 SSL 콘텍스트에서 생성될 메인 BIO 객체이다. 두 번째 객체인 abio는 accept BIO로서 인커밍 연결을 수락한다. 세 번째 BIO인 out을 통해 서버가 클라이언트와 통신한다. Listing 8. 메인 BIO 객체 설정하기 bio = BIO_new_ssl(ctx, 0); if(bio == NULL) { /* Handle failure here */ } /* Here, ssl is an SSL* (see Part 1) */ BIO_get_ssl(bio, &ssl); SSL_set_mode(ssl, SSL_MODE_AUTO_RETRY); BIO 객체 설정은 클라이언트 연결을 설정하는 것과는 다르다. 클라이언트 연결이 BIO_new_ssl_connect를 사용하여 설정되는 것이라는 것을 Part 1에서 배웠다. 여기에서, 설정은 두 개의 매개변수, SSL_CTX 객체에 대한 포인터와 플래그와 함께 BIO_new_ssl을 사용하여 수행된다. 이 플래그는 OpenSSL에게 어떤 종류의 BIO 객체를 구현해야 하는지를 말해준다. 서버의 경우, 0, 클라이언트의 경우 1이다. 이 코드는 클라이언트 연결을 설정하는 것이므로, 플래그는 0으로 설정된다. Listing 9. accept BIO 설정하기 abio = BIO_new_accept("4422"); BIO_set_accept_bios(abio, bio); BIO_do_connect는 클라이언트 연결에 BIO를 생성하는데, BIO_new_accept는 서버 연결용 BIO를 생성한다. 여기에는 단 하나의 인자만 취하는데, 리스닝용 포트이다. 이것은 보안 연결을 리스닝 할 것이므로, 보안 BIO를 이 accept BIO로 연결시켜야 한다. 여기에서 두 번째 함수 호출, BIO_set_accept_bios가 작동한다. 이것은 이전에 생성된 SSL BIO를 accept BIO로 연결한다. 이 함수는 SSL BIO를 해제할 필요도 없앤다. accept BIO가 제거되면 자동으로 해제된다. 앉아서 기다리기 서버는 어부와 같다. 클라이언트가 물릴 때까지 앉아서 기다린다. 서버는 그저 인커밍 연결을 기다릴 뿐이다. 여러분이 Winsock이나 BSD Sockets를 사용해본 경험이 있다면, accept 함수에 대해서도 알 것이다. OpenSSL 상대자는 BIO_do_accept이다. 여기에서는 accept를 호출하면 되었지만, 이 경우에는 앉아서 기다리기 전에 BIO_do_accept를 두 번 호출해야 한다. Listing 10. 서버에게 앉을 것을(sit) 명령하기 /* First call to set up for accepting incoming connections... */ if(BIO_do_accept(abio) <= 0) { /* Handle fail here */ } /* Second call to actually wait */ if(BIO_do_accept(abio) <= 0) { /* Handle fail here */ } /* Any other call will cause it to wait automatically */ BIO_do_accept에 대한 첫 번째 호출은 BIO가 인커밍 연결을 수락하도록 설정한다. 두 번째 호출은 실제로 이것이 앉아서 기다리도록 하는데 필요하다. 이후에는 그저 기다리면 된다. 인커밍 호출에 응답하기 BIO_do_accept는 인커밍 연결을 받으면 1을 리턴한다. 하지만, accept BIO를 통해서 통신할 수 없다. 대신, OpenSSL은 BIO_pop을 사용하여 accept BIO에 필적하는 또 다른 BIO를 생성한다. Listing 11. 연결하기 out = BIO_pop(abio); if(BIO_do_handshake(out) <= 0) { /* Handle fail here */ } accept BIO에서 인커밍 연결을 해제한 후에, 핸드쉐이크는 BIO_do_handshake로의 호출을 사용하여 처리되어야 한다. 이전 섹션의 설정이 성공했다면, 핸드쉐이크도 성공할 것이다. 서버는 BIO 라이브러리에 사용할 수 있는 다양한 읽기 및 쓰기 함수들을 통해 클라이언트와 통신한다. 이 부분은 Part 1에서 설명했으므로 참조하기 바란다. 최상의 서비스 제공하기 결국, OpenSSL로 보안 서버 애플리케이션들을 구현하는 것은 실행 방법을 이해하기만 한다면 어렵지 않다. 이 코드 샘플을 확장하여 완벽한 SSL 서버 애플리케이션들을 여러분의 필요에 맞게 구현할 수 있다. 다시 한번 말하지만, 다운로드 섹션에서 제공하는 코드 샘플들은 최대로 간단한 것이고 실험을 목적으로 한 것이다. SSL 서버 애플리케이션들을 실제로 구현하기 전에, 최신 보안 권고 사항을 읽어보기 바란다. }

표준 C 스트링 함수 또는 각자 개인이 선호하는 스트링 라이브러리를 사용하여, 공통 이름과 호스트 이름을 비교한다. 미스매치(mismatch)를 다루는 방법은 프로젝트의 요구 사항이나 사용자의 결정에 달려있다. 더 심도 깊은 체크가 사용되어야 한다면, 개별 스트링 라이브러리를 사용하여 복잡함을 없애라고 권고하고 싶다.

신뢰 얻기

이 글을 통해 신뢰를 받은 소스인 것처럼 가장하여 침입하는 man in the middle 공격에 대하여 SSL 핸드쉐이크를 보안화 하는 방법을 설명했다. 또한 디지털 인증서의 개념과 OpenSSL API가 이들을 다루는 방법도 설명했다.

SSL 세션 동안 핸드쉐이크를 보안화 하는 것은 매우 중요하다. 연결에 포함된 거의 모든 보안들이 핸드쉐이크 내에서 설정되기 때문이다. 이 글에 제시된 각 단계를 따라가는 것은 프로젝트의 보안 요구 사항 및 개발자의 결정에 달려있다.

출처 : http://www.ibm.com/developerworks/kr/library/l-openssl.html