http://www.emh.co.kr/content.pl?mime 에서 참조

아스키와 바이너리 (ASCII, Binary)

마임을 이해하기 위해서는 아스키와 바이너리에 대해 알고 있어야 합니다. 컴퓨터는 0 과 1로 이뤄진 이진수만 이해할 수 있습니다. “바이너리(binary)"라는 단어가 "이진의”, “이진수의"라는 의미입니다.

컴 퓨터에서 ‘ㄱ,ㄴ,ㄷ’ 이나 ‘a, b, Z, T,..’ 등의 문자를 표시하려면 각각의 문자를 숫자로 지정해줄 필요가 있습니다. 즉 ‘a는 십진수로 97이다’, ‘z는 122다’ … 이런 식으로 규정을 해야 했습니다. 이렇게 규정을 하면 그 값을 이진수로 변환해서 컴퓨터가 각 문자를 식별할 수 있기 때문입니다.

컴퓨터 등장 초기에는 오늘날의 피씨처럼 공통된 표준이 정립되어 있지 않았습니다. 각자 자기 식으로 하드웨어를 제작했고 거기에 맞게 소프트웨어를 만들었습니다. 각 문자에 해당하는 값 역시 컴퓨터마다 달랐습니다. 이렇다 보니 서로 다른 메이커에서 만든 컴퓨터 간에 데이타를 교환해야 할 필요가 생긴 경우 굉장히 곤란한 상황이 발생합니다. A 컴퓨터에서는 ‘abc’라고 저장한 것인데 B 컴퓨터에서 열어보면 ’!#F’라고 열린다든지 하는 일이 생겼습니다.

이에 "ANSI"라는 표준을 정하는 곳에서 각 문자에 해당하는 숫자값을 하나로 통일하자는 목적 아래 "ASCII"라는 표준을 만듭니다. "ASCII"는 "American Standard Code for Information Interchange"의 약자입니다. 단어 뜻대로 정보 교환을 위한 미국 표준 코드입니다.

컴퓨터가 정보 처리를 할 때 사용하는 기본 단위는 바이트(byte)입니다. 바이트는 8비트를 줄인 말입니다. 이런 것이 1바이트입니다.

11001101

8자리의 이진수를 1바이트라고 하는 것입니다. 1바이트는 십진수로 고치면 최소 0(00000000)부터 최대 255(11111111) 사이의 값이 됩니다. ANSI는 0부터 255까지의 숫자를 알파벳과 특수문자에 하나하나 대응시켰습니다. a는 97, W는 87 ,… 이런 식으로 문자 마다 값을 지정을 했습니다. 그런데 왜 ‘a’를 1이나 2처럼 앞의 숫자로 할당하지 32라는 큰 숫자로 지정했을까요? 그것은 제어 문자(control character)라는 것이 필요했기 때문입니다. 당시 컴퓨터 단말기의 표준격인 TTY에 쓰이던 제어 문자를 위해 앞의 0-32를 남겨둬야 했습니다. 제어 문자는 폰트가 바뀐다든지, 전송의 끝을 알리는 문자 같은 특수한 작업, 기능, 이벤트를 알려주는 특수 문자입니다.

제어 문자에 할당한 0-32 다음 값인 33부터 화면상에 보여지는 보통의 문자를 짝지운 것입니다. 아스키 33은 !이고, 34는 ”, 35는 #, … 이렇게 하면 0부터 127까지 사용해서 모든 ‘문자’를 다 표시할 수 있습니다.[1] 따라서 8비트 중 128 부터 255까지는 사용할 필요가 없었습니다. 이것을 이진수로 바꿔보면 1바이트 이진수의 맨 첫 번째 자리는 사용할 필요가 없다는 것이 됩니다. 1111111가 127이니까요. 그래서 아스키 문자의 이진수 값은 첫 숫자가 0입니다. 이것을 잘 기억해 두세요.“7비트 아스키 문자"라는 용어는 그런 원리로 등장한 것입니다.

이제 아스키가 뭔지, 왜 아스키 문자는 7비트인지, 그리고 첫 문자 값을 33으로 설정했는지 등이 이해되시죠? 이것이 도대체 마임과 무슨 상관이 있는가.

문제는 컴퓨터 사이에서 이동되는 파일이 모두 다 아스키 문자로 이뤄진 텍스트 파일은 아니였다는 데서 출발합니다.

인코딩과 디코딩

