http://www.xeschool.com/xe/step2_62

SSL 보안서버인증 적용하기 - 웹호스팅

인터넷 보안이란 뭘까?

XE 시작하기 1단계(게시판 모듈 설치하기)에서 인터넷은 미 국방부에서 만들게 되었다고 설명하였습니다. 이렇게 개발된 군사기술은 일반에 공개되면서 월드와이드웹(WWW) 세상에서 정보를 주고 받을 수 있는 범용 프로토콜로 사용하게 되었는데 이것이 바로 HTTP 통신규약입니다.

HTTP의 의미는 HyperText Transfer Protocol, 즉 "하이퍼텍스트(본문)전송규약"이라는 뜻으로 HTML로 작성된 웹문서를 포함하여 클라이언트 웹브라우저와 서버 사이에 이루어지는 요청/응답(request/response)에 대해 필요한 정보를 주고 받을 수 있는 신호 체계로 전송 매체, 접속용 단자 및 전송 신호, 회선 규격 등을 미리 정의한 양식과 규칙을 말합니다.

HTTP는 D.D.D.자동전화기를 닮았다고 생각하면 이해가 쉽습니다. D.D.D.는 Direct Distance Dialing의 약자입니다. 즉 교환 안내원이 먼저 전화를 받아 연결하고자 하는 상대방과 일일히 선을 연결해야만 통화를 할 수 있었던 수동 전화 방식(교환전화기)이 아니라 미리 약속해 둔 번호를 따라 회전 다이얼을 돌려 신호를 전송하면 자동으로 상대방 전화기에 연결되는 원거리 자동식 전화기를 말합니다.

오늘날 인터넷의 원리와 별반 다르지 않다는 것을 금방 알 수 있겠지요? 즉 우리가 사용하는 개인용 컴퓨터를 포함하여 모든 하드웨어(서버, 스마트폰, 기타 단말기 등)는 미리 약속된 숫자(TCP/IP)를 할당 받고 이 번호를 따라 자동으로 네트워크에 접속할 수 있으며 심지어 사람도 쉽게 호출(Host)할 수 있도록 각각에 이름을 붙여 활용하는 기술이 도메인 네임 시스템(Domain Name System, DNS)입니다.

그런데 한가지 문제가 있군요. 위 그림처럼 교환 안내원이 중간에 선을 연결하면 통화내용을 몰래 엿들을 수도 있다는 것입니다. 실제로 수동 전화방식에서는 연결시켜준 당사자간의 대화를 교환수가 함께 듣고 있어야 했고 통화가 끝났다면 선을 뽑아야 했습니다. 당시에는 어쩔수 없는 일이었고 때로는 통화 목적보다는 목소리가 예쁜 교환 안내원을 호출(Host)하는 경우도 있었다고 합니다...^^ 또한 D.D.D.자동 전화 방식도 중간 연결 단자에 선만 연결해 주면 현재 통화중인 내용을 몰래 엿들을 수 있어서 감청 또는 도청이 가능합니다. 이러한 장면은 007 영화나 첩보 영화에서 자주 등장하는 장면이기도 합니다.

만약 이러한 문제가 군에서 일어난다면 정말 큰일이 아닐 수 없습니다. 따라서 군용 통신 장비는 통화 내용, 즉 사람의 목소리를 알아들을 수 없는 신호로 바꾸어 변조하거나 빠른 속도로 주파수를 변경해가며 적의 간섭이나 도청을 피하기도 하고, 모스부호 기능으로 통신하는 등의 다양한 암호화 기술을 적용한 무전기, 즉 통신장비를 사용하게 됩니다. 원리는 무척 간단합니다. 즉 암호화된 데이터를 송신했다면 같은 방법(알고리즘)으로 풀어내어 수신하면 되는 것입니다. 그러나 이 기술이 아군도 알고 적군도 쉽게 알 수 있는 알고리즘이라면 의미가 없겠죠? 따라서 보안이라는 것은 매우 중요한 데이터 변조 기술입니다.

