FAQ..

SSL, HTTP
그리고 Apache 각각이 요청(request) 처리하는 방식 간의 연관성으로 인하여 SSL 적용된 서버의 어떤 특정 보안 문제에 대한 해결 방법이 항상 명확하지는 않다. 장에서는 그러한 전형적인 상황에서 문제를 어떻게 해결할 것인가에 대하여 논의한다.

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

Cipher Suites and Enforced Strong Security

어떻게 하면 SSLv2만을 사용하는 서버를 생성할 있나? [L]

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

httpd.conf

SSLProtocol -all +SSLv2

SSLCipherSuite SSLv2:+HIGH:+MEDIUM:+LOW:+EXP


어떻게
하면 강력한 암호화(strong encryption)만을 허용하는 SSL 서버를 생성할 있나? [L]

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

httpd.conf

SSLProtocol all

SSLCipherSuite HIGH:MEDIUM


어떻게
하면 SSL 서버로 하여금 강력한 암호화만을 허용하면서 수출용 브라우저로 하여금 강력한 암호화를 사용할 있게 업그레이드를 허용할 있을까? [L]

이러한 기능(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 허용되지 않는다는 것이다.

다음에 트릭이 있다:

httpd.conf

# allow all ciphers for the initial handshake,

# so export browsers can upgrade via SGC facility

SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

<Directory /usr/local/apache/htdocs>

# but finally deny all browsers which haven't upgraded

SSLRequire %{SSL_CIPHER_USEKEYSIZE} >= 128

</Directory>


어떻게
하면 SSL 서버로 하여금 일반적인 모든 형식의 cipher 허용하면서 특정 URL로의 접근에 대해서만 strong cipher 요구하게 있나? [L]

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

httpd.conf

# be liberal in general

SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

<Location /strong/area>

# but https://hostname/string/area/ and below requires strong ciphers

SSLCipherSuite HIGH:MEDIUM

</Location>

 

Client Authentication and Access Control

나의 모든 클라이언트들을 알고 있는 경우 어떻게 하면 증명서에 기반하여 클라이언트들을 인증할 있나? (How can I authenticate clients based on certificates when I know all my clients?) [L]

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

httpd.conf

# require a client certificate which has to be directly

# signed by our CA certificate in ca.crt

SSLVerifyClient require

SSLVerifyDepth 1

SSLCACertificateFile conf/ssl.crt/ca.crt


특정
URL 대해서만 증명서를 기반으로 클라이언트를 인증하면서 서버의 다른 부분들에 대해서는 임의의 클라이언트들의 접근을 허용하려면 어떻게 하나? (How can I authenticate my clients for a particular URL based on certificates but still allow arbitrary clients to access the remaining parts of the server?) [L]

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

httpd.conf

SSLVerifyClient none

SSLCACertificateFile conf/ssl.crt/ca.crt

<Location /secure/area>

SSLVerifyClient require

SSLVerifyDepth 1

</Location>


몇몇
URL들에 대해서는 증명서에 기반하여 특정 클라이언트들만을 인증하면서 서버의 나머지 부분들에 대해서는 임의의 클라이언트들로부터의 접근을 허용하고자 하는 경우 어떻게 해야 하나? (How can I authenticate only particular clients for a some URLs based on certificates but still allow arbitrary clients to access the remaining parts of the server?) [L]

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

첫번째 방법:

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

SSLVerifyClient none

<Directory /usr/local/apache/htdocs/secure/area>

SSLVerifyClient require

SSLVerifyDepth 5

SSLCACertificateFile conf/ssl.crt/ca.crt

SSLCACertificatePath conf/ssl.crt

SSLOptions +FakeBasicAuth

SSLRequireSSL

AuthType Basic

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

require valid-user

</Directory>


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

/C=DE/L=Munich/O=Snake Oild, Ltd./OU=Staff/CN=Foo:xxj31ZMTZzkVA

/C=US/L=S.F./O=Snake Oild, Ltd./OU=CA/CN=Bar:xxj31ZMTZzkVA

/C=US/L=L.A./O=Snake Oild, Ltd./OU=Dev/CN=Quux:xxj31ZMTZzkVA

 
The second method:

SSLVerifyClient none

<Directory /usr/local/apache/htdocs/secure/area>

SSLVerifyClient require

SSLVerifyDepth 5

SSLCACertificateFile conf/ssl.crt/ca.crt

SSLCACertificatePath conf/ssl.crt

SSLOptions +FakeBasicAuth

SSLRequireSSL

SSLRequire %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." and \
%{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"}

</Directory>




신고
Posted by Golmong

댓글을 달아 주세요



Chapter 6 Glossary

Authentication

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

Access Control

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

Algorithm

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

Certificate

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

