어떤 문제를 해결하는 가장 첫번째 방법은 일단 시도해 보는 것이긴 하지만 항상 그 이전에 내용을 이해하려고 노력해야 한다. 어떤 보안 솔루션의 사용에 있어서 그 제한(restriction)과 연관성(coherence)을 알지 못한 상태로 사용하는 것만큼 더 나쁜 것도 없다!

다음은 SSLv2 프로토콜과 cipher만을 사용하는 SSL 서버를 생성하는 방법이다:

다음은 일곱 가지의 가장 강력한 암호화만을 허용하게 한다:

이러한 기능(facility)은 Server Gated Cryptography (SGC)라고 불려지며, mod_ssl 배포판의 README.GlobalID 문서에서 자세한 내용을 볼 수 있다. 간단히 말하자면 다음과 같다:

Verisign과 같은 수출용 브라우저에서 강력한 암호화를 가능하게 해주는 Verisign과 같은 CA의 증명서(certificate)로 서명된 Global ID 서버 증명서를 서버가 가지고 있다. 브라우저는 수출용 암호(export cipher)를 가지고 서버에 접속하면 서버는 자신의 Global ID 증명서를 보내고 브라우저는 그 증명서를 확인(verify)한 후 어떠한 HTTP 통신이 일어나기 전에 cipher suite를 갱신한다. 여기서 생기는 질문은 우리가 어떻게 이 갱신을 허용하여 strong encryption을 강제(enforce)할 수 있는가이다. 다르게 말하면 브라우저가 처음부터 strong encryption을 가지고 접속하거나 혹은 strong encryption으로 갱신하여야 하는데 수출용 브라우저는 그러한 수출용 cipher가 허용되지 않는다는 것이다.

다음에 그 트릭이 있다:

분명히 strong variant에 대한 cipher들을 제한하는 server-wide SSLCipherSuite는 사용할 수 없다. 하지만 mod_ssl은 per-directory context에서의 cipher suite 재설정을 허용하며 자동으로 그 새로운 설정을 만족하기 위한 SSL 파라미터들의 재협상(renegotiation)을 강요하게 해준다. 따라서 다음과 같이 설정해 주면 된다:

인트라넷과 같이 공동체 내의 모든 사용자를 알고 있는 경우 plain certificate authentication을 사용할 수 있다. 해야 할 일은 단지 각 클라이언트들의 증명서를 자신의 CA 증명서인 ca.crt로 서명한 후 그 증명서를 가지고서 클라이언트를 확인(verify)하는 일 뿐이다.

이를 위해서는 mod_ssl가 제공하는 디렉토리 기반 재설정 기능(per-directory reconfiguration feature)을 사용한다:

중요한 것은 클라이언트 증명서의 다양한 구성요소(ingredient)들을 점검하는 것이다. 보통 이것은 Subject의 DN(Distinguished Name) 전체 혹은 일부분을 점검하는 것을 의미하며, 이를 위해서 두가지 방법, mod_auth 기반 방법과 SSLRequire가 존재한다: 첫번'째 방법은 클라이언트가 전체적으로 다른 형식, 즉 DN이 organisation과 같은 공통 필드를 가지지 않는 경우 유용하다. 이 경우 모든 클라이언트들에 대한 패스워드 데이터베이스를 구축하여야 한다. 두번째 방법은 클라이언트들이 DN으로 인코딩되어지는 공통 구조(common hierarchy)의 부분인 경우 유용하며, 이 경우 match가 더 쉽다.

첫번째 방법:

/usr/local/apache/conf/httpd.passwd

　
The second method:

서버, 클라이언트, 사용자와 같은 네트워크 상의 개체들에 대한 확인하는 일. SSL의 경우 서버와 클라이언트의 증명서를 확인(verification)하는 과정을 의미한다.

네트워크 상의 접근(access)에 대한 제한(restriction). Apache에서는 보통 어떤 URL에 대한 접근 제한을 의미한다.

어떠한 문제를 해결하기 위해 사용하는 방법으로서, 유한개의 단계(step)로 이루어진 모호하지 않는 식(formula) 혹은 규칙의 집합. 암호화를 위해 사용되는 알고리즘은 보통 Cipher라고 불린다.