그러면 우리가 일반적으로 사용하는 월드와이드웹(WWW)에서도 위와 같이 보안 문제를 해결할 수 있는 방법이 없을까? 해답은 이미 오래전부터 사용되어져 왔었고 미리 준비된 포트(접속용 단자)가 있었답니다. 왜냐하면 인터넷은 군에서 만들었고 우리가 필요하지 않았기 때문에 사용하지 않았을 뿐 HTTPS라는 통신 프로토콜이 존재했으며 일반적으로는 전자 상거래를 위한 통신에서 자주 사용되는 1차적 보안 프로토콜이기도 합니다.

HTTPS : 보안 소켓 이해하기

HTTPS는 Hypertext Transfer Protocol over Secure Socket Layer의 약자입니다. 쉽게 말해서 같은 HTTP 프로토콜이지만 특별히 준비된, 안심(Secure)할 수 있는 소켓(Socket) 단계(Layer)를 통해서 하겠다는 의미입니다. 이해를 돕는다면 소켓(Socket)은 전기 기구의 플러그를 꽂을 수 있는 전기 콘센트와 같은 의미입니다. 이때 소켓은 데이터 통신을 위해 꽂는 작은 구멍(Port)이라는 뜻보다 좀 더 포괄적인 의미로 거대한 네트워크에 자신의 컴퓨터를 연결시켜 주는 입출력 장치(단자)를 뜻합니다. 즉 여기서 소켓과 포트는 거의 같은 의미로 사용됩니다.

우리가 항상 사용하던 HTTP 표준 프로토콜의 포트번호는 80번으로 약속되어 있습니다. 따라서 다음과 같이 URL을 작성합니다.

http://www.xeschool.com:80/

같은 방법으로 HTTPS 프로토콜로 접속하기 위해서는 다음과 같이 작성하고 호출해야 합니다.

https://www.xeschool.com:443/

하지만 일반적으로 포트번호는 생략한 채 http: 또는 https: 프로토콜만을 사용하여 접속할 수 있는 것은 위와 같이 잘 알려진(자주 사용되는) 서비스 포트에 대해 서버상에서 리다이렉션(Redirection) 설정을 미리 해두었기 때문에 일일히 포트번호를 입력하지 않아도 자동으로 방향을 지정하거나 변경하여 웹페이지를 호출할 수 있는 것입니다.

웹호스팅 사용자는 같은 서버에서 각각 다른 도메인으로 연결된 계정 공간을 할당 받고 이용하기 때문에 보안 포트의 경우 기본 포트(443 포트)가 아닌 도메인마다 개별적으로 할당된 포트번호를 사용하여 접속하게 됩니다.

예) https://www.xeschool.com:3000/

웹브라우저를 이용해 보안이 필요한 웹페이지를 서버에게 요청/응답 받는다는 의미는 HTTP 표준 프로토콜의 80번 포트를 이용하지 않고 특별히 준비된 443번 포트에 할당된 HTTPS 프로토콜을 이용하는 것입니다. 이러한 연결 방법을 보안 소켓(Secure Socket)이라 표현하고 이와 같이 HTTPS 보안 프로토콜을 이용하게 되면 요청과 응답의 양방향 모두에서 데이터 전체를 암호화 할 수 있습니다.

하지만 요청과 응답에 있어서 암호화 대상은 데이터의 일부분일 수 있고 또는 마크업 된 웹페이지 전체를 응답 받을 수도 있기 때문에, 불필요한 암호화/복호화를 반복하는 통신은 서버에 지나친 부담을 줄 수 있으므로 보안처리가 꼭 필요한 페이지(예: 폼 엘리먼트가 대부분을 차지하는 회원가입 페이지)나 혹은 부분적인 영역(예: 로그인 폼 엘리먼트의 아이디와 비밀번호 데이터 전송 등)에 제한적으로 적용하여 사용하는 것이 바람직합니다.