Certification Authority (CA)

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

Certificate Signing Request (CSR)

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

Cipher

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

Ciphertext

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

Configuration Directive

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

CONNECT

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

Digital Signature

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

Export-Crippled

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

Fully-Qualified Domain-Name (FQDN)

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

HyperText Transfer Protocol (HTTP)

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

HTTPS

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

Message Digest

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

Pass Phrase

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

Plaintext

암호화되지 않은 텍스트.

Private Key

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

Public Key

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

Public Key Cryptography

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

Secure Sockets Layer (SSL)

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

Session

SSL 통신의 context information.

SSLeay

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

Symmetric Cryptography

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

Transport Layer Security (TLS)

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

Uniform Resource Locator (URL)

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

X.509

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

신고
Posted by Golmong

댓글을 달아 주세요



Chaper.5 FAQ

FAQ 뉴스그룹 comp.infosystems.www.servers.unix mod_ssl 지원을 위한 메일링 리스트인 sw-mod-ssl@engelschall.com 올라왔던 질문들을 모은 것이다.

About the module

mod_ssl Apache-SSL 어떻게 다르며, mod_ssl 어디에서 출발한 것인가? [L]

mod_ssl Apache-SSL 비해 많은 변화가 있었으며, 자세한 내용은 mod_ssl 배포판의 CHANGES CHANGES.20 파일을 참조한다. 대부분은 내부적인 변경이나 소스 코드의 변경이며, 밖으로 보여지는 주요한 변화는 다음과 같다 :

mod_ssl Apache-SSL에서는 제공하지 않는 완전한 사용자 매뉴얼을 제공하며, 여기에는 모든 Configuration directives, 환경변수(environment variable) 그리고 외의 많은 것들에 대하여 기술하고 있다. 또한 mod_ssl Apache/SSL/SSLeay 대한 FAQ 제공하며, FAQ에서는 CA 설정하는 , 서버 증명서(Server Certificate) 생성하는 등등에 대한 자세한 설명을 제공한다.

Mod_ssl 사용자들이 backdoore security hole 등을 찾아보는데 도움이 있도록 소스 코드에 자세한 설명을 덧붙이고 있으며, 이것은 보안에 관련된 소프트웨어에 있어서 매우 중요하게 고려되어야 사항이다. Mod_ssl 패키지의 소스 코드는 Apache 코딩 스타일을 따르고 있으며, API 단계를 논리적으로 따른다.

Mod_ssl SSL 구현하기 위하여 Extended API 사용하며, Apache kernel SSL 암호화에 관련된 코드를 직접 패치하는 것이 아니라 EAPI 패치함으로써 커널과 mod_ssl 서로 독립적이 있도록 하였다. 이로 인하여 SSL 암호화에 관련된 코드는 단지 SSL 모듈 자체(src/modules/ssl/ 디렉토리)에만 존재하게 되며, Apache 커널에서 직접적으로 SSL 참조하지 않는다.

Mod_ssl Dynamic Shared Object(DSO) 기능을 지원하며, DSO 지원으로 run-time 시의 유연성(flexibility) 최대한 높일 있게 된다. , Apache 컴파일할 SSL Apache 실행파일(httpd) 넣을 것인가 넣지 않을 것인가를 결정할 필요가 없으며, 단지 필요하면 mod_so 제공하는 LoadModule directive 이용하여 mod_ssl 로딩하면 된다. 기능은 두가지 면에서 매우 유용하다: Vendor package maintainer에게 유연성 있는 패키지를 만들 있는 방법을 제공하며, Apache 사용자에게 있어서는 하나의 Apache만을 설치하고서 하나 이상의 Apache(SSL 사용하는 Apache SSL 사용하지 않는 Apache) 실행할 있게 해준다.

Mod_ssl Win32 플랫폼에서 동작하며, 이는 Apache SSLeay Wind32 플랫폼에서 동작함에 의해서 가능하다. mod_ssl 패키지들의 발전을 따르고 있으며, 귀찮은 플랫폼에서도 항상 요구되는 지원 사항들을 제공한다. Unix/DSO 경우와 같이 Win32에서도 mod_ssl mod_so LoadModule directive 의해 로딩될 있는 표준 DLL 통해 Apache 적용되어진다.

Apache-SSL 사용자로 하여금 직접 patch cp 같은 명령어를 사용하게 만들었던 것에 비하여 mod_ssl 자동화된 설정 환경을 제공함으로써 매우 쉽게 Apache 소스 트리에 적용되어진다. 이를 위하여 mod_ssl Apache 1.3 제공하는 Autoconf-style Interface(APACI) 지원한다. 또한 mod_ssl RSAref 사용할 있으며, SSLeay 어느 위치에 설치되었는가를 상관하지 않는다.