보 통의 텍스트 파일을 보내고 받는 데는 ASCII라는 공통된 표준에 따르기만 하면 아무 문제가 없었습니다. 그런데 네트웍을 통해 아스키 파일이 아닌, 즉 ‘바이너리’ 파일을 보낼 필요가 생깁니다. 바이너리 파일은 음악 파일이나 그래픽 파일, 무비 파일, 또는 (포매팅 정보가 담긴) 워드 프로세서로 만든 문서 파일 등입니다. 이들은 모두 8자리 이진수의 첫 번째 자리가 0으로 한정된 것이 아닌, 8비트 모두를 사용한다는 특징을 갖습니다. "8비트 데이타"입니다. (아스키 문자는 "7비트 데이타.”)

이메일이나 기타 네트웍 상에서 데이타를 교환하는 시스템은 최초 아스키 문자로 이뤄진 파일만을 전송하는 것을 전제로 제작되었기 때문에 첫 번째 숫자가 1인 데이타가 섞여 있는 이들 8비트 바이너리 데이타를 제대로 전달할 수가 없었습니다. 바이너리 파일을 기존의 시스템 상에서 문제 없이 전달하기 위해서는 이들을 다시 “아스키 문자 파일” 바꾸어서 전달할 필요가 있었습니다. 즉, ‘바이너리’를 ‘텍스트’로 변환해야만 했습니다.

그것을 인코딩(encoding)이라 합니다. 바이너리 파일을 텍스트 파일로 바꾸는 것입니다. 디코딩(decoding)은 인코딩 된 텍스트 파일을 다시 바이너리 파일로 변환하는 해독 과정을 의미합니다.

그 러면 초기 인코딩 방식의 대표적 표준인 “UUEncode(Unix-to-Unix Encode)” 방식의 원리를 통해 인코딩의 원리를 간단하게 살펴 봅시다. 어떤 바이너리 파일 데이타 중 3개의 바이트를 가져 왔을 때 다음과 같았다면,

10011100 00110011 11110000

8자리씩 총 24개의 비트입니다. 24개이므로 이것을 다시 6개짜리 4개로 바꿀 수 있습니다.

100111 000011 001111 110000

그 다음, 첫 두 자리에 0을 붙입니다.

00100111 00000011 00001111 00110000

이제 전부 첫 번째 숫자가 0이 되어서 조금더 아스키 코드에 가까와졌습니다.

그 다음, 각각에 십진수 32를 (이진수 100000) 더합니다. 조절 문자가 아닌, 화면에 보이는 보통의 문자 값으로 바꾸기 위해서입니다. 그렇게 하면 위 데이타는,

01100111 01000011 01001111 01110000

이 됩니다. 이제 이들은 모두 알파벳이나 기타 기호 등의 보통의 아스키 문자로 바꿀 수가 있게 됩니다.

이 과정을 거친 바이너리 파일은 아스키문자 파일이 되어서 종래의 이메일 시스템 등을 타고 아무 탈없이 전달될 수가 있습니다. 인코딩 된 바이너리 파일을 열어보면 이상한 문자가 가득 뜨는데 그런 이유입니다.

그러면 마임(MIME)이란?

MIME은 Multipurpose?Internet?Mail?Extensions? 의 약자로 일종의 인코딩 방식입니다. MIME은 이메일과 함께 동봉할 첨부 파일(attachment file)을 텍스트 문자로 전환해서 이메일 시스템을 통해 전달 하기 위해 개발되었기 때문에 이름이 “Internet Mail Extension"입니다. 이제는 웹을 통해서 여러 형태의 파일을 전달하는 데 두루 쓰이고 있습니다.

왜 UUEncode 방식이 있는데 MIME이란 인코딩이 또 나타나게 되었을까요? UUEncode 방식에는 단점이 있었습니다. 문서 끝 부분의 공백이 사실은 공백이 아니라 변환되어야 할 값인데 공백을 무시하는 시스템의 경우엔 UUEncode 파일을 원형 그대로 전달 받을 수 없었다는 것 등의 단점이 있었습니다. 그래서 UUEncode 방식을 대폭 보강한 새로운 인코딩 방식이 등장하게 되었고 그것이 MIME입니다. MIME은 특히 기존의 UUEncode 방식에서는 없었던 파일 포맷(또는 Content-type) 정보도 함께 담을 수 있습니다. ‘지금 전달하는 이 파일은 GIF 파일이다.’, ‘MOV 파일이다.’처럼 그 파일의 종류를 나타내는 딱지를 붙일 수 있었습니다. 이렇게 MIME 에서 사용하는 인코딩 방식을 "base64"라고 합니다. 방식은 위에서 본 것과 유사합니다. 8비트 3개를 6비트 4개로 바꿔서 적절한 변형을 합니다.

이렇게 해서 텍스트만 전달될 수 있는 기존의 이메일 시스템에서도 바이너리 파일들을 자유롭게 주고 받을 수 있게 되었습니다. 8비트 바이너리 파일을 7비트의 아스키문자 파일로 바꿔주는 것입니다.

마임의 타입(Type)

마 임으로 인코딩 한 파일은 "Content-type” 정보를 파일의 앞 부분에 담고 있습니다. 컨텐트 타입에는 여러 가지가 있습니다. 이런 얘기를 들어 본 적이 있을 것입니다. ‘어떤 마임 타입 (MIME type)이 웹브라우져에서 지원된다, 안된다.’ 그것은 ‘특정 컨텐트 타입의 파일을 웹 서버로부터 전달받아서 웹브라우져가 열 수 있다, 아니다.’라는 의미입니다. 웹 브라우져가 웹 서버에 접속해서 html 문서를 요청하면서 html 문서 내에 담긴 이미지 태그내에 지정된 패쓰로부터 이미지 파일도 가져 옵니다. 이 때 그 패쓰에 있는 파일이 웹 브라우져에서 지원되는 마임 타입이라면 웹 브라우져 내에서 열 수 있습니다. .jpg, .gif 파일 등은 브라우져 내에서 바로 뜨는 것입니다.(모자익 웹브라우져 당시만 해도 이것은 획기적인 기능이었습니다. 모자익 이전의 웹브라우져는 .jpg, .gif 마임 타입을 직접 지원하지 않았기 때문에 외부 그래픽 프로그램이 구동되면서 이미지를 보여 줬습니다)

초기 웹 브라우져는 표준적인 마임 타입들(.gif, .jpg, .mov,…)은 무리 없이 열렸지만 그렇지 않은 유형은 그 파일을 열어줄 프로그램을 손수 지정해야 했습니다. 웹 브라우져 셋팅에 파일 포맷 별로 외부 프로그램을 연결하는 부분이 있었습니다. 그런데 마이크로소프트가 웹 브라우져를 불공정하게 운영체계에 통합하면서 마임 타입 지정이 OS 차원으로 넘어 갑니다. 윈도우즈 탐색기를 열어서 [보기 > 폴더옵션] 메뉴에 보면 아래 그림같이 “파일 형식"이라는 탭이 있습니다. 여기에서 파일 확장자나 마임 타입 별로 구동될 프로그램을 설정하게 되어 있습니다. gif 파일의 경우를 한 번 볼까요?

mime

"내용 형식”(=“Content-type”)이라는 단어 옆에 “MIME"이라고 되어 있죠? MIME 타잎이 어떻게 설정되어 있는지를 자세히 봅시다. 가운데에 슬래쉬가 / 있고 슬래쉬 앞 부분에는 파일의 종류("image”) 슬래쉬 뒷 부분은 파일의 포맷을(“gif”) 나타내고 있습니다. 이렇게 마임 타입은 “파일종류/파일포맷” 형태로 정의합니다.
몇 가지 예를 들어 봅시다.

application/msword
text/html
application/pdf
audio/mpeg

위 의 대화상자를 보면, 마임 타입 밑에 연결 프로그램으로 인터넷 익스플로러가 설정되어 있습니다. 따라서 gif 파일을 데스크탑 상에서 더블 클릭할 때도 익스플로러를 통해 열립니다. 또는 웹 문서에 포함된 gif 파일은 바로 웹 브라우져내에서 열립니다. image/gif 마임 타입을 다른 그래픽 프로그램(예컨데 페이트샵 프로)과 연결하면, gif 파일이 포함된 웹 문서가 열릴 때마다 페인트샵 프로가 뜹니다. 데스크탑상에서 더블 클릭할 대도 페인트샵 프로가 뜨면서 엽니다.

[1] 을 이용해서 아스키 값을 출력해주는 코드는,
#!/usr/bin/perl

foreach (33..127) {
$letter = chr;
print qq|$_: $lettern|;
}

아스키 값 표입니다
33!34"35#36$37%38&39’40(41)42*43+44,45-46.47/48049150251352453554655756857958:59;60<61=62>63?64@65A66B67C68D69E70F71G72H73I74J75K76L77M78N79O80P81Q82R83S84T85U86V87W88X89Y90Z91[9293]94^95_96`97a98b99c100d101e102f103g104h105i106j107k108l109m110n111o112p113q114r115s116t117u118v119w120x121y122z123{124|125}126~

http://www.hanb.co.kr/network/view.html?bi_id=1505 에서 참조

제공 : 한빛 네트워크
저자 : Juliet Kemp
역자 : 고현영
원문 : Step by Step: Configuring SSL Under Apache

Introduction

보안 웹 서버에서, 클라이언트는 연결 대상을 알고 트랜잭션(역자주: 정보의 교환)이 암호화되어 보안상 안전하다는 환경하에서 서버에 연결하게 된다. 보안이 유지되는 트랜잭션을 수행하기 위한 최선의 방법은 Apache 2 – 리눅스 웹 서버 소프트웨어의 최신 버전, Secure Sockets Layer- 보안 채널 프로토콜을 이용하는 것이다. 차세대 보안 레이어인 Transport Layer Security(TLS) 는 기본개념에서는 SSL과 동일하다. 그러므로 여기서는 SSL을 이용하는 방법을 언급하고자 한다.

SSL은 웹 브라우저와 웹 서버간의 트랜잭션을 암호학적으로 안전하게 보호하기 위한 프로토콜이다. 대부분의 경우 서버쪽만 인증 대상이 된다. 즉 클라이언트는 서버가 누구인지 알 수 있지만 그 반대는 알 수 없다. 왜냐하면 한번 연결이 되면, 양쪽 단은 보안상 안전하게 되고, 클라이언트와 서버는 key material(핵심 데이터)에 접근할 수 있다. 계속 같은 클라이언트와 트랜잭션하게 되면 서버는 클라이언트가 누구인지 더 이상 고려할 필요가 없다. 누가 생각해도 이것은 당연하게 보인다. 클라이언트 인증에 대해 고려하고자 한다면, 클라이언트 SSL 인증서(다른 비슷한 방법으로는 htaccess, Kerberos가 있다)를 사용할 수 있지만 여기서는 다루지 않겠다.

우리가 클라이언트의 입장이 되어 보자. 클라이언트로서 우리는 암호화된 데이터를 보내고자 할 때 보내고자 하는 사람(서버)에 대해 알아야 한다. 따라서, 서버는 인증이 되어야 한다. 또한 third party(제 3자)가 우리가 보내는 데이터에 대해 접근하지 못하도록 신경서야 한다. SSL은 이 두 가지 보안 사항에 대하여 지원을 한다.

SSL의 수행 절차는 다음과 같다.

  1. 클라이언트는 웹 서버에 접속을 하고 자신이 사용할 수 있는 암호화 방법들을 알려준다.
  2. 서버는 클라이언트가 수행할 수 있는 암호화 방법 중 가장 안전한 방법을 택하여 신뢰할 수 있는 인증 기관(예. Verisign)에서 서명한 인증서를 클라이언트쪽으로 보낸다. 이 인증서에는 인증서 이름과 공개키가 들어있다.
  3. 클라이언트는 CA(역자주: Certificate Authority:인증기관)를 통해 받은 인증서를 검증한다. 실제적으로는 클라이언트는 CAs(인증기관들)에 대한 정보를 로컬(역자주: 예. 디스크)상에 가지고 있다. 이렇게 하는 이유는, 네트워크를 통해 CA에 접속하여 인증서에 대한 검증을 하는데 따르는 시간적인 부담을 덜기 위해서다.
  4. 클라이언트는 서버의 공개키로 암호화된 random number(임의의 수)를 서버로 되돌려 준다. 이 random number는 오직 클라이언트만 알고 있다. 서버는 클라이언트가 보낸 것을 자신의 개인키로 복호화한다. 이렇게 함으로써 third-party의 접근을 막을 수 있도록 안전함을 보장한다.
  5. 서버와 클라이언트는 이 random number를 가지고 트랜잭션을 암호화하기 위한 key를 생성한다.

우리가 관심가질 부분은 위의 방법이 클라이언트 측면에서 좀 더 명확해 지고, 트랜잭션이 좀 더 쉬워지게 하는 것이다.

SSL을 사용해서 Apache를 설정하는 것은 간단한 것이지만, 몇 가지 절차를 밟아야 한다. 이 기사는 CA에 의해 서명된 인증서를 얻는 방법, Apache 컴파일, Apache 설정에 대해 다루고 있다. 여기서는 mod_ssl을 이용한 Apache2를 가지고 설명할 것이다. Apache SSL(SSL을 지원하는 Apache)도 역시 가능하지만 구식 기술이므로 mod_ssl을 사용하도록 하겠다.

Creating a Certificate

첫 번째 단계는 인증서 생성이다. 암호문(passphrase)이 있던 없던 인증서를 생성할 수 있다. 암호문를 사용할 때의 가장 큰 단점은 웹 서버를 시작할 때마다 암호문을 넣어야 한다는 것이다. 따라서 자동적으로 부팅이 되지 않는다. 예를 들어 전원을 끈 이후에 재 기동할 때 암호문을 넣어주어야 한다는 것이다. 여러분이 구성하는 환경에 따라 이것은 중요한 요소가 될 수 있다.

이론적으로, 암호문를 사용할 때의 장점은 보안을 강화한다는 것이다. 하지만 실제적으로는 그렇게 크게 강화시키지 못한다. 누군가 개인키를 읽거나 복제할 수 있다면, 그 사람은 이미 root 레벨로써 시스템에 접근할 수 있고 암호문을 얻을 수 있다는 것을 의미한다. 예를 들어 ‘keylogger’ 같은 프로그램을 사용한다면 말이다. 암호문은 script kiddies 스크립트 키디(역자주: 해킹 툴을 사용하는 해킹 초보자들을 지칭한다)에 대해서야 보호할 수 있겠지만, 숙련된 해커를 막을 수는 없다. 대부분의 사람이 한 가지 암호문만 사용하지 않는 이유는 이런 것 때문일 것이다.  

테스트 목적으로 혹은 소규모의 LANs에 대해 self-signed(자기 서명)한 인증서를 사용할 수 있다.(역자 주: self-signed certificate은 말 그대로 자기가 자신을 서명했다는 것으로 자기가 자기를 신뢰한다는 뜻이다. 보통의 경우 어떤 인증서를 신뢰하기 위해서는 그 보다 상위의 신뢰된 CA가 서명을 한다. 보통 Root 인증서가 self-signed certificate 이다. ). 이 인증서는 다음과 같은 명령으로 발행(issue)할 수 있다.

openssl req -new -x509 -days 365 -sha1 -newkey rsa:1024 
-nodes -keyout server.key -out server.crt 
-subj '/O=Company/OU=Department/CN=www.example.com'

옵션에 대해 살펴보자.

  • -x509 는 인증서가 요청(request)되었다는 의미보다는 인증서가 요구(required)된다는 것을 언급한다.
  • -days 365 는 인증서가 일년 후에 만료된다는 것이다. 기간을 확장할 수 있다. 만료기간을 늘리고 싶다면 만료시점을 기억했다가 필요할 때 갱신(renew)하면 될 것이다.
  • -sha1 SHA1 암호방법을 사용했음을 의미한다.
  • rsa: 1024 RSA의 키 길이를 1024 bit로 두었다는 뜻이다(역자주: 요즘은 1024bit의 안정성 때문에 2048bit로 가고 있는 추세이다. 하지만 암호화 연산 시간이 3~4배 늘어난다).
  • -nodes 암호문을 쓰지 않음을 의미한다.
  • -keyout, -out 인증서와 키의 저장위치를 지정한다. 키는 반드시 root 권한만이 읽을 수 있어야 한다. 반면, 인증서는 누구라도 읽을 수 있게 한다. 즉 Apache를 사용하는 유저가 읽을 수 있어야 한다.
  • -subj 이 플래그는 회사 이름, 부서 이름, 웹 사이트 주소를 설정한다. 이것을 그냥 두면 프롬프트로부터 입력을 받게 된다. CN은 여러분이 적은 웹 사이트의 주소와 반드시 일치해야 한다. 그렇지 않으면 인증서가 일치하지 않게 되고 사용자가 접속할 때 경고 메시지를 받게 된다. 접속암호를 사용하지 않았나 다시 한 번 확인해 보자.

웹 서버에서 self-signed 인증서를 사용할 때의 문제점은 이 웹 서버에 접속하는 어떤 브라우저도 인증서를 발급한 CA를 인식할 수 없다는 것이다. 즉 사용자가 신뢰할 수 있는 인증서인지 아닌지를 판단해야 한다는 것이다. 대부분의 경우 self-singed 인증서를 사용하는 것은 차선책 일 것이다. 그렇지만 테스트 용도이고, 소규모의 LANs이라면 CA로부터 인증서를 사기 위해 돈을 지불하는 것은 쓸데없는 일이다(역자주: 인증서를 사기 위해서는 돈을 지불해야 한다. 우리 나라에서 개인이 인터넷 뱅킹을 위해 사용하는 인증서는 무료이지만 다른 목적으로 사용하는 인증서들은 보통 돈을 주고 구입한다.).

대부분의 사용자들은 외부 고객과의 거래를 위해 신뢰된 인증기관인 Verisign(가장 큰 시장 규모를 가진)이나 다른 인증기관에서 인증서를 구입하는 것도 좋을 것이다. 대부분의 브라우저들은 신뢰된 CAs에 대한 정보를 이미 가지고 있기 때문에 클라이언트가 접속을 할 때 해당 CA에 접속하여 웹 서버의 인증서를 검증해 줄 것이다. 이런 것은 엔드유저가 접속과 관련된 처리에 따른 부가 작업을 줄여줄 것이다. 또한, 인증서 검증을 통해 여러분이 운영하는 사이트가 신뢰받는 사이트임을 엔드유저에게 알려준다.

CA로부터 서명된 인증서를 얻기 위해서는 먼저 키쌍을 생성하고 인증서 요청과 관련된 정보를 생성해야 한다.

openssl req -new -sha1 -newkey rsa:1024 -nodes  
-keyout server.key -out www.example.com.csr  
-subj '/O=Company/OU=Department/CN=www.example.com'

앞에서 봤던 예제랑 비슷하지만 여기서는 –x509 옵션을 사용하지 않았다. 따라서 인증서생성이 아닌 key와 인증서 요청에 대해 생성할 것이다. 만약 CN이나 기타 항목을 적을 때 명령 줄이 아닌 다른 방법을 쓴다면 email 주소나, 암호를 적어서는 안 된다.

서버 키(server.key-root에 의해서만 읽혀져야 한다)는 웹 서버에 둔다. 요청(www.exapmle.com.csr)은 CA에게로 간다. 원한다면 요청 파일(request file)을 사용할 수도 있지만, 도메인을 사용하는 것이 CA편에서는 처리하기에 편하다.

다음 단계는 CA에게 요금을 지불하고 www.example.com.csr 파일을 보내는 것이다. 여러분이 인증서 요청에 대해 필요한 정보를 잘 적었다면 CA는 가능한 한 빨리 응답을 줄 것이다. 여러분이 선택한 CA의 웹 페이지에서 인증서 발급에 관한 절차를 설명해 줄 것이다. 여러분은 인증서를 PEM format으로 바꾸어야 할지도 모르지만, Verisign 인증서의 경우에는 그럴 필요가 없다.

만약 여러분이 PEM format의 인증서를 받았다면, 이름을 server.crt 로 바꾸자(꼭 필요한 절차는 아니지만 Apache에서의 작업의 편의성을 위해 하자). 그리고 받은 인증서를 검증해 보자.

openssl verify -CAfile /path/to/trusted_ca.crt -purpose sslserver server.crt

다음으로, 다음의 두 명령의 결과가 똑같은지 확인해 보자. 즉, 여러분이 가진 개인키에 대응되는 인증서인지 확인해 보는 것이다.

openssl x509 -noout -modulus -in server.pem | openssl sha1
openssl rsa  -noout -modulus -in server.key | openssl sha1

생성한 개인키(server.key)와 인증서(server.crt)를 /etc/apache2/ssl에 설치하자. 여러분이 구성한 Apache2의 구성 디렉토리(config directory)는 이것과 다를 수도 있다. 그러면 그곳에 설치하자. 위에서 언급한 바와 같이 server.key는 root권한을 가진 자만이 읽을 수 있게 해야 한다는 것을 명심해라(역자주: 이것은 집 열쇠는 집 주인이 가져야만 한다는 것에 비유를 들 수 있다). 반면 서버의 인증서는 누구나 읽을 수 있도록 해야 한다. 대신 인증서의 소유와 쓰기권한은 오직 root권한을 가진 자만이 가능해야 한다(역자주: 개인키와 인증서에 대한 개념은 PKI의 기본 개념을 참고하도록 한다.)

Compiling Apache with SSL

인증서가 만들어 졌다. 이제는 인증서를 사용하기 위해 서버를 세팅해 보자.

대부분의 사람들에게, Apache2와 Apache2의 모듈을 다루기 위한 가장 좋은 방법은 여러분의 배포 패키지 운영 시스템(distribution’s package management system)을 이용하는 것이다. Debian Apache2 웹 서버는 SSL 모듈이 가능하도록 나와 있지만 자동적으로 기능이 활성화되어 있지는 않다. 이 모듈을 활성화 하기 위해서는 a2enmod ssl 을 실행해야 하고 웹 서버를 다시 기동해야 한다.

일반적인 방법은 /etc/apache2/apache2.conf(별칭: httpd.conf )에 다음을 삽입하는 것이다. Include /etc/apache2/mod_ssl.conf

여러분의 mod_ssl.conf 설정에 따라 위의 위치는 바뀌어야 할 것이다. 그리고 웹 서버를 다시 기동한다.

여러분이 Apache2를 소스에서 컴파일하기 바란다면, SSL에 대한 지원을 하게 했는지 안 했는지의 여부보다, 여러분이 전에 사용했던 옵션이 컴파일에 더 큰 영향을 준다. apache2 -l 명령으로 확인해 봐라. 재컴파일이 필요하다면 여러분이 전에 사용했던 모든 옵션에 추가적으로  –enable-ssl 과 –enable-setenvif(이 옵션은 일부 Internet Explorer와의 호환을 위한 것) 옵션을 넣고 ./configure 를 실행해라. 그리고 make를 이용해서 설치해라. 보통 make install  명령을 실행하면 설치가 된다. 설치할 때 소유자와 퍼미션이 올바르게 설정되어 있는지 확인하는 것도 잊지 말기 바란다.

Configuring Apache with SSL

이제는 Apache2의 환경 구성을 해야 한다. 여러분이 보안 서버(port 443이용)와 일반(regular) 서버(port 80 이용)를 동시에 운영하고 싶다면 다음과 같이 한다. 먼저 서버가 두 포트에 대해 리슨하도록 구성해야 한다. /etc/apache2/ports.conf(debian 인 경우에는 apache2.conf에 들어 있다.)를 수정하거나 /etc/apache2/apaceh2.conf에 다음의 라인을 넣는다.

Listen 80
Listen 443

다음으로, /etc/apache2/sites-enabled/yoursite 을 수정하여 SSL 설정을 사용하도록 한다. VirtualHosts를 사용해서 일반 서버와 보안 서버를 분리해서 관리하는 것도 시스템 관리적인 측면에서 좋은 방법이다. VirtualHosts 섹션(예를 들어, ServerAdmin)을 제외한 다른 모든 구성과 관련된 사항은 VirtualHosts 양쪽 모두에 적용을 해야 한다. 다음의 박스 안의 내용을 여러분의 설정 파일에 넣도록 해라.

# =================================================
# SSL/TLS settings
# =================================================
NameVirtualHost *:443



    DocumentRoot "/local/www/ssl_html"

    SSLEngine on
    SSLOptions +StrictRequire

    
        SSLRequireSSL
    

    SSLProtocol -all +TLSv1 +SSLv3
    SSLCipherSuite HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM

    SSLRandomSeed startup file:/dev/urandom 1024
    SSLRandomSeed connect file:/dev/urandom 1024

    SSLSessionCache shm:/usr/local/apache2/logs/ssl_cache_shm
    SSLSessionCacheTimeout 600    

    SSLCertificateFile /etc/apache2/ssl/server.crt
    SSLCertificateKeyFile /etc/apache2/ssl/server.key

    SSLVerifyClient none
    SSLProxyEngine off

    
        AddType application/x-x509-ca-cert      .crt
        AddType application/x-pkcs7-crl         .crl
    

    SetEnvIf User-Agent ".*MSIE.*"   
      nokeepalive ssl-unclean-shutdown   
      downgrade-1.0 force-response-1.0

위의 구성에 대해서 간략히 설명하겠다.

  • SSLEngine은 반드시 활성화해서 서버가 SSL을 사용하도록 한다.
  • DecumentRoot는 가상 호스트(virtual host)에 대해 root directory를 설정한다. 이렇게 함으로써, 보안상 접근불가한 컨텐트(content)와 일반 컨텐트를 구별한다.
  • SSLRequireSSL은 여기서의 가상 호스트에 대해 SSL을 사용하도록 규정한다. 즉, 사용자가 일반 HTTP 요청으로 이 호스트에 접속하지 못하게 한다. 이 때문에 우리가 ‘보안 root directory’와 ‘일반 root directory’를 구별하는 것이다.
  • SSLProtocol은 TLS v1.0과 SSL v3.0을 제외한 모든 프로토콜을 비활성화한다. 현재 웹 서버에 대해서는 이 정도만 설정하면 된다.
  • SSLCipherSuite는 HIGH, MEDIUM 레벨의 보안 암호 집합(security cipher suites)을 사용하도록 설정한다. SHA1은 MD5보다 보안상 더 안전하므로 SHA1을 더 추천한다.
  • SSLCertificateFile과 SSLCertificateKeyFile은 여러분의 인증서와 key파일의 위치를 지정해야 한다.
  • SSLVerifyClient는 클라이언트 인증을 사용하지 않는다면 설정하지 않는다.

포트 80으로 일반 서버를 돌리기 위하여 환경 파일에 다음 박스 안의 내용을 넣도록 한다.

NameVirtualHost *:80


    DocumentRoot "/local/www/html"
    # Host-specific directory setup, options, etc
    # Most of these options are likely to be set outside the VirtualHosts
    # sections.

환경 설정 파일을 수정하고 저장한 뒤, 웹 서버를 다시 시작한다. 여러분이 인증서를 생성할 때 암호를 사용했다면, 서버를 다시 시작할 때 인증서 암호를 넣어야 할 것이다.

Testing

여러분의 웹 서버에 index.html을 만들어 보자(물론 처음 접속했을 때 뜨는 화면이다).

웹 브라우저의 주소창에 https://www.yoursite.com 을 넣어보자. 그러면 SSL접속이 이루어진 것과 전송된 페이지를 볼 수 있을 것이다. Self-signed 인증서를 사용했다면, 여러분의 브라우저는 서버에 대해 검증할 수 없다는 경고창을 띄울 것이다. 여러분은 인증서를 보고 그 인증서를 사용하는 서버에 대해서 접속을 허락할지를 결정해야 한다. 인증된 기관의 인증서를 사용한다면, 이런 경고는 뜨지 않을 것이다.
‘http://’를 사용해서 보안된 컨텐트에 접속하지 않도록 해라. 그렇게 하면 에러 메시지가 나온다.  

Troubleshooting

생각했던 되로 진행이 되지 않으면 먼저 ps -a | grep apache 명령을 사용하여 apache 서버가 돌아가는지 확인해라. 창에 아무 메시지도 나오지 않는다면 apache를 재 기동해서 터미널에 나오는 에러 메시지를 확인하도록 해라.

여러분의 키와 인증서의 퍼미션이 올바르게 설정되어 있는지 확인해라. 또한 테스트 HTML 페이지와 부모 디렉토리의 퍼미션도 올바르게 설정되어 있는지 확인해라.

그 다음으로 로그를 확인해라. 주 서버 로그와 여러분이 설정한 SSL log를 둘 다 확인하도록 해라. 유용한 정보를 얻을 수 없다면 Apache2 구성 파일의 로그 레벨을 “debug”로 바꾸어서 Apache2를 재 기동하고 테스트를 해 보자. 이렇게 하면 더 많은 정보를 얻을 수 있다.

포트 80으로 일반 웹 서버를 기동하고 있다면 ‘https://’가 아닌 ‘http://’로 테스트 페이지를 접속해 봐라. 이렇게 하면 문제가 웹 서버 문제인지 아니면 SSL 접속문제인지를 파악하는데 도움을 준다. 위에서 구성한 설정을 확인해라. 웹 서버의 root directory는 ‘http://’와 ‘https://’에 대해 서로 다르다. 따라서 여러분은 같은 컨텐트에 접속할 수 없다(접속해서도 안된다). 여러분의 테스트 페이지가 ‘http://’ 의 root directory에서 잘 동작하고 ‘https://’의 root directory에서 잘 동작하지 않는다면 문제의 핵심을 파악할 수 있을 것이다.

SSL 커넥션 문제였다면, 유용한 툴로는 s_client가 있다. 이것은 TLS/SSL 커넥션 문제에 관한 진단 툴이다. /usr/bin/openssl s_client –connect localhost:443 명령을 하면 간단하게 이 툴을 사용해 볼 수 있다. 다른 많은 옵션도 있는데 이것은 문서에서 확인해 보도록 해라. 여러분이 에러 메시지를 받았다면, 문제를 찾는데 도움이 될 것이다.

Conclusion

축하한다! 여러분은 최신의 브라우저를 통해 검증할 수 있는 인증서를 가진 보안 서버를 갖게 되었다.

저자 Juliet Kemp는 어떤 역경을 만나더라도 극복할 수 있는 방법을 찾아낸 6년 경력의 Linux system 경험자이다. 그녀는 현재 UK(United Kingdom)의 런던 소재의 Imperial College의 Astrophysics group의 system admin으로서 Linux+Solaris network와 그 사용자에 대해 책임을 맡고 있다.

역자 고현영님은 광운대학교 전자통신공학과, 전자통신공학과 대학원을 졸업하고 드림시큐리티에서 PKI(Public Key Infrastructure) 서버/클라이언트 개발, PKI 시장 동향 분석 업무, 최적화, 여러 상용 DB를 위한 커스터마이징 작업, 시스템 이전 업무를 담당했습니다. 현재는 수펙스테크놀러지에서 근무하고 있으며 NMS(Network Management System) 개발을 담당하고 있습니다. 주요 관심사는 유닉스 기반 네트워크 프로그래밍과 보안 분야입니다.

http://www.symantec.com/ko/kr/theme.jsp?themeid=how-ssl-works 에서 참조

SSL(Secure Sockets Layer): 작동 방법

브라우저가 SSL을 발견하면

  1. 브라우저가 SSL로 보호되는 웹 사이트에 연결하려고 시도합니다.
  2. 브라우저가 웹 서버에 신원을 밝힐 것을 요청합니다.
  3. 서버가 SSL 인증서 복사본을 브라우저로 전송합니다.
  4. 브라우저가 SSL 인증서를 신뢰할 수 있는지 확인합니다. 신뢰하는 경우 서버로 메시지를 전송합니다.
  5. 서버가 디지털 서명 확인을 다시 보내면 SSL로 암호화되는 세션이 시작됩니다.
  6. 암호화된 데이터가 브라우저와 서버 간에 공유됩니다.

암호화를 통해 전송 중인 데이터 보호

웹 서버와 웹 브라우저는 공용 인터넷 상에서 주고받는 사적인 통신 내용과 데이터를 보호하기 위해 SSL(Secure Sockets Layer) 프로토콜을 사용하여 암호화된 채널을 생성합니다. 각 SSL 인증서는 키 쌍과 검증된 신원 정보로 구성되어 있습니다. 웹 브라우저(클라이언트)가 보안 웹사이트를 가리키면 서버는 클라이언트와 공개 키를 공유하고 세션에 대한 암호화 방식과 고유한 세션 키를 설정합니다. 클라이언트는 SSL 인증서의 발급자를 인식하고 신뢰한다고 인증합니다. 이 프로세스를 “SSL 핸드셰이크"라고 하며, 메시지의 개인 정보와 무결성을 보호하는 보안 세션을 시작합니다.

128비트의 강력한 암호화는 40비트 암호화에 비해 288배 많은 조합을 계산할 수 있습니다. 이것은 1조 배 이상 더 강력한 것입니다. 현재의 컴퓨팅 속도에서는 시간, 툴, 공격 의지를 가진 해커가 무차별 공격을 가하여 SGC 지원 인증서로 보호되는 세션에 침투하려면 1조 년이 걸립니다. 대부분의 사이트 방문자에게 강력한 암호화를 제공하려면 99.9%의 웹 사이트 방문자를 위한 128비트 암호화를 지원하는 SSL 인증서를 선택하십시오.

인증 정보로 온라인 신원 구축

신원을 증명하기 위한 인증 정보는 주변에서 쉽게 찾을 수 있습니다. 운전 면허증, 여권, 회사 배지 등이 여기에 해당합니다. SSL 인증서는 온라인 세계에서 통용되는 인증 정보이며 SSL 인증서 제공업체가 특정 도메인 및 웹 서버에 대해 고유하게 발급하고 인증합니다. 브라우저가 서버에 연결하면 서버는 식별 정보를 브라우저로 전송합니다.

웹 사이트의 인증 정보를 보려면 다음과 같이 하십시오.

  • 브라우저 창에서 잠긴 자물쇠를 누릅니다.
  • 인증 마크(예: Norton Secured Seal)를 누릅니다.
  • EV(Extended Validation) SSL에 의해 표시되는 녹색 주소창을 확인합니다.

인증을 통해 인증서의 신뢰 입증

인증 정보의 신뢰성은 발급 기관을 신뢰할 수 있는지 여부에 달려 있습니다. 발급 기관이 가짜이면 인증 정보도 가짜일 것이기 때문입니다. 인증 기관은 기업에서 제공하는 정보를 검증하기 위해 다양한 인증 방식을 적용합니다. 시만텍은 선두 인증 기관으로서 엄격한 인증 방법과 안정성 높은 인프라스트럭처를 갖추고 있으며 브라우저 공급업체의 신뢰를 받고 있습니다. 이러한 신뢰는 시만텍이 발급한 SSL 인증서에 대한 브라우저의 신뢰로 이어집니다.

HTTPS 이상의 보호 기능

Symantec SSL Certificates는 사이트를 보호하고 온라인 비즈니스를 육성하기 위해 더 많은 서비스를 제공합니다. SSL, 취약점 평가, 일일 웹 사이트 악성 코드 검사를 모두 사용하여 사이트 방문자에게 더 안전한 온라인 환경을 제공하고 일반에 공개되는 웹 페이지에 대해 HTTPS 이상의 보안을 제공할 수 있습니다. Norton Secured Seal 및 Symantec Seal-in-Search 기술을 통해 귀사의 사이트가 검색, 서핑, 쇼핑하기에 안전한 사이트임을 고객에게 확인시켜 줄 수 있습니다

http://blog.naver.com/PostView.nhn?blogId=tttnnn1234&logNo=110091727476 에서 참조

URI와 URL의 차이

Uniform Resource Identifier (URI) consists of a string of characters used to identify or name a resource on the Internet
http://en.wikipedia.org/wiki/URI

URI는 인터넷 상의 자원을 식별하기 위한 문자열의 구성쯤으로 해석 될 수 있겠다.

http://en.wikipedia.org/wiki/URL
URI의 한 형태인 URL은 인터넷 상의 자원 위치를 나타낸다.

URL는 URI의 한 형태로, 바꿔 말하면 URI는 URL을 포함 하는 개념이다.
(URI > URL)

인터넷 상의 자원의 위치와 식별자.
언듯 보면 같은 것을 의미하는 듯 하다.
하지만 ‘자원의 위치’라는 것은 결국은 ‘하나의 파일 위치’를 나타내는 것임을 명심하자.

http://img0.gmodules.com/ig/images/korea/logo.gif
이와 같은 형식은 logo.gif라는 인터넷상의 자원 위치를 의미 한다.
이는 URI이면서도 URL라고 말할 수 있다.

다음은 어떠한가.
http://endic.naver.com/endic.nhn?docid=1232950
http://endic.naver.com/란 서버에 위치한 endic.nhn파일은 query string인 docid의 값에 따라 여러가지 결과를 나타낸다.

여기서 URL은 endic.nhn의 위치를 표기한 http://endic.naver.com/endic.nhn 까지이다.
내가 원하는 정보에 도달 하기위해서는 ?docid=1232950라는 식별자(Identifier)가 필요한 것이다.

결국 위의 http://endic.naver.com/endic.nhn?docid=1232950주소는 URI이긴 하지만 URL은 아니다

[출처] URI 와 URL의 차이|작성자 너부리

URI 가 더 큰 개념이라고 할 수 있죠..
URI는 Uniform Resource Identifier 의 약자로
URL(Uniform Resource Locator)와 URN(Uniform Resource Name) 을 포함합니다.

아래의 자세한 내용은 http://www.xmlgo.net/open_xml/namespace/uri-url-urn.html 에서 발췌한 내용입니다. 참고하세요..

URLs

URL은 실제의 네트웍 경로를 가리키며, 네트웍 상의 리소스 접근시에 사용된다 URL의 첫 번째 부분은 다음과 같은 프로토콜을 명시하는데, 대부분의 경우 http이며, 가끔은 ftp 혹은 mailto이며, 드물게 gopher, news, telnet, file 등을 사용합니다. 이와 같은 URL 프로토콜 부분을 scheme이라고 한다. Scheme 뒤에는 콜론(:)이 따라오며 그 뒤에 식별된 자원의 경로가 나타난다. 다음의 예는 여러 분들이 매우 익숙할 것이다.

    http://www.xmlgo.net/document/editor/editor.html

이 URL은 www.xmlgo.net 이라는 이름의 인터넷 상에 있는 서버로부터 /document/editor/editor.html 이라는 파일을 검색하기 위하여 사용될 수 있는 경로(PATH)를 나타낸다. 파일 editor.html 은 /document/editor 이라는 디렉토리에 있으며, HTTP 프로토콜에 의하여 검색되야함을 명시한다. 또 다른 예로써 다음과 같은 전자메일 계정을 가리키는 URL도 있다.

    mailto:someone@sungshin.ac.kr

계속해서 다양한 프로토콜에 따른 예를 들어 본다면 ,

  • file -시스템내의 파일 이름 ( file:///C:windowsxmltest.xml )

  • ftp – ( ftp://ftp.is.co.za/rfc/rfc2141.txt )

  • news – 유즈넷 뉴스 그룹 ( news:comp.xml.xsl )

  • telnet – telnet://www.xmlgo.net

물론 URL을 통하여 검색될 수 있는 자원에는 제한이 있다. 컴퓨터로부터 검색가능한 형태의 자원만 검색할 수 있다. 실제의 예를 든다면 , RDF (URI상의,리소스에 관해 기술하는 규칙) : http://www.w3.org/TR/REC-rdf-syntax# SVG (2차원 그래픽,벡터형태의 그래픽, 이미지, 텍스트를 포함,을 표현하는 XML 용어집): http://www.w3c.org/XSL/Format/1.0 등이 네임스페이스로 사용된다.

URNs

URN은 자원에 대하여 영속적 (persistent)이고 유일하다. 위치에 독립적인 이름을 제공하기 위하여 존재한다. 이것은 RFC 2141 (http://www.ietf.org/rfc/rfc2141.txt) 에 정의되어 있다.

iURN은 문자열 “urn” 혹은 “URN”, NID (Namespace Identifier), 그리고 NSS (Namespace Specific String)로 구성되어 있으며 각 구성 엘리먼트간에 콜론(:)을 위치시킨다. NID는 URN의 형태를 나타내는데, 예를 들어 차후 XMLgo.net에서 ebXML문서의 형태로 각 회사의 정보를 기억해 두는 저장소를 URN으로 가리키고 , NSS 는 유일하고 영속적이여야 하며, 여기서는 registry1이라고 칭하였다.

    urn:xmlgo:registry1

좀더 현실적인 예를 들어 본다면

한국인을 위한 URN을 만들기 위하여 한국-시민 이라고 선언할 수 있다. NSS 로는 유일한 번호, 주민등록 번호를 표현하도록 한다면 000000-0000000 이 될 것이다.

    urn:한국-시민:000000-0000000

지금까지의 내용을 종합해 보면, Namespace를 지정할 때 URI 로 지정한다. URI로는 현재 널리 사용하는 웹주소, URL 방식과 URN 방식이 포함 되어 있다. 일반적으로 URL을 많이 사용하나 URN도 널리 사용 될 것이다. URL에서는 도메인 주소와 거기에 위치한 물리적인 경로가 자원을 찾기 위한 중요한 정보가 되지만, URN은 자원에 부여된 고유한 이름으로 그 자원의 위치와는 무관하게 부여된 이름이다.

이를 구체적으로 예를 들면 , 인천 광역시 남구 용현동에 인하대학교가 있지만, 인하대학교는 새로운 부지로 이사를 갈 수도 있을 것이다. 인하대학교가 어디에 있는지는 URL(주소)로 표현 할 수 있지만, 인하대학교가 다른 곳으로 가더라도 URN을 가지고 그 리소스(인하대학교)을 식별할 수 있다. 이사를 가고 나서 ‘인천광역시 남구 용현동의 인하대학교’ 라는 기존의 주소를 가지고는 인하대학교를 찾을 수 없다. 하지만 인하대학교란 고유한 이름은 변함이 없을 것이다

Installation Instructions

CodeIgniter is installed in four steps:

  1. Unzip the package.
  2. Upload the CodeIgniter folders and files to your server. Normally the index.php file will be at your root.
  3. Open the application/config/config.php file with a text editor and set your base URL. If you intend to use encryption or sessions, set your encryption key.
  4. If you intend to use a database, open the application/config/database.php file with a text editor and set your database settings.

If you wish to increase security by hiding the location of your CodeIgniter files you can rename the system and application folders to something more private. If you do rename them, you must open your main index.php file and set the $system_folder and $application_folder variables at the top of the file with the new name you’ve chosen.

For the best security, both the system and any application folders should be placed above web root so that they are not directly accessible via a browser. By default, .htaccess files are included in each folder to help prevent direct access, but it is best to remove them from public access entirely in case the web server configuration changes or doesn’t abide by the .htaccess.

After moving them, open your main index.php file and set the $system_folder and $application_folder variables, preferably with a full path, e.g. ’/www/MyUser/system’.

One additional measure to take in production environments is to disable PHP error reporting and any other development-only functionality. In CodeIgniter, this can be done by setting the ENVIRONMENT constant, which is more fully described on the security page.

That’s it!

If you’re new to CodeIgniter, please read the Getting Started section of the User Guide to begin learning how to build dynamic PHP applications. Enjoy!