다음의 그림을 보면 쉽게 이해할 수 있습니다. A와 같이 HTTPS 프로토콜로 웹페이지를 호출한 경우 암호화된 페이지 전체를 응답 받은 후 복호화 처리 과정을 거쳐 화면에 출력됩니다. 또한 목적한 폼(Form) 엘리먼트의 action 속성에 HTTP 프로토콜을 향한 절대경로를 지정하지 않는한 데이터 처리를 위한 요청 역시 호출했던 포트와 같은 HTTPS 프로토콜을 이용하게 됩니다. 즉 HTTPS 포트는 항상 443번 포트를 이용하여 통신하기 때문에 웹페이지에 포함된 모든 경로는(상대경로라면) 자동으로 같은 포트를 이용하게 되는 것입니다.

B는 HTTP 프로토콜을 이용해 웹페이지를 호출한 경우로 일반적인 평문 통신의 기본 형태입니다. 웹페이지에 포함된 마크업 언어 전체가 암호화/복호화 처리 과정을 거치지 않기 때문에 A와 비교하면 상대적으로 빠르면서 효율적이고 비용 역시 저렴합니다. 만약 작은 크기의 데이터를 암호화하여 전송하고자 한다면 데이터 처리를 요청하는 폼의 action 속성에 위와 같이 443번 포트를 향하도록 절대경로를 지정하여 작성하게 되면 HTTP 프로토콜로 들어온 페이지라 하더라도 암호화된 전송 데이터는 HTTPS 프로토콜을 향하게 됩니다.

XE 코어에서 SSL을 사용하는 경우 [선택적으로]와 [항상 사용]이라는 옵션 설정이 있습니다. [항상 사용]을 선택하게 되면 요청과 응답에 사용할 프로토콜을 항상 HTTPS로 설정하고 사용하기 때문에 A와 같은 방법으로만 동작하게 됩니다. [선택적으로]를 선택하는 경우 A와 B를 혼합하여 사용합니다. 예를 들어 폼 엘리먼트가 대부분을 차지하는 회원가입 또는 회원정보수정과 같은 페이지는 입력된 데이터를 포함하여 마크업 된 페이지 전체를 A와 같은 방식으로 송수신하게 되고, 레이아웃 안에 포함된 로그인 위젯은 계정 확인을 위한 아이디와 비밀번호만 암호화하여 전송할 필요가 있기 때문에 액션 처리과정에서 B와 같은 방식으로 동작하게 됩니다. 어떤 방식을 선택하느냐는 사용자의 몫이지만 브라우저 접근성과 페이지에 소요되는 비용을 고려한다면 [선택적으로]를 활용하는 방법이 바람직 할 수 있습니다.

처리 후 결과 페이지를 전송할 응답 프로토콜의 지정은 어플리케이션과 로직에 따라 각각 다를 수 있습니다. 회원가입 후 회원정보를 재출력하고 확인을 받아야 할 필요가 있다면 같은 방식으로 HTTPS 프로토콜을 이용해 페이지를 전송하고, 로그인 후 보안이 필요하지 않은 목적 페이지를 출력한다면 HTTP 프로토콜을 이용하도록 방향을 지정할 수 있습니다. XE 코어는 로그인 후 HTTP 프로토콜로 목적 페이지를 전송합니다.

HTTPS 프로토콜로 웹페이지를 호출하는 경우 혼합 콘텐츠가 유입되지 않토록 주의해야 합니다.

혼합 콘텐츠란 HTTPS 프로토콜로 응답 받은 페이지 안에서 같은 포트가 아닌 80번 포트를 이용해 페이지 내부로 유입되는 모든 리소스를 말합니다. ① 폼(Form) 엘리먼트 또는 ② 링크는 페이지 안에서 외부로 요청하는 속성을 갖기 때문에 상대경로와 절대경로를 포함하여 프로토콜의 방향성은 매우 자유롭습니다. 즉 페이지 출력 후 타겟 속성은 다음(미래) 요청의 경로를 미리 지정할 뿐 혼합 콘텐츠가 아닙니다.

③, ④, ⑤는 모두 외부에서 내부로 유입되어 현재 페이지에 표시되어야 할 URI가 정의한 같은 항목을 포함시키지만 ⑤와 같이 HTTP 프로토콜로 유입 된다면 웹브라우저는 혼합 콘텐츠로 판단하게 됩니다. frameset 또는 iframe은 XE 코어에서 거의 사용되지 않는 엘리먼트이지만 만약 사용된다면 현재 페이지로 유입되는 리소스이므로 올바른 프로토콜을 경유할 수 있도록 수정해야 합니다.