서버나 클라이언트와 같은 네트워크 상의 개체(entity)들을 인증(authentication)하기 위해 사용되는 특정한 데이터 레코드로서, 증명서에는 그 증명서의 소유자에 대한 X.509 information (subject)과 그 증명서에 서명한 Certificate Authority (issuer)에 대한 X.509 information 이 포함되어 있으며, 또한 소유자의 공개키, CA에 의해 만들어진 서명이 포함되어 있다. 네트워크 상의 개체들은 CA의 증명서를 이용하여 이 서명들을 확인하게(verify) 된다.

네트워크 상의 개체들에 대한 증명서에 서명하는 것을 목적으로 하는 믿을 수 있는 제 3자(trusted third party)로서 증명서를 인증하는 역할을 한다. 다른 네트워크 개체들은 서명을 체크함으로써 자신에게 온 증명서가 어떤 CA에 의해 인증되었음을 확인할 수 있다.

서명을 받기 위해 CA에게 제출되어질 아직 서명되지 않은 증명서로서 CA는 자신의 CA 증명서의 개인키로 CSR에 서명하게 된다. CSR이 서명되어지면 실제로 사용할 수 있는 증명서(real certificate)가 된다.

데이터 암호화를 위한 알고리즘이나 시스템으로서, DES, IDEA, RC4 등이 있다.

Plaintext가 cipher를 통하여 나온 암호화된 결과.

어떤 프로그램의 행동을 제어하는 설정 명령(configuration command ). Apache의 경우 설정 파일의 첫번째 열에 모든 명령어의 이름이 있다.

HTTP 상에서 raw data channel을 proxying하기 위한 HTTP 명령으로서 SSL 프로토콜과 같은 다른 프로토콜들을 포함하는데(encapsulate) 사용되어질 수 있다.

증명서나 어떤 파일에 대한 유효성(validity)을 검사하기 위한 암호화된 텍스트 블록. CA는 증명서에 들어있는 공개키의 hash를 생성하고, 생성된 hash를 CA 자신의 개인키로 암호화함으로써 서명을 생성하게 된다. 단지 서명을 생성한 CA의 공개키만이 서명을 복호화할 수 있으며, 서명을 복호화함으로써 그 CA가 그 증명서의 소유자를 인증하였음을 확인하게 된다.

미국의 수출관리규정(Export Administration Regulation ? EAR)에 따르기 위한 목적으로 암호화의 강도(cryptographic strength)를 낮추는 것으로서, 이 규정이 적용되는 암호화 소프트웨어는 작은 크기의 키만을 사용하도록 제한되어져 있으며, 이로 인하여 Brute Force 공격에 쉽게 깨어질 수 있는 암호문만을 생성할 수 있다.

네트워크 상의 개체에 대한 유일한 이름으로서, IP 주소로 변환(resolve)될 수 있는 호스트 명과 도메인 명으로 이루어진다. 예를 들어, www는 호스트 명이고, whatever.com은 도메인 명이며, www.whatever.com은 FQDN이 된다.

World Wide Web에서 사용되는 표준 전송 프로토콜.

안전한(secure) HTTP 프로토콜로서 World Wide Web에서 사용되는 표준 암호화 통신 프로토콜. 실제로 HTTPS는 SSL 상에서 HTTP를 구현한 것이다.

메시지로부터 얻어낸 hash로서 전송 중에 메시지의 내용이 변경되지 않았음을 확인하는데 사용된다.

개인키 파일을 보호하기 위한 단어(word)나 구문(phrase)으로서 허용되지 않은 사용자가 개인키 파일을 암호화하는 것을 막기 위해 사용된다. 이 때 보통 암호화를 위해서 비밀키 암호화/복호화를 사용한다.

암호화되지 않은 텍스트.

공개키 암호화 시스템에서 자신만이 알고 있는 비밀키로서 자신에게 온 메시지를 암호화하거나, 자신이 보내는 메시지에 서명하는데 사용된다.

공개키 암호화 시스템에서 공개하게 되는 공개키로서, 그 공개키의 소유자에게 보낼 메시지를 암호화하거나 그 공개키의 소유자가 생성한 서명을 복호화하는데 사용된다.

비대칭형 암호화 시스템을 구현한 암호화 방법으로서 하나의 키를 암호화에 사용하고 다른 하나의 키를 복호화에 사용하게 되며, 이 키들의 쌍을 key pair라고 부른다. 공개키 암호화는 비대칭형 암호화(Asymmetric Cryptography)라고도 불려진다.