Apache-SSL mod_ssl 같은 Apache 소스 트리에 적용하기 위한 손쉬운 방법을 제공하지 않으며 어느정도의 수작업 편집과 patch 작업이 필요하다. Configuration 때와 Install Apache-SSL Apache 1.3 Autoconf-style Interface(APACI) 쉽게 통합되어질 없으며, 이미 설치되어 있는 SSLeay out-of-the-source-only SSLeay와의 차이점을 자동으로 인식하지 않는다. 또한 SSLVerifyClient 인수로 이름 대신에 0에서 2까지의 숫자를 사용하는데, 이유는 내부적으로 enum 사용되었고 또한 CustomLog %{version}c construct 대한 결과값으로 SSLeay 0.9에서는 SSL2, SSL3 등을 사용하는 것에 비하여 SSLeay 0.8에서는 2, 3 사용되었기 때문이다.

Mod_ssl Apache-SSL에서 제공하지 않았던 몇가지 기능을 덧붙였다:

Mod_ssl log level 따른 SSL 전용 로그 파일을 제공하며, error level 메시지는 자동으로 Apache 에러 로그 파일에 중복해서 기록한다. 또한 occuring system SSLeay 에러 메시지는 자동으로 mod_ssl 메시지에 덧붙여지며, 부가적으로 mod_ssl 매우 자세한 힌트와 함께 SSLeay 메시지를 기록한다. Mod_ssl 암호화된 개인키 파일들의 handling 있어서 매우 새로운 기능을 제공한다. 먼저, 개인키를 permanent memory pool 저장함으로써 Apache 완전히 죽이지 않고서도 서버를 재시동할 있게 되었다. 두번째는 pass-phrase dialog 훨씬 사용하기 편리하고 기능이 향상되었다: pass-phrase 입력받는 횟수를 줄이기 위해 pass-phrase reuse algorithm 사용하며, 틀린 pass-phrase 인식하여 재시도할 있게 하며, pass-phrase 일괄 입력하기 위하여 pass-phrase 제공하는 외부 프로그램을 사용할 있는 interface 제공한다. Mod_ssl 제공하는 SSLCACertificateReqFile directive 클라이언트가 서버 인증의 속도를 높이기 위해 서버로부터 CA Certificate 로딩하는데 사용되는 SSLv3 feature 위한 differect set of CA Certificates 설정하는데 사용된다. Apache 내에서 외부 프로그램을 제어하는 것이 그다지 믿을 만하게 동작하지 않기 때문에, Mod_ssl Apache-SSL에서 SSL 세션을 저장하기 위해 사용하는 gcache 기능을 더욱 강력한 DBM 기반의 솔류션으로 대체하였다. 부가적으로 cache 대한 inter-process access 동기화하기 위하여 mutex 사용한다. Mod_ssl SSLeay RSAref 함께 조합하여 사용할 있는 기능, RSAref 패키지를 이용하여 Apache에서의 SSL Extension 구현할 있는 기능을 제공한다. SSLRequire directive 임의의 boolean expression 조합을 접근 제어의 조건으로 사용할 있게 해준다. Apache Proxy Module(mod_proxy) 대한 HTTPS 기능을 지원한다. Mod_ssl Win32 Apache 대한 SSL Extension으로서는 처음으로 소스를 공개한 패키지이다.

mod_ssl 대한 자세한 내용은 mod_ssl 배포판에 포함되어 있는 CHANGES 파일과 CHANGES.20 파일을 참조하기 바란다.

그렇다면 지금부터 Apache-SSL 사용하지 말아야 하는가? [L]

그렇지 않다. 단지 mod_ssl 사용할 있음을 의미할 뿐이다. 알려져 있는 SSL 솔류션인 Apache-SSL 여전히 필요한 기능을 훌륭히 수행하며, Ben Laurie 아직도 패키지의 관리를 위해 많은 일들을 하고 있다. 단지 중요한 차이점은 Ben Laurie 목적과 Ralf S. Engelschall 목적이 다르다는 것이다. 만약 패키지의 차이점에 대하여 별로 필요성을 느끼지 않는다면 굳이 mod_ssl 업그레이드할 이유는 없다. 단지 Apache-SSL 사용하는 것이 편하게 느껴진다면 Apache-SSL 사용하는 것이고 그렇지 않다면 mod_ssl이나 나은 기능을 제공하는 다른 상용 SSL 솔류션을 사용하라는 것이다. 다시 말해서 어떤 솔류션이 다른 것들보다 낫다고 말할 수는 없으며, 어느 것을 사용하는가는 개인적인 요구사항에 달려있는 것이다.

On which Apache-SSL version is mod_ssl actually based? [L]