HTTPS 프로토콜로 응답 받은 페이지 안에 혼합 콘텐츠가 표시된다고 해서 보안에 큰 영향을 주는 것은 아니지만 웹브라우저에 따라 위 그림과 같이 보안 정보 표시창을 출력하기도 하고, 정작 보안이 필요한 데이터가 혼합 컨텐츠의 평문 형식으로 유입 된다면 보안 페이지를 구성했다고 말할 수 없을 것입니다. 결국 보안 소켓(Secure Socket)을 활용하는 가장 중요한 핵심은 암호화가 필요한 데이터의 입출력 과정이 보안 포트를 경유할 수 있도록 웹페이지를 올바르게 마크업하는 것입니다.

순수 XE 코어에서는 사이트맵을 포함하여 대부분의 링크 속성이 상대경로로 동작합니다. 따라서 사용자가 특별히 수정하거나 변경해야 할 마크업 요소는 없습니다. 다만 사용자 레이아웃을 제작하여 이용하거나 필요에 의해서 수정한 내용 안에 절대경로로 지정된 링크요소가 있다면 위 내용을 참고하여 HTTPS 프로토콜 상황에서 올바른 경로로 유입될 수 있도록 수정해야 할 필요는 있습니다.

Q : 그러면 지금 당장이라도 보안 프로토콜(HTTP Secure)의 접속과 사용이 가능한가요?

아니오! HTTPS(HTTP over Secure Socket Layer)를 좀더 정확한 의미로 표현한다면 보안 소켓 레이어(SSL)를 갖춘 HTTP 프로토콜이라는 뜻입니다. 다시말해서 SSL(Secure Socket Layer)이 암호화 알고리즘을 뜻하는 것이 아니라, 네트워크 계층상에서, 즉 TCP-IP layer와 Application layer 중간에 위치하면서 웹브라우저와 서버 사이의 통신 과정에 항상 개입하여 암호화 알고리즘을 응용 할 수 있도록 준비된 보안 프로토콜이라는 의미입니다.

따라서 위에서 설명한 내용처럼 HTTPS 프로토콜을 경유하는 데이터를 암호화하여 송수신하려면, 서버 상에 HTTPS 인증서(HTTPS certificates) 또는 SSL 인증서라고도 부르는 보안 인증 도구를 설치해야 합니다. HTTPS는 단지 보안을 위해 접속하는 지정된 프로토콜 일뿐 송수신하는 데이터를 암호화/복호화 해 줄수는 없습니다. 다만 흔히들 443번 포트를 HTTPS 보안 프로토콜이라고 부르는 이유는 제3자로부터 신뢰할 수 있는 암호화 알고리즘 인증 도구를 설치할 수 있고 이러한 도구를 활용하여 송수신하는 데이터를 보호할 수 있는 보안 포트로서 작동하기 때문입니다.

SSL 인증서(Certificate)란 뭘까?

보안 인증을 위한 서버 구축은 크게 [응용프로그램 방식]과 [SSL 방식]으로 구분할 수 있는데 응용프로그램 방식은 웹서버에 접속한 사용자 PC에 보안 프로그램이 설치된 이후에야 사용이 가능하지만 SSL 방식은 별도의 다운로드와 설치 과정 없이 웹서버에 설치된 전자 인증서를 이용해 개인정보를 암호화하여 송수신하게 됩니다. 다음의 내용은 그 중 대표적인 공개키 암호화 알고리즘에 대해 간략히 소개합니다.

맨 처음 D.D.D.자동 전화기를 예로 들어 보안에 대한 문제점을 이야기하였습니다. 즉 도청과 감청의 문제를 해결하기 위해 군용통신장비는 송신 내용을 암호화하여 전송하고 수신기는 이것을 같은 방법으로 풀어 내야만 합니다. 같은 원리로 HTTPS는 소켓 통신에서 개인정보(주민등록번호,이메일,아이디,비밀번호 등)를 포함한 중요한 데이터의 유출과 변조를 차단하기 위해 일반 텍스트(Plaintext)로 송수신 하는 대신, 암호화 알고리즘을 이용하여 변조하거나 판독이 불가능한 암호화 텍스트(Ciphertext)를 만들어야 합니다.