TCP/IP 네트워크 상에서 일반적인 통신 인증과 암호화를 목적으로 Netscape사에 의해 만들어진 프로토콜. SSL을 사용하는 가장 일반적인 방법은 SSL 상에서 HTTP를 구현하는 HTTPS를 사용하는 것이다.

SSL 통신의 context information.

Eric A. Young eay@cryptsoft.com이 개발한 SSL/TLS 구현 라이브러리.

암호화와 복호화에 동일한 키를 사용하는 암호화.

TCP/IP 네트워크 상에서 일반적인 통신 인증과 암호화를 위해 IETF(Internet Engineering Task Force)에서 SSL의 후속으로 개발한 프로토콜. TLSv1은 SSLv3와 거의 동일하다.

World Wide Web 상에서 다양한 자원(resource)들의 위치를 표시하기 위한 방법. 가장 잘 알려진 URL scheme은 http이며, SSL은 https를 사용한다.

ITU(International Telecommunication Union)에 의해 권장되어진 authentication certificate scheme이며, SSL/TLS 인증에 사용된다.

이 장에서는 mod_ssl에서 사용되는 모든 설정 지시자(configuration directive)와 함께 mod_ssl이 제공하는 user visible feature들에 대하여 설명하며, 이를 통해 mod_ssl의 어떤 특정한 기능이 실제로 어떻게 설정되는가 혹은 활성화되는가를 설명한다. 각 directive는 Apache 문서에서 표준 Apache directive를 설명하는 방식과 유사한 방식으로 기술되어지는데, 여기에는 directive의 syntax, default, context 등의 요소들이 기술된다.

Mod_ssl에서 사용하는 directive는 크게 세가지 분류(class)로 나눠진다. 먼저 Global Directive(context가 “server config”인 directive)는 server config 파일에서 <VirtualHost>와 같은 sectioning command 밖에서만 사용될 수 있다. 두 번째는 Per-Server Directive(context가 “server config, virtualhost”인 directive)로서 server config 파일에서 <VirtualHost> 섹션의 밖이나 안에서 모두 사용될 수 있으며, <VirtualHost> 섹션의 밖에서 사용될 때는 메인(Default) 서버에 대한 설정이 된다. 세 번째는 Per-Directory Directive(context가 “server config, virtual host, directory, .htaccess”인 directive)로서 server config 파일과 per-directory .htaccess 파일의 어느 곳에서든 사용될 수 있다. 이 세가지 class들은 서로의 부분 집합이 되는데, 즉 per-directory의 directive가 per-server와 global context에서 사용될 수 있으며, 또한 per-server class의 directive가 global context에서 사용될 수도 있다.

다른 Apache SSL 숄류션들에 대한 backward compatibility를 위해 mod_ssl이 제공하는 부가적인 directive들과 환경 변수들은 Compatibility Chapter에 기술되어져 있다.

Apache가 시동될 때 SSL이 적용된 각 virtual host에 대한 Certificate와 Private Key를 읽어온다. 보안을 위해서 Private Key들은 암호화되어 있으며, 따라서 mod_ssld은 관리자에게 암호화된 Private Key를 복호화하기 위해서 Pass Phrase를 요구한다. Pass Phare를 요구하는 방식은 다음의 두가지 방식이 될 수 있다.

이 directive는 fork되어진 Apache 서버 프로세스 간의 동기화되어 실행되어야 할 오퍼레이션들의 상호배제(mutual exclusion)에 사용되는 SSL 엔진의 세마포어(semaphore)를 설정한다. 단지 하나의 global mutex만이 유효하기 때문에 이 directive는 global server context에서만 사용할 수 있다.

가능한 Mutext type은 다음과 같다:

SSLRandomSeed

이 directive는 시동할 때(context가 startup인 경우) 혹은 새로운 SSL 연결(connection)이 이루어질 때(context가 connect인 경우) SSLeay의 Pseudo Random Number Generator (PRNG)의 seeding을 위한 하나 혹은 그 이상의 seed source를 설정한다. PRNG가 global facility이므로 이 directive는 global server context에서만 사용될 수 있다.

가능한 source variant는 다음과 같다:

이 directive는 global/inter-process SSL Session Cache의 storage type을 지정하며, 이 cache는 병렬적인 요청 프로세스(parallel request processing)의 속도를 개선해주는 역할을 한다. 동일한 서버 프로세스(HTTP keep-alive를 통한)에 대한 요청에 대해서 SSLeay는 SSL session information을 로컬에 저장을 한다. 그러나 modern client는 이미지나 다른 데이터들을 parallel request를 통하여 요청하기 때문에(보통 4개까지의 parallel request), 이러한 요청들은 서로 다른 pre-forked process에 의해 처리된다. Inter-process cache는 필요없는 session handshake를 피할 수 있게 해준다.

다음과 같은 2가지의 storage type이 지원된다:

이 directive는 global/inter-process SSL Session Cache와 SSLeay internal memory cache에 저장된 정보들에 대한 timeout을 초단위로 지정한다. 설정 값은 최저 15초이며 실제로 실행될 서버에서는 보통 300초 이상을 지정한다.

이 directive는 SSL/TLS 프로토콜 엔진의 사용여부를 지정하며, 보통 <VirtualHost> 섹션 안에 사용되어 해당 virutal host가 SSL/TLS를 사용할 것인가를 지정한다. 기본 설정은 주서버와 모든 virtual host에 대하여 SSL/TLS 프로토콜을 사용하지 않는 것이다.

이 directive는 SSL handshake phrase 단계에서 클라이언트와 협상(negotiation)할 수 있는 Cipher Suite를 설정하며, 이를 위해 콜론(: )으로 구분되는 SSLeay cipher specification들로 이루어진 스트링을 directive의 값으로 지정한다. 이 directive는 per-server와 per-directory context 모두에서 사용될 수 있다. Per-server context의 경우 이 directive는 connection이 이루어질 때 표준 SSL handshake에 적용되며, per-directory context의 경우에는 HTTP request는 read 되었지만 HTTP response는 보내지기 전에 재설정된 Cipher Suite를 가지고 SSL renegotiation하게 된다.

Cipher-spec에 지정되는 SSL cipher specification은 4개의 주속성(major attribute)과 몇 가지의 부가적인 작은 속성(extra minor ones)들로 이루어진다:

SSL cipher는 또한 export cipher가 되거나 혹은 SSLv2와 SSLv3/TLSv1 cipher(여기서 TLSv1은 SSLv3와 동일하다) 둘 중에 하나가 될 수 있다. 사용할 cipher를 명시하는 방법으로는 모든 cipher를 사용하거나, 한번에 한가지 cipher를 사용하거나, 혹은 alias를 지정하여 cipher의 선호도와 사용 순서를 지정할 수 있다(Table 1 참조).

사용하고자 하는 cipher와 그 순서를 지정하기 위해서 여러 개의 tag들을 함께 지정할 수 있으며, 이를 위해 어떤 특정한 cipher들의 그룹을 의미하는 alias(SSLv2, SSLv3, EXP, LOW, MEDIUM, HIGH)들을 사용할 수 있다. 이 tag들을 몇 가지 접두사(prefix)로 연결하여 cipher-spec을 이룰 수도 있으며, 가능한 접두사(prefix)는 다음과 같다:

• none: 리스트에 cipher를 포함시킨다

• + : cipher를 리스트에 포함시키며 또한 리스트의 현재 위치로 가져다 놓는다

• - : 리스트로부터 cipher를 제거한다(이후에 다시 포함시킬 수 있다)

• ! : 리스트로부터 cipher를 완전히 제거한다(이후에 다시 포함시킬 수 없다)

“ssleay ciphers ?v” 명령어로 모든 cipher-spec string을 볼 수 있다. 기본(default) cipher-spec string은 “ALL:!ADH:RC4+RSA:+HIGN:+MEDIUM:+LOW:+SSLv2:+EXP”이며 의미는 그 다음과 같다.

1. Authenticate하지 않는 모든 cipher들을 고려(consideration)에서 제거한다. SSL의 경우 단지 Anonymous Diffie-Hellman cipher만이 제거된다

2. RC4와 RSA를 사용하는 cipher를 포함시킨다.

3. High security cipher, medium security cipher, 그리고 low security cipher를 각각 포함시킨다.

4. 마지막으로 모든 SSLv2 cipher와 export cipher들을 리스트의 마지막에 포함시키다.

Table 2는 SSL에서 사용되는 RSA와 DH cipher에 대한 전체 리스트이다.