Mod_ssl 본래 1998 4 Apache-SSL 1.17 버전을 Apache 1.2.6에서 Apache 1.3b6 포팅하는 작업에서 만들어졌다. Ben Laurie 개발 사이클과 맞지 않음으로 인하여 mod_ssl 기존의 mod_ssl 새로운 Apache-SSL 1.18 조합하여 Apache 1.3.0 위한 버전으로 태어나게 되었다. 시점부터 mod_ssl 독자적인 개발을 하게 되었으며, Apache-SSL에서 개선되는 부분들은 이후 mod_ssl 받아들이는 방식으로 진행되어져 왔다. 다시 말하면, mod_ssl 가장 최신의 Apache-SSL 기반을 두고 있으며, Apache-SSL에서 개선되는 부분들을 항상 받아들이게 것이다.

Why is mod_ssl's version starting with 2.0.0? [L]

Mod_ssl 프로젝트가 Apache-SSL 프로젝트의 일환으로 계획되어진 것이었으며, 원래는 mod_ssl Apache-SSL 2.0.0 넣고자 하는 의도였으나, Ralf S. Engelschall Ben Laurie mod_ssl Apache-SSL 합치지 않겠다고 결정함으로써 mod_ssl 프로젝트는 mod_ssl이란 이름으로 새로운 패키지로서 발표되었다. 그러나 mod_ssl second generation 이란 의미를 표시하기 위해 첫번째 mod_ssl 버전은 2.0.0으로 결정되게 되었다.

How do I know which mod_ssl version is for which Apache version? [L]

그것은 간단하다. Mod_ssl <mod_ssl-version>-<apache-version>으로 구성된 버전 표기를 하며, 예를 들면 2.2.0-1.3.4 mod_ssl 버전이 2.2.0이며 Apache 버전 1.3.4 위한 것임을 의미한다. 또한 이는 mod_ssl 버전을 정확히 Apache 버전에만 적용할 있음을 의미한다.

Is mod_ssl Year 2000 compliant? [L]

Mod_ssl Y2K 문제를 해결하였다.

Mod_ssl 내부적으로 년도를 2자리로 표시하지 않으며, 시간의 표시를 현대의 대부분의 유닉스 시스템들이 사용하고 있는 시간 표시 방식인 ANSI C & POSIX numeric data type time_t 형식을 사용한다. 형식은 1970 1 1 00:00 UTC로부터 지금까지의 (second) 단위 시간을 가지고 있는 signed long 정수(보통 32bit) 시간을 표시한다. 수는 2000년이 아니라 20381월초에 overflow 발생한다. 또한 날짜와 시간의 표기(예를 들어 %{TIME_YEAR} ) 2자리 숫자로 표기하지 않고 4개의 숫자로 표기한다.

부가적으로, Apache 그룹의 2000 문제에 대한 발표에 따르면 Apache 서버는 2000 문제의 영향을 받지 않는다. 그러나 SSLeay OS ( Unix 혹은 Win32 platform) 2000 문제의 영향을 받지 않는가의 문제는 여기서 답변될 내용이 아니다.

What about mod_ssl and the Wassenaar Arrangement? [L]

Wassenaar Arrangement on Export Controls for Conventional Arms and Dual-Use Goods and Technologies 재래식 무기, dual-use good technology 대한 무역을 통제하기 위해 1995년에 설립된 국제기구(international regime)로서 기존에 있던 기구인 CoCom 대체한 기구이다. 다음의 33 가맹국이 있다: Argentina, Australia, Austria, Belgium, Bulgaria, Canada, Czech Republic, Denmark, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Japan, Luxembourg, Netherlands, New Zealand, Norway, Poland, Portugal, Republic of Korea, Romania, Russian Federation, Slovak Republic, Spain, Sweden, Switzerland, Turkey, Ukraine, United Kingdom and United States. 자세한 내용은 http://www.wassenaar.org 사이트를 참조한다.

간단히 말해서 Wassenaar Arrangement 목적은 국제적 혹은 지역적인 안보와 평안을 위협하는 군사적 능력(military capability) 제어하는데 있다. Wassenaar Arrangement 암호학 (Cryptography) 하나의 dual-use good으로서 제한하고 있으나 mass-market software free software 대해서는 수출 제한에서 면제하고 있다.

현재 Wassenaar GENERAL SOFTWARE NOTE(GSN) 대한 List of Dual Use Goods and Technologies And Munitions 따르면, public domain 속하는 소프트웨어는 제한하지 않는다고 되어 있다. 또한 DEFINITIONS OF TERMS USED IN THESE LISTS에는 다음과 같은 정의가 있다. in the public domain : This means "technology" or "software" which has been made available without restrictions upon its further dissemination. N.B. Copyright restrictions do not remove "technology" or "software" from being "in the public domain".