이러한 기술의 핵심 요소는 웹브라우저와 서버간 송수신하는 데이터를 암호화(Encryption)/암호 해독(Decryption) 할 수 있는 알고리즘과 한 쌍의 키 교환, 제3자가 네트워크 상에서 신원을 확인해 줄 수 있는 서명된 전자 인증서를 포함한 인증 도구, 즉 이러한 일련의 인증 과정을 통해서만(over SSL) 가능합니다.

▼ 비대칭(Asymmetric) 공개 키(Public Key) 암호화(Encryption) :

※ 이미지 출처 : Max's Chips and Dips: Elliptic Curve Cryptography.
http://chipdesignmag.com/print.php?articleId=1162?issueId=22

RSA 방식의 공개키 암호화 알고리즘의 인증 과정을 간략하게 설명한 그림입니다. 암호화 알고리즘(encryption algorithm)의 종류는 60여가지가 넘지만 대표적인 RSA 방식만 살펴봐도 SSL의 흐름을 이해하는데 도움이 됩니다. 위 그림이 어려워 보이지만 절대 그렇지 않습니다. RSA란 이름이 붙은 것은 단순하게도 최초로 공개키 암호화 시스템을 개발한 로널드 라이베스트(Ron Rivest), 아디 샤미르(Adi Shamir), 레오널드 애들먼(Leonard Adleman) 이들 3명의 이름 앞글자를 딴 것 뿐입니다.

위 과정에서 주의깊게 살펴볼 내용은 ①공개 키(Public Key)와 ②개인 키(Private Key) 그리고 ③인증서(Certificate)가 하는 일입니다. 우선 위 그림에는 없지만 비밀 키(Secret Key)라는 것도 있습니다. 비밀 키는 암복호화 할 데이터를 단순히 같은 키로, 즉 비밀 키 하나로 활용하는 방법입니다. 따라서 이것을 대칭 키(Symmetric key)라고도 부르고 작업 속도가 매우 빠른 장점이 있지만 공유된(shared) 비밀 키는 이브(Eve, 성서에 나오는 아담의 아내로 아담에게 선과 악(the Knowledge of Good and Evil)을 알게하는 나무의 열매를 함께 먹도록 꾀어 에덴동산에서 추방되었기 때문에 유혹과 뱀을 연상시키는 의미로 자주 사용됨)에게 매우 좋은 유혹(Temptation)의 대상이기 때문에 결코 안전하지 않습니다.

이러한 문제점을 해결하기 위해서 공개 키 기반구조(Public Key Infrastructure, PKI)의 비대칭 암호화(Asymmetric Encryption)방식이 더 선호되는 것입니다. 비대칭이라는 뜻은 암복호화에 각각 다른 키를 사용한다는 뜻입니다. 즉 ①공개 키(Public Key)는 말 그대로 누구에게나 공개 된 키입니다. 심지어 이브(Eve)도 가질 수 있지만 이 키가 하는 일은 데이터를 암호화(Encryption)하는 일입니다. 암호화된 텍스트(Ciphertext)는 반드시 각자가 비밀스럽게 잘 보관한 ②개인 키(Private Key)로 풀어야 합니다. 하지만 이브(Eve)가 얼마나 똑똑한지 공개 키를 이용해 텍스트를 변조할 수도 있습니다. 하지만 너무 걱정할 필요는 없습니다. 공개 키의 길이가 충분히 크다면 단지 몇몇의 이브만이 암호화된 텍스트(Ciphertext)를 해독 할 수 있을 뿐이고(Anyone can use the public key to encrypt a message, but with currently published methods, if the public key is large enough, only someone with knowledge of the prime factors can feasibly decode the message.) 해독이 된 시점에는 이미 다른 새로운 키를 사용하고 있을 것입니다.

