 |
|
|
|
난이도 : 중급
Kenneth Ballard, Software Engineer, MediNotes Corp.
2007 년 8 월 28 일
보안 통신용 오픈 라이브러리인 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에 모두 리스팅 되어 있다. 기타 헤더 및 초기화 함수들은 다른 기능들에 필요하다.
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 포인터와 비슷하다.
Listing 2. 포인터
연결하기
새로운 연결을 만들려면 BIO_new_connect를 호출해야 한다. 같은 호출에 호스트네임과 포트를 설정해야 한다. (Listing 3) 이것으로 연결을 시도할 것이다. 또한 이것을 두 개의 개별 호출로 나눌 수 있다. BIO_new_connect는 연결을 만들고 호스트네임을 설정하고, BIO_set_conn_port (또는 BIO_set_conn_int_port)는 포트 넘버를 설정한다.
일단 호스트네임과 포트 넘버가 BIO에 설정되면, 연결을 시도할 것이다. 방법은 없다. BIO 객체를 생성하는데 문제가 있다면, 포인터는 NULL이 될 것이다. BIO_do_connect로 호출하여 연결이 성공했는지를 확인하게 될 것이다.
Listing 3. 연결 생성 및 시작하기
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를 호출한다.
Listing 4. 연결에서 읽기
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는 이를 파악하는 방법이다. 쓰기 연산이 재시도 되면, 전과 똑 같은 매개변수가 있어야 한다.
Listing 5. 연결에 작성하기
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가 클래스에 삽입되면, 이는 클래스의 디스트럭터에 사용된다.
Listing 6. 연결 닫기
/* 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 매개변수를 설정한다.
Listing 7. 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을 리턴한다.
Listing 8. 트러스트 스토어 로딩하기
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에 대한 경로 매개변수로서 사용할 수 있도록 폴더를 준비시킨다.
Listing 9. 인증서 폴더를 준비하고 사용하기
/* 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은 이를 뒤에서 핸들한다. 이 옵션이 없이, 읽기 또는 쓰기 연산은 서버가 새로운 핸드쉐이크를 원할 경우 에러를 리턴하면서, 프로세스에서 재시도 플래그를 설정한다.
Listing 10. BIO 객체 설정하기
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로의 호출 역시 수행되어 연결이 성공적으로 열렸는지를 확인한다. 이와 똑 같은 호출이 핸드쉐이크를 수행하여 보안 통신을 설정한다.
Listing 11. 보안 연결 개방하기
/* 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 옵션 밑에 문서화 된 에러 코드를 리턴한다.
실패했다고 해서 연결이 사용될 수 없는 것은 아니다. 연결이 사용되는지의 여부는 확인 결과와 보안 고려 사항에 의존한다. 예를 들어, 실패한 트러스트 확인은 트러스트 인증서를 사용할 수 없다는 것을 의미한다. 더 강화된 보안으로 연결은 지속된다.
Listing 12. 인증서 유효성 여부 검사하기
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를 호출한다.
Listing 13. SSL 콘텍스트 제거하기
에러 탐지
OpenSSL은 에러도 던진다. 이것은 무엇을 의미하는가? 에러 코드를 먼저 받아야 한다. ERR_get_error가 바로 그것이다. 그 코드를 에러 스트링으로 변환하는데, 이는 SSL_load_error_strings 또는 ERR_load_BIO_strings에 의해 메모리로 영구 로딩되는 스트링에 대한 포인터이다. 이는 중첩 호출에서 수행될 수 있다.
표 1은 에러 스택에서 에러를 가져오는 방법을 정리한 것이다. Listing 14는 텍스트 스트링에서 마지막 에러 메시지를 출력하는 방법을 보여주고 있다.
표 1. 스택에서 에러 가져오기
ERR_reason_error_string |
정적 스트링에 대한 포인터를 리턴한다. 이는 스크린에 디스플레이 되고, 파일에 작성될 수 있다. |
ERR_lib_error_string |
어떤 라이브러리에 에러가 발생했는지를 알려준다. |
ERR_func_error_string |
에러를 일으켰던 OpenSSL 함수를 리턴한다. |
Listing 14. 마지막 에러 출력하기
printf("Error: %s\n", ERR_reason_error_string(ERR_get_error()));
|
이 라이브러리는 사전 포맷된 에러 스트링도 제공한다. ERR_error_string을 호출하면 된다. 에러 코드와 매개변수로서 사전 할당된 버퍼를 취한다. 이 버퍼는 256 바이트여야 한다. 이 매개변수가 NULL이면, OpenSSL은 256 바이트인 정적 버퍼에 스트링을 작성하고 그 버퍼에 대한 포인터를 리턴한다. 그렇지 않으면, 여러분이 제공했던 포인터를 리턴한다. 정적 버퍼 옵션을 선택하면, 그 버퍼는 ERR_error_string에 대한 호출로 오버라이트 될 것이다.
Listing 15. 사전 포맷된 에러 스트링 검색하기
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]은 소스 파일의 라인 넘버이다.
Listing 16. 에러 큐 덤핑하기
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이다.
참고자료
- 이 기술자료의 소스 코드 다운로드.
- 본 OpenSSL 시리즈의 다른 기술자료 (영문).
- OpenSSL Project; OpenSSL 소스 다운로드, 문서 확인. 메일링 리스트, FAQ!
- OpenSSL의 원조, SSLeay (문서).
- "SSL 소개," & SSL 3.0 프로토콜 스팩.
- 두 파트로 구성된 기술자료 보기 "OpenSSL Programming 소개" (Linux Journal, 2001) (& Part II), 또다른 두 파트 "OpenSSL을 이용한 소켓 보안" (Sams (informIT, 2001), & Part 2)
- BIO 라이브러리 문서 & OpenSSL을 이용한 네트워크 보안 (O'Reilly & Associates, 2002). Linux Socket Programming (Sams, 2001).
- OpenSSL은 BSD/Apache 라이센스이다. Free Software(good documentation) 팬이라면,The GNU Transport Layer Security Library를 참조하라. Mozilla Network Security Services (NSS)도 Mozilla Public License (MPL) 와 GNU General Public License (GNU GPL)에서 모두 라이센싱을 받고, 문서화도 잘 되어 있다. TLS의 경우, Wikipedia 기술자료, Transport Layer Security를 참조하라.
- Transport Layer Security (RFC 2246) & RFC 3546(TSL 프로토콜 확장)
- "Twisted 프레임웍에서의 네트워크 프로그래밍, Part 4" (developerWorks, 2003년 9월) David Mertz.
- To learn more about socket programming, see 리눅스 소켓 프로그래밍, Part 1 (developerWorks, 2003년 10월) & Part 2, 튜토리얼 시리즈 - David Mertz (developerWorks, 2004년 1월). Beej's Guide to Network Programming Using Internet Sockets.
- "Unix, NT, Java에서 소켓 이해하기" (developerWorks, 1998년 6월)
- IBM Sockets 관련 문서 (Communications Programming Concepts Sockets & Programming sockets on AIX (Technical Reference: Communications, Volume 2)
- "OpenSSL의 암호 라이브러리를 사용한 암호화" (Linux Gazette, 2003), & 암호화 개요" (developerWorks, 2001년 3월). Handbook of Appplied Cryptography (CRC Press, 1996).
- 리눅스 개발자를 위한 참고자료는 한국 developerWorks 리눅스 존에서
- Browse for books
필자소개
|
|
|
|
|
Kenneth는 MediNotes Corp.(West Des Moines, Iowa)의 소프트웨어 엔지니어이다. 페루, 나브라스카에 있는 Peru State College에서 경영학 학사 학위를 받았다. Southwestern Community College에서 컴퓨터 프로그래밍의 Associate of Science도 보유하고 있다. 여러 애플리케이션 및 프로그래밍 라이브러리를 작성했다. | |