Wassenaar Agreement 따르면 mod_ssl SSLeay public domain 속하게 되며, 따라서, mod_ssl SSLeay Wassenaar Agreement 영향을 받지 않는다..

 

About Configuration

I want to run HTTP and HTTPS on the same machine. Is that possible? [L]

두가지 방법이 있다: 두개의 서버를 따로 실행하거나 하나의 서버에 두개의 서비스를 실행한다. 두개의 서버를 실행해야 특별한 이유가 없는 , 하나의 instance에서 SSL 필요로 하는 virtual host 대해서만 SSL 적용하는 방법을 사용하는 것이 간단하다. 만약 두개의 서버를 따로 실행하는 경우에는 두개의 서버가 각각 허용된 포트(보통 HTTP 80, HTTPS 443)에만 bind 시도하도록 되어 있는가를 확인해야 한다.

I know that HTTP is on port 80, but where is HTTPS? [L]

어느 포트에서든지 HTTPS 실행할 수는 있지만 표준 HTTPS 포트는 443번이며, 브라우져는 기본적으로 포트를 찾도록 되어 있다. 브라우져가 443번이 아닌 다른 포트를 찾도록 하기 위해서는 다음과 같은 URL 사용한다(포트가 666 경우):

https://secure.server.dom:666/

How can I speak HTTPS manually for testing purposes? [L]

보통 Apache HTTP 프로토콜을 간단하게 테스트할 다음을 이용한다.

$ telnet localhost 80

GET / HTTP/1.0

그러나 HTTPS 경우에는 SSL 프로토콜이 TCP HTTP 사이에 위치하기 때문에 HTTP 같이 쉽지 않다. 하지만 SSLeay 제공하는 s_client 프로그램을 이용하여 HTTPS 대해서도 HTTP 비슷한 테스트를 있다:

$ s_client -connect localhost:443 -state -debug

GET / HTTP/1.0

실질적인 HTTP 응답(response) 이전에 SSL handshake 대한 자세한 정보가 보여지게 된다. Apache 80번과 443 포트에서 제대로 동작하고 있는가를 체크하기 위해서는 다음과 같은 cURL tool 사용할 있다.

$ curl http://localhost/ (80 포트)

$ curl https://localhost/ (443 포트)

Why does my browser hang when I connect to my SSL-aware Apache server? [L]

https:// 형태의 URL 아닌 http:// 형태의 URL 사용하였을 있다. 경우 Apache 에러 로그파일에 SSL_Accept failed error: 140760EB: SSL routines: SSL23_GET_CLIENT_HELLO: unknown protocol 이라는 메시지가 나타나게 된다. 또한 이러한 현상은 SSL 지원하지 않는 서버에 https:// 접속을 시도하는 경우에도 나타난다. 이러한 경우에는 해당 가상 서버(virtual server) SSL 지원하고 있나를 확인해 본다.

How can I use relative hyperlinks to switch between HTTP and HTTPS? [L]

URL 변경하기 위해선 보통 Fully-qualified 하이퍼링크를 사용해야 하지만 mod_rewrite URL manipulation 기능을 이용하여 상대 경로(relative URL) 사용하면서도 동일한 효과를 얻을 있다:

RewriteEngine on

RewriteRule ^/(.*):SSL$ https://%{SERVER_NAME}/$1 [R,L]

RewriteRule ^/(.*):NOSSL$ http://%{SERVER_NAME}/$1 [R,L]

rewrite 규칙은 다음과 같은 형태의 하이퍼링크를 사용할 있게 해준다:

<a href="document.html:SSL">

 

About Certificates

What are RSA Private Keys, CSRs and Certificates? [L]

RSA 개인키는 암호화되어있는 메시지를 복호화 하는데 사용하는 디지털 파일이다. RSA 개인키는 그에 대응되는 공개키가 존재하며, 공개키는 증명서를 통하여 공개적으로 배포되어서 다른 사람들이 공개키를 가지고 메시지를 암호화하여 공개키의 주인에게 전송하게 된다. Certificate Signing Request(CSR) 증명서를 발급받기 위한 요청서로서 사람의 공개키와 이름을 포함한다. CSR CA에게 보내면 CA CSR 실재로 사용할 있는 증명서(real Certificate) 만들어 주게 되는데, 증명서에는 CSR 보낸 사람의 공개키, 이름, 증명서를 발급한 CA 이름이 들어 있으며, CA 의해서 서명 된다. CA 알고 있는 브라우져는 증명서의 서명을 확인할 있으며, 서명이 확인되면 증명서에 들어있는 RSA 공개키를 얻게 된다. 브라우져는 이렇게 얻은 공개키를 이용해서 공개키의 주인만이 복호화할 있는 메시지를 전송한다.