키 크기(Key Size) : 가능한 키 조합(Possible Key Combinations)
2-bit  2^2  2x2 = 4
3-bit  2^3  2x2x2 = 8
4-bit  2^4  2x2x2x2 = 16
5-bit  2^5  2x2x2x2x2 = 32
...
40-bit  2^40  2x2x2x2x2x2x2x2x2x2 ... 2x2x2x2x2x2x2x2x2x2... = 1 trillion (1,097,728,000,000)
128-bit  2^128 2x2x2x2x2x2x2x2x2x2 ... 2x2x2x2x2x2x2x2x2x2... = 339,000,000,000,000,000,000,000,000,000,000,000

따라서 데이터의 내용이 올바르게 잘 전달 되었는지, 이브에 의해서 변조되지는 않았는지를 최종적으로 검증할 수 있는 제3의 인증기관(Certificate Authority, CA)이 함께 보증하는 전자 서명된(Signed) ③인증서(Certificate)가 반드시 필요한 것입니다.

인증서 파일은 데이터를 암호화하는 자물쇠 역할을 하며, 키(Keys)의 소유자의 신원 확인과 소유자 정보, 인증 만료일, 발급자(CA)의 전자서명과 같이 중요한 정보를 포함시켜, 서버(A)에 접속한 클라이언트(B)에게 보내준 공개 키가 과연 A가 보내 준 것인지 확인할 수 있도록 검증해 주고, 서버(A)는 접속 요청하는 암호화 데이터의 주인(B)이 과연 B가 맞는지 신원을 확인할 수 있도록 하는 디지털 서명(Digital Signatures) 인증서를 첨부하게 됩니다.

참고로 하이브리드 암호화(Hybrid Encryption)는 공개 키 방식에 비밀 키를 포함시켜 전송하는 방식으로 대칭 키의 효율성과 공개 키의 편의를 결합한 방식이며, 암호화 된 데이터 전송시 임의 키를 생성하여 단 한번만 사용하고 버리는 세션 키(Session Key)를 활용하기도 합니다. 세션 키는 전송 데이터마다 매번 다른 키를 사용하기 때문에 안정성은 크지만 과정에 따른 비용은 상당히 크다고 볼 수 있습니다.

결론적으로 SSL 인증서란, 클라이언트 PC와 서버 사이의 통신 과정에서 전송계층 종단간 보안과 데이터 무결성, 최종단의 인증, 통신의 기밀성을 확보하기 위한 암호화 알고리즘의 인증 규약(TLS/SSL 암호 규약)을 가리키며, HTTPS(Hypertext Transfer Protocol over Secure Socket Layer) 프로토콜을 지칭하기도 하고, 보안 프로토콜 안에서 반드시 통과해야만 하는 전자 인증서(digital certificates), 즉 보안 서버 인증서를 가리킵니다.

관련자료 :

• http://wiki.kldp.org/HOWTO/html/SSL-Certificates-HOWTO/x45.html
• http://korea.gnu.org/openweb/1/certificate.html
• http://www.gria.org/documentation/5.3/manual/guide-to-public-key-infrastructure/overview

Q : 보안 서버 인증서(SSL)는 어디서 구하죠?

보안 인증서(SSL)는 서버 사용자(User)가 한쌍의 키(Keys)를 생성하여 제3의 인증기관(Certificate Authority, CA)에 서명해줄 것을 ★요청(Certificate Signing Request, CSR)하면 신원확인 후 서명된 키(Keys)와 인증서(Certificate)를 보내 줍니다. 사용자는 이것을 서버의 보안 포트에 설치해야만 비로서 HTTPS 보안 프로토콜을 활용할 수 있게 됩니다.

※ 이미지 출처 : http://www.cisco.com/en/US/tech/tk583/tk618/technologies_white_paper09186a0080179739.shtml

웹호스팅 사용자는 위와 같은 과정을 서비스 제공 회사가 대신 처리해 주기 때문에 홈페이지 운영에 필요한 인증서를 선택 후 올바른 신청서 정보만 작성하여 제출하면 보안 인증서를 활용할 수 있습니다. 개인 서버 운영자는 별도의 정보제공 사이트를 참고하여 보안 서버를 구축하도록 합니다.(XE스쿨은 서버 운영 정보를 다루지 않습니다.)

SSL 인증서를 선택하는 가장 중요한 요소는 다양한 웹브라우저 및 운영체제의 호환성을 검토해야 합니다. 무료 인증서의 경우 사용 기간 제한이나 제한된 웹브라우저에서만 활용할 수도 있고 호스팅 회사에 의해서 테스트 되지 않은 타사 인증서는 설치를 거부할 수도 있기 때문에 신중하게 선택해야 합니다.

SSL 인증서 발행은 도메인과 해당 도메인의 소유자의 정보를 확인하여 신원을 확인하는 과정입니다. 좀더 쉽게 설명하면 나는(I am) www.xeschool.com 이라는 ①도메인을 사용하여 사이트를 운영하고 있는데, 이 도메인의 주인이 나(I am)라는 것을 어떻게 증명할 수 있을까? 따라서 인증기관(CA)이 ★요청(Certificate Signing Request, CSR)과 도메인 등록 정보를 확인한 후 ②소유자 메일로 신원 확인을 위한 도메인 소유자 인증키 등록 메일을 보내 옵니다. 도메인 관리자는 소유자 이메일을 확인하여 보내준 인증키를 재첨부하고 등록하면 나머지 과정은 호스팅 회사가 서명된 인증서를 받아 도메인과 연결된 서버 계정에 설치하여 보안 서버를 구축하고 활용하게 됩니다.

★ XE 코어 사용자(호스팅)는 다음 3가지 과정만으로 SSL 보안 서버를 쉽게 구축할 수 있습니다.

이상의 내용으로 HTTPS 보안 프로토콜의 올바른 사용법과 데이터 암호화의 과정, SSL 인증서의 역할을 간략히 살펴 보았지만 XE 코어 사용자는 사실 아래 나열된 3가지 단계만 실행하면 보안 서버를 운영할 수 있게 됩니다...^^ 하지만 위 내용이 웹사이트를 운영하는데 조금이나마 도움이 될 수 있으리라 생각합니다.

• Step 1 : SSL 인증서 신청하기
• Step 2 : 도메인 소유자 메일 확인후 인증키 등록하기
• Step 3 : XE 코어 관리자 설정에서 SSL 사용 설정하기

SSL 인증서 신청하기(Step 1)

서비스 받고 있는 회사의 보안 인증서 신청란에 접속하여 운영중인 웹사이트 계정에 설치하고자 하는 인증서를 선택한 후 다음과 같이 올바른 도메인 정보와 소유자 정보를 입력합니다. 기업용 인증서로 회사명을 사용할 때는 접미사를 붙여주고 반드시 후이즈(Whois) 정보와 일치하도록 작성해야 합니다. 본인확인메일주소는 도메인 소유자임을 나타내는 검증에 활용됨으로 반드시 도메인 등록시 사용된 메일 주소를 올바르게 입력합니다. 아래 신청서 양식은 호스팅 서비스 제공 업체마다 조금씩 다를 수 있으므로 자세히 확인한 후 입력합니다. 기타 등록 비용과 결재방법을 처리하게 되면 다음 과정으로 넘어가게 됩니다.

★ 참고 : 현재 사용하고 있는 도메인의 URL 주소에서 월드와이드웹(www)의 사용 여부에 따라 인증서는 각각 별개의 도메인으로 구분합니다. XE 스쿨은 www.xeschool.com으로 신청하였지만 서비스 회사는 신청서와는 별도로 xeschool.com까지 등록 지원해 주고 있군요. 이 부분은 반드시 확인한 후에 등록을 완료하도록 합니다.

※ 관련내용 참고 : XE에서 로그인 풀림 방지

도메인 소유자 인증키 등록하기(Step 2)

도메인 소유자를 검증하는 과정은 해당 인증기관(Certificate Authority, CA)이 도메인 소유자에게 직접 메일로 인증을 요구합니다. 따라서 다음과 같이 인증키를 확인하고 등록하게 되면 호스팅 서비스 제공자는 전자 서명된(Signed) 인증 파일을 인증기관으로 부터 발급 받아 서버에 설치하고 마무리하게 됩니다.