Seems like there is a difference on startup between the original Apache and an SSL-aware Apache? [L]

Mod_ssl 적용한 Apache 시동하는 것은 SSL 개인키가 pass phrase 필요로 하는 경우 pass phrase 요구하는 dialog 먼저 실행되는 것을 제외하고는 일반적인 Apache 시동하는 것과 거의 유사하다.

Pass phrase 수동으로 입력하는 것은 서버 시스템의 부팅 시에 Apache 시동하는 경우 문제가 있는데, How can I get rid of the pass-phrase dialog at Apache startup time? 설명된 단계를 따름으로써 이를 해결할 있다.

How can I create a dummy SSL server Certificate for testing purposes? [L]

서버 증명서가 반드시 알려져 있는 public CA 의해 서명될 필요는 없으며, 자신의 공개키가 포함된 증명서를 서명하는데 자신의 개인키를 사용할 있다. 이렇게 생성된 증명서를 자신의 서버에 설치하게 되면, 서버에 접속한 브라우져에는 증명서를 받아들일 것인가를 묻는 경고 메시지가 보여지게 되며, OK 버튼을 누르면 서버에 접속할 있다.

Apache 설치할 make install 명령으로 Apache install하기 전에 먼저 Apache 소스 트리의 가장 상위 디렉토리에서 make certificate 명령을 이용하여 self-signed SSL Certificate 생성할 있다. 증명서는 30일간 사용할 있으며, 또한 암호화되어지지 않는다(, Apache 시동할 pass phrase 묻지 않는다).

BUT REMEMBER: YOU REALLY HAVE TO CREATE A REAL CERTIFICATE FOR THE LONG RUN! HOW THIS IS DONE IS DESCRIBED IN THE NEXT ANSWER.

Ok, I've got my server installed and not want to create a real SSL server Certificate for it. How do I do it? [L]

Real SSL Server Certificate 생성하기 위한 과정은 다음과 같다:

1. SSLeay 시스템에 설치하고 PATH 환경변수에 SSLeay 경로를 설정한다.

2. 다음의 명령으로 Apache 서버에 대한 RSA 개인키를 생성한다( 개인키는 3DES 암호화되어 PEM 포맷으로 변환되어진다):

$ ssleay genrsa -des3 -out server.key 1024

생성하는 과정에서 PEM Pass Phrase 입력하게 되는데, pass phrase 잃어버리지 않도록 기록해 두어야 하며, 결과로 얻어지는 server.key파일은 이후의 복구를 위하여 안전한 곳에 백업해 둔다. 다음의 명령어로 RSA 개인키의 자세한 내용을 있다:

$ ssleay rsa -noout -text -in server.key

다음의 명령으로 decrypted PEM 버전의 RSA 개인키를 생성할 수도 있다(권장되지 않는다):

$ ssleay rsa -in server.key -out server.key.unsecure

3. RSA 개인키에 대한 Certificate Signing Request (CSR) 생성한다(PEM 포맷으로 생성된다):

$ ssleay req -new -days 365 -key server.key -out server.csr

다음의 명령으로 CSR 자세한 내용을 있다.

$ ssleay req -noout -text -in server.csr

4. 생성된 CSR CA에게 보내어 CA 서명을 받음으로써 Apache 실재로 사용할 있는 증명서를 받는다. CSR 서명할 CA 선택에는 두가지의 옵션이 있다:

첫번째는 Verisign이나 Thawte 같은 상용 CA에게 CSR 서명을 받는 것으로서, 이경우에는 보통 해당 CA 홈페이지에서 CSR 입력한 요금을 지불하고 서명된 증명서를 받아서 server.crt 파일에 저장하면 된다. 상용 CA들의 자세한 정보는 다음의 사이트들을 참조한다:

Verisign http://digitalid.verisign.com/server/apacheNotice.htm

Thawte Consulting http://www.thawte.com/certs/server/request.html

CertiSign Certificadora Digital Ltda. http://www.certisign.com.br

IKS GmbH http://www.iks-jena.de/produkte/ca/

Uptime Commerce Ltd. http://www.uptimecommerce.com

BelSign NV/SA http://www.belsign.be

두번째 방법은 self-signed CA 사용하는 것이며, 경우 CSR 자신이 만든 CA 서명하게 된다. 다음 질문에서 자신의 CA CSR 서명하는 방법에 대하여 설명할 것이다.

다음의 명령으로 발급된 증명서의 자세한 내용을 있다:

$ ssleay x509 -noout -text -in server.crt

5. 위의 과정을 통하여 얻은 두개의 파일 server.key server.crt 위치를 httpd.conf 파일에서 각각 다음과 같이 지정해 준다:

SSLCertificateFile /path/to/this/server.crt

SSLCertificateKeyFile /path/to/this/server.key

server.csr 파일은 이상 필요하지 않다.

How can I create and use my own Certificate Authority (CA)? [L]

SSLeay 제공하는 CA.sh 스크립트를 가지고 Self-signed CA 생성하고 사용할 있으며, 스크립트를 이용하는 방법은 다음과 같다:

1. 다음의 명령으로 자신의 CA 대한 RSA 개인키를 생성한다( 개인키는 3DES 암호화되어 PEM 포맷으로 변환되어진다):

$ ssleay genrsa -des3 -out ca.key 1024

생성하는 과정에서 PEM Pass Phrase 입력하게 되는데, pass phrase 잃어버리지 않도록 기록해 두어야 하며, 결과로 얻어지는 server.key파일은 이후의 복구를 위하여 안전한 곳에 백업해 둔다. 다음의 명령어로 RSA 개인키의 자세한 내용을 있다:

$ ssleay rsa -noout -text -in ca.key

다음의 명령으로 decrypted PEM 버전의 RSA 개인키를 생성할 수도 있다(권장되지 않는다):

$ ssleay rsa -in ca.key -out ca.key.unsecure

2. CA RSA 키에 대한 self-signed CA 증명서(X.509 structure) 생성한다(PEM 포맷으로 생성된다):

$ ssleay req -new -x509 -days 365 -key ca.key -out ca.crt

다음의 명령으로 생성된 증명서의 자세한 내용을 있다:

$ ssleay x509 -noout -text -in ca.crt

3. 서명 작업을 위한 스크립트를 준비한다. ssleay ca라는 명령어는 몇몇 까다로운 요구사항을 필요로 하며, 또한 SSLeay 기본 설정에서는 사용자가 직접 ssleay ca 명령을 실행하는 것을 허용하지 않기 때문에 서명을 위한 스크립트가 필요하다. Mod_ssl sign.sh라는 이름의 서명을 위한 스크립트를 제공하며(pkg.contrib 디렉토리에 위치) 스크립트를 사용하기를 권장한다.

4. 다음의 명령으로 Apache 서버의 SSL 증명서를 생성하기 위한 CSR 서명한다:

$ ./sign.sh server.csr

CSR 서명함으로써 server.crt 파일을 얻게 되며, server.crt Apache 증명서로 사용하게 된다.

How can I change the pass-phrase on my private key file? [L]

다음의 명령어를 이용하여 개인키를 이전 pass-phrase 가지고 읽은 새로운 pass-phrase 다시 덮어쓴다:

$ ssleay rsa -des3 -in server.key -out server.key.new

$ mv server.key.new server.key

과정에서 두번의 PEM pass-phrase 요구하게 되는데, 첫번째에는 이전의 pass-phrase 입력하고 두번째는 새로운 pass-phrase 입력한다.

How can I get rid of the pass-phrase dialog at Apache startup time? [L]

Server.key 파일에 저장되어 있는 RSA 개인키는 보안 상의 이유로 암호화되어져 저장되어져 있기 때문에 Apache 시작하거나 재시동할 때마다 pass-phrase 입력 받기 위한 dialog 실행되게 된다. 만약 서버가 충분히 안전하다고 확신할 있는 경우 dialog 없앨 있다. 과정은 다음과 같다.

1. RSA 개인키로부터 암호화를 제거한다(원본 파일은 남겨둔다):

$ cp server.key server.key.org

$ ssleay rsa -in server.key.org -out server.key

2. server.key 파일을 루트만이 읽을 있도록 해준다.:

$ chmod 400 server.key

과정을 거쳐 server.key 암호화되지 않은 키를 가지게 되며, key 파일을 Apache 설치해 경우 이상 pass-phrase 요구하지 않게 된다. 그러나 이것은 보안상 상당한 위험을 가진다. 따라서 항상 파일의 접근 권한을 루트나 서버 사용자만이 파일에 접근할 있도록 설정해야 한다.

How do I verify that a private key matches its Certificate? [L]

개인키는 일련의 숫자들을 가지는데, 수들 2개는 공개키에 포함되며, 나머지는 개인키의 일부분이 된다. 공개키에 사용된 bit들은 증명서에 포함되며 숫자들은 CSR로부터 얻을 있다. 증명서의 공개키가 개인키의 public portin 일치하는가를 확인하기 위해서 증명서 파일과 개인키 파일을 다음의 명령으로 비교한다:

$ ssleay x509 -noout -text -in server.crt

$ ssleay rsa -noout -text -in server.key

키와 증명서 안의 modulus public exponent 부분이 서로 일치해야 한다. 그러나 public exponent 보통 65537이며 modulus 비교하는 것이 힘들기 때문에 다음과 같은 명령을 사용할 있다:

$ ssleay x509 -noout -modulus -in server.crt | ssleay md5

$ ssleay rsa -noout -modulus -in server.key | ssleay md5

명령은 매우 짧은 숫자들을 보여주며, 숫자들을 비교하면 된다. 만약 공개키와 개인키가 다르다면 숫자들이 다를 것이다. 특정 CSR 어느 키나 증명서에 대한 것인가를 알고자 때는 다음과 같은 명령을 사용한다:

$ ssleay req -noout -modulus -in server.csr | ssleay md5

Why does my 2048-bit private key not work? [L]

SSL 브라우져들과의 호환성을 위하여 기본 길이로 512 bit 1024 bit 사용한다. 1024 bit 이상의 길이는 일부 버전의 Netscape Navigator MSIE, 그리고 RSA사의 BSAFE 암호화 ToolKit 사용하는 일부 브라우져들과 호환되지 않기 때문에 1024 bit 길이를 가지는 키를 사용하는 것이 권장된다.

Why is client authentication broken after upgrading from SSLeay version 0.8 to 0.9? [L]

SSLCACertificatePath directive 지정한 경로에서 CA 증명서를 찾을 SSLeay hash symlink 통해서 증명서를 찾게 되며, hash 값은 ssleay x509 ?noout ?hash 명령으로 생성된다. 그런데 SSLeay 0.8에서 0.9 오면서 증명서에 대한 hash 계산하는데 사용되는 알고리즘이 변경되었다. 따라서 SSLeay 업그레이드한 먼저 모든 예전 hash symlink 삭제하고 새로운 hash symlink 생성해야 한다.

 

About SSL Protocol

Why has my webserver a higher load now that I run SSL there? [L]

SSL 강력한 암호화를 사용하며, 또한 HTTPS 통하여 어떤 페이지를 요청하는 경우 심지어 페이지 내의 이미지들까지 암호화된 채로 전송되기 때문에 HTTPS 전송량이 많은 경우 일반적인 Apache 서버에 비해 많은 서버 로드가 증가한다.

What SSL Ciphers are supported by mod_ssl? [L]

설치된 SSLeay 지원하는 거의 대부분의 SSL cipher 지원하며, 특히 최소한 다음과 같은 cipher들을 지원한다:

RC4 with MD5

RC4 with MD5 (export version restricted to 40-bit key)

RC2 with MD5

RC2 with MD5 (export version restricted to 40-bit key)

IDEA with MD5

DES with MD5

Triple-DES with MD5

다음의 명령으로 실제로 지원하는 cipher들의 목록을 있다:

$ ssleay ciphers -v

Why can't I use SSL with name-based/non-IP-based virtual hosts? [L]

문제는 닭과 달걀의 문제와 같다. SSL 프로토콜 레이어는 HTTP 프로토콜 레이어의 아래에 위치하여 HTTP encapsulate한다. SSL 연결(HTTPS) 이루어질 Apache/mod_ssl 클라이언트와 SSL 프로토콜 파라미터들을 협상해야 하며, 이를 위해 mod_ssl 가상서버(virtual server) 설정(예를 들어 cipher suite server certificate ) 참조해야 한다. 그러나 올바른 virtual server 찾기 위해 Apache Host HTTP heaer field 알아야 하며, 이를 위해 HTTP request header 읽혀져야 한다. 과정은 SSL handshake 끝나기 전에는 수행되지 않는데 과정이 수행되어야 얻어지는 정보를 이미 SSL handshake 단계가 요구하였기 때문에 이러한 문제가 발생하게 된다.

When I use Basic Authentication over HTTPS the lock icon in Netscape browsers still show the unlocked state when the dialog pops up. Does this mean the username/password is still transmitted unencrypted? [L]

아니다, username passwd 이미 암호화되어 전송되어진 것이다. Netscape 브라우져의 자물쇠 아이콘은 SSL/TLS 레이어와 정확히 동기화되지 않으며, 해당 페이지의 첫번째 데이터가 전송되는 시점에서야 잠김 표시로 전환되는 것이다. Basic Authentication HTTP 레이어의 기능이며 HTTP 레이어는 SSL/TLS 레이어 위에 위치한다. 따라서 HTTPS 프로토콜에서 어떠한 HTTP 데이터의 통신이 이루어지기 위해서는 반드시 이전에 SSL/TLS 레이어가 handshake 단계를 수행하고 암호화된 통신으로 전환되어야만 한다. 따라서 인증 단계에서 자물쇠 아이콘이 잠김 상태가 아니더라도 username passwd 이미 암호화된 상태로 전송되게 된다.

신고
Posted by Golmong

댓글을 달아 주세요