★ 참고 : 첨부한 이미지는 참고자료입니다. 소유자 이메일 검증 방법은 인증기관(CA)에 따라 조금씩 다를 수 있습니다.

XE 코어 관리자 설정에서 SSL 사용 설정하기(Step 3)

도메인 소유자 인증키 등록을 이메일로 검증하는 과정이 끝나면 호스팅서비스 회사로부터 최종적으로 보안인증서 설치를 완료하였다는 안내 메일을 받게 됩니다. 이제 인증 받은 도메인의 XE 코어 관리자 화면으로 접속하여 제어판 > 설정 > [일반]을 클릭합니다.

기본 URL에서 월드와이드웹(www)의 사용을 확인한 후에 SSL 보안접속 선택 항목에서 [선택적으로]와 [항상 사용] 중 하나를 선택합니다. [항상 사용]을 선택하는 경우 사이트 접속시 시작 모듈을 포함하여 모든 페이지를 HTTPS 보안 프로토콜로 요청/접속하는 것을 뜻하며, [선택적으로]는 아래와 같은 동작에서 HTTPS 보안 프로토콜로 페이지 전체를 호출하여 출력하거나, HTTP 표준 프로토콜의 위치에서 요청된 액션의 처리 과정에서 암호화 전송된 데이터를 받아 처리하도록 설정되어 있습니다.

SSL 인증서를 활용하는 가장 큰 목적은 웹서버와 브라우저 사이에서 회원의 개인정보 데이터를 보호하기 위한 것으로 [선택적으로]를 지정하게 되면 회원관리(member) 모듈에 한정하여 사용되는 것입니다. 따라서 "_use_ssl" 변수값이 "optional" 일때 member 클래스는 다음과 같이 설정하고 사용합니다.

▶ xe.1.5.3.ko/xe/modules/member/member.class.php : Line 27

• 비밀번호 수정 페이지 : dispMemberModifyPassword
• 회원가입 페이지 : dispMemberSignUpForm
• 회원정보 수정 페이지 : dispMemberModifyInfo
• 로그인 페이지 : dispMemberLoginForm
• 비밀번호 찾기 페이지 : dispMemberFindAccount
• 로그인 실행 단계 : procMemberLogin
• 비밀번호 찾기 실행 단계 : procMemberModifyPassword
• 회원가입 실행 단계 : procMemberInsert
• 회원정보 수정 실행 단계 : procMemberModifyInfo
• 비밀번호 찾기 실행 단계 : procMemberFindAccount

③번 서버 포트 지정에서 호스팅 사용자는 반드시 HTTPS 보안 프로토콜에 사용될 포트 번호를 할당 받아 올바르게 입력해야 합니다. HTTP 표준 프로토콜의 경우 80번 포트를 사용 중이라면 빈 공란으로 유지해도 상관없지만 보안 프로토콜의 경우 같은 서버에서 다수의 도메인 사용자가 존재하기 때문에 별도의 포트를 할당 받게 됩니다. 서버 설정에 따라 HTTP 포트와 HTTPS 포트 번호가 [잘 알려진 포트 번호]와 다른 경우 반드시 올바른 포트 번호를 함께 입력해야 합니다.

설정이 완료되면 하단에 위치한 [저장] 버튼을 클릭합니다.

[선택적으로] SSL 사용하기를 지정하였기 때문에 시작 모듈은 예전과 동일하게 HTTP 표준 프로토콜로 접속 됩니다.

회원가입 등 지정된 모듈을 호출하는 경우 페이지 전체를 HTTPS 보안 프로토콜로 호출하고 출력하게 됩니다. 구글 크롬 웹브라우저를 이용해 확인해 보면 URL 주소 앞에 선명한 초록색 자물쇠 아이콘으로 확인할 수 있으며 아이콘을 클릭하면 인증서의 세부 정보가 표시되고 사이트의 SSL 보안 서버 인증이 올바르게 동작하고 있음을 알려줍니다.

익스플로러의 경우에는 웹페이지 우측 하단에 자물쇠 아이콘이 출력됩니다.

※ SSL 인증서는 유효기간이 만료 되면 갱신해야 합니다.