[초보자들] 특별 퀘스트 : HTTPS 통신환경 구축하기

HTTPS를 도입하자

새해가 밝았습니다! 밝은 새해와 함께 Apple에서는 어마어마한 계획을 적용할 예정이었으니…
바로 ‘ATS 적용의 의무화’였습니다.  >>기사보기
ATS(App Transport Security)는 iOS 앱 통신 보안을 확보하기 위한 애플의 제도로, ATS를 적용시 모든 통신을 HTTPS로 해야만합니다. 다행히도(?) Apple에서는 의무화 시기를 미뤘습니다…

하지만 Apple이 아니더라도 HTTPS 환경 구축은 Bsidesoft의 오랜 숙원중에 하나였으니..! 프로젝트를 진행할 때 좀 더 안전한 사이트를 만들기위해 HTTPS 환경을 구축해야겠구나…를 계속 느껴왔습니다.
새해도 밝았겠다… Bsidesoft에서는 오랜 숙원인 HTTPS 환경을 구축을 해치우기로 했습니다.

드디어 해치울 수 있는건가..!

HTTPS? HTTP랑 뭐가 달라요?

“HTTP…? 인터넷 주소 아니에요? www 앞에 붙이던데…
근데 가끔은 www안쓰고 HTTP만 써도 되는거 보면 두개가 같은거 같은거 아닌가요….?”

네 이것이 Bsidesoft 취업 전 저의 HTTP지식이었습니다. 이런 저의 무지함은 인턴기간 통신 구조를 배우며 조금은 계몽이 되었지만, 시간이 지나니 또 잊게 되더군요. 이번에 HTTPS환경 구축을 하며 다시 한번 공부를 했습니다.

HTTP(hypertext transfer protocol)는 말 그대로 프로토콜, ‘약속’입니다. 통신을 할 때 이런 식으로 하자~라고 정해둔 약속인거죠. 예를 들어 https://www.bsidesoft.com/index.html라고 웹 브라우저에 입력하면 “http 통신 방법으로 www.bsidesoft.com에 있는 index.html 데이터를 가져와줘”라는 의미가 됩니다. 우리가 쓰고 있는 웹은 기본적으로 HTTP로 통신을 하기때문에 HTTP를 쓰지않아도 브라우저단에서 HTTP를 붙여줘서 제가 HTTP를 쓰지 않아도 요청이 잘 보내졌던 거구요.

지난번 메신저 글에서도 잠깐 언급을 했다시피 HTTP는 간편하고 단순하기 때문에 일반 데이터를 주고 받기에는 좋습니다. 하지만 다음과 같은 단점이 있습니다.

1. 암호화 안된 방식으로 데이터를 주고 받음 : 데이터를 중간에 가로챌 수 있음.
2. 통신하는 상대방의 신원을 확인하지 않음 : 상대방이 누군지 확인하지 않고 요청/응답을 보냄. 중간에 상대방인척하고 데이터를 가로챌 수 있음.

신용카드 번호라든지, 비밀번호라든지.. 여러가지 중요한 정보들을 HTTP로 보내기엔 너무 위험한것..!
이를 보완하기 위해 HTTPS가 등장하게 되었습니다.

HTTPS는 Hypertext Transfer Protocol over Secure Socket Layer의 약자로 “시큐어”한 SSL층 위에서 하는 HTTP를 말합니다. 기존의 HTTP를 보안층인 SSL 층으로 한겹 감싸서 더 안전한 통신을 할 수 있는거죠. HTTPS는 HTTP의 문제점을 다음과 같이 해결합니다.

1. 데이터를 암호화하고
2. 통신하는 상대방의 신원을 확인함.

그렇다면 HTTPS는 어떻게 통신을 암호화하고 , 통신하는 상대방의 신원을 확인할까요?

HTTPS의 암호화기법

어떤 정보를 암호화 된 정보로 바꾸는 것을 암호화, 암호화된 정보를 다시 원래 정보로 바꾸는 것을 복호화라고 합니다. 암호화하는데 쓰는 비밀번호 같은 것을 키라고 하는데, 암호화 할 때 쓰는 키와 복호화할 때 쓰는 키를 같이 사용하는 것을 “공통키 암호화 방식”이라고 합니다. 단순한 구조라 CPU를 적게 쓰고 빠르다는 장점이 있죠. 하지만 공통키를 누군가에게 빼앗기면 복호화를 할 수 있으므로 보안에 취약하다는 단점이 있습니다.

그래서 등장한 것이 암호화와 복호화에 다른 키를 사용하는 “비대칭키(=공개키) 암호화 방식”입니다. 암호화 한 키를 빼앗겨도 해독을 할 수 없으니 좀 더 안전하다는 장점이 있죠. 하지만 공통키 방식에 비해 느리고 리소스 소비가 크다는 단점이 있습니다.

그렇다면 부담은 적게하면서도 안전성은 높일 수는 없을까요? 공통키 방식과 비대칭키 방식을 같이 쓰면 됩니다. HTTPS에서 이 방법을 사용하는데, 자주 써야하는 메시지 암호화는 “공통키”방식으로 암호화 하고, 그 공통키는 비대칭키 방식으로 암호화해서 처음에만 사용합니다. 이렇게 되면 공통키는 비대칭키 방식으로 안전하게 보호하고, 메시지 전송은 공통키 방식으로 빠르게 할 수 있으니 두마리 토끼를 다 잡을 수 있게 됩니다.

HTTPS에서 통신을 시작할 때 공개키와 증명서를 확인하고 그것으로 공통키를 암호화해서 주고받은 후 복호화 하는 단계가 있는데, 이를 핸드쉐이크(handshake)라고 합니다. 핸드쉐이크가 되고 나서야 본격적인 암호화 통신이 개시됩니다.

HTTPS의 인증기법

메시지의 암호화는 해결했고, 이제 사용자의 신원을 인증은 어떻게 할까요? 바로 ‘인증서’를 이용합니다.
자기를 자신이 인증할 수는 없기 때문에 3자의 인증을 받는데(가끔 자기가 자기를 인증하는 경우도 있습니다… 하지만 신뢰성이 매우 급감…) 이런 인증을 해주는 전문적인 기관들을 인증기관(Certificate Authority – CA)들이라 합니다. 우리가 많이들 보았던 Verisign에서 부터 comodo, thawte 등… 다양한 인증기관이 있는데, 그 공신력을 인정받은 인증기관의 인증서는 아예 브라우저에 그 정보를 가지고 있어서 그를 이용하기도 합니다. (이를 이용해 브라우저 자체를 해킹해 자신이 인증받은 기관인 것처럼 속여서 해킹을 하는 경우가 많다고 하네요)

인증기관에 인증을 받은 사이트같은 경우 접속을 하면 다음과 같이 ‘안전함’이라든지 ‘자물쇠’ 표시 등이 되어있습니다.

우리은행에서는 기관 정보까지 확인해볼 수 있습니다.

브라우저에서 요청을 보냈는데 중간에 누가 가로채서 이상한 곳으로 가진 않았나, 친구가 네이버 링크를 보내줘서 클릭했는데 생긴것만 네이버지 실제로는 다른 곳이 아닌가..? 의심이 될때면, 웹브라우저의 주소창 부분을 확인해보시면 됩니다.

유료 인증서 말고 무료 인증서도 존재합니다. 하지만, 그런 인증서는 브라우저에 등록이 되어 있지 않기 때문에 특정 브라우저에서는 의심이 되는 사이트로 접속 자체를 차단하기도 한다고 합니다.

아참, 서버만 인증을 하는 건 아닙니다. 반대로 사용자(클라이언트)의 신원을 인증하는 경우도 있는데, 대표적인 것이 바로 공인인증서입니다. 하지만 보통은 클라이언트보다는 서버의 신원 인증을 하는 경우가 많죠.

SSL 인증서 구매

이제 HTTPS 통신의 원리를 알았으니 구매를 해보겠습니다. HTTPS통신을 하려면 “인증서”를 갖춰야합니다. 인증서는 위에서 말했다시피 CA 기관에서 구매를 하든지, 무료 SSL 인증서를 받아서 사용할 수 있습니다. Bsidesoft에서는 CA기관에서 인증서를 구매하려고 했는데 크나큰 문제에 봉착했으니… 바로 인증서의 종류가 너무 다양하다는 것이었습니다.

무엇을 살 지 고민할 때 가장 중요하게 봤던 것은 “인증서를 사용할 범위가 어떻게 되는가”였습니다. 인증서의 사용 범위는 도메인 기준인데, 도메인이라 함은 웹사이트 상에서 자료가 있는 위치를 말합니다. 보통 인증서 상품들은 1개의 도메인에 인증서를 발급하는 것을 기준으로 하기 때문에 같은 서버에 있는 자료라도 도메인을 다르게 사용하고 있다면 도메인별로 인증서를 구매해야합니다.

하지만 많은 도메인에 인증서를 갖춰야하는경우를 위해 멀티인증서도 존재합니다. 예를 들면, 하나의 인증서를 가지고 www.bsidesoft.com, www.asidesoft.com 두개의 웹사이트를 인증할 수 있는 것이죠.

한편, 인증서에서는 똑같은 도메인이라 하더라도 서브 도메인은 개별로 취급을 합니다. 예를 들어 www.bsidesoft.com과 blog.bsidesoft.com은 둘 다 bsidesoft.com으로 끝나지만 다르게 취급하는 거죠. 이런 경우에는 와일드카드(*) 상품을 구매하면 되는데 Bsidesoft는 이 상품이 필요했습니다.

사실 적용 범위 외에도 암호화 강제여부라든지, 보상금액이라든지 다양한 조건으로, 다양한 브랜드 상품들이 있습니다. 본인의 환경에 가장 알맞은 상품을 구매하시면 됩니다.

원하는 상품을 정한 후에는 SSL 판매 사이트에 들어가서 취급하는 다양한 상품들의 사양과 견적을 비교했습니다. 여전히 많은 상품들이 있었지만, 그중에 고르고 골라 최종 후보를 몇 개 골라냈습니다.

그리고 가장 합리적인 가격대의 상품을 이사님께 최종 확인을 받아 결정했으니, 선택된 상품은 바로 Comodo사의 PositiveSSL Wildcard! 구매는 큐트러스트라는 곳에서 했습니다. (가격은 VAT 포함해 17만원정도로 구매!)

아차… 구매 단계에서 한가지 더 난관이 남았으니 바로 인증! (두둥)

여기서 인증은 인증서를 실제로 보내주기 전에 구매한 사람이 실제로 도메인을 소유한 사람인지, 유효한 사용자인지를 확인하는 절차입니다. 인증 방식으로는 메일, 웹사이트 등을 통해서 하는 방법이 있는데 저는 http방식을 선택했습니다. http는 인증사에서 정해진 이름과 형식의 파일을 인증을 받고 싶은 페이지의 정해진 위치에 올리는 방식으로 인증을 하는 방식입니다.

구매를 하면, 담당자 메일로 어떤 내용의 파일을 어디에 올려야하는지 지시가 옵니다.

그럼 그 파일을 잘 만들어서, 지정한 위치에 올려두고 기다리면 됩니다. 몇시간 정도 기다리니 인증이 완료되었고, 인증서 파일과 인증서 설치 내용을 안내하는 내용이 메일로 도착했습니다.

드디어 인증서 get…✩

SSL 인증서 설치

이제 구매한 인증서를 웹서버에 설치를 하면 됩니다.

외부 업체를 통해 호스팅을 받은 분은 동일한 호스팅 업체에서 판매하는 인증서를 구매하면 아주 간편하게 (거의 자동급으로) 설치가 가능하다고 합니다. 그렇지 않은 경우에는 호스팅 업체가 제공하는 메뉴얼에 따라 조금 복잡하게 직접 설정을 해줘야할 수도 있습니다.

직접 서버를 돌리거나 서버를 구매한 경우에는 웹서버 환경에 알맞은 방법으로 인증서를 설치하면 됩니다. Bsidesoft에서는 웹서버를 직접 운영하고 있기 때문에 후자의 환경에서 구매처에서 알려준 방법에 따라 설치했습니다. 저희는 웹서버로 Microsoft의 IIS를 쓰고 있는데, IIS(인터넷 정보 서비스)관리자를 이용해 쉽게 설치를 할 수 있었습니다.

1. IIS(인터넷 정보 서비스)관리자 > 서버인증서 선택
   
2. 가져오기 클릭
   
3. 인증서 가져와서 등록
   

생각보다 간단합니다..?!?

HTTPS 사이트 적용

인증서를 서버에 설치했다면, 이제는 사이트에 인증서를 적용할 차례입니다.

1. IIS서버에서는 IIS 인터넷 정보 서비스 관리자 > 적용할 사이트 오른쪽 클릭 >  바인딩 편집
   
2. 사이트 바인딩에 https를 선택하고 인증서 선택
   *여기서 url 스킴의 종류를 고를 수 있고, 접속 포트도 지정할 수 있습니다. HTTP는 기본으로 80번 포트를, HTTPS는 보통 443 포트로 접속을 하게 되어있는데 다른 포트로 할 경우에는 도메인 뒤에 포트를 써줘야한다고 합니다.(443인경우에는 도메인 뒤에 포트번호를 생략해도 ok) 저희는 기본으로 고고!
   
3. 확인 누르면 끝!
4. 이제 https://www.bsidesoft.com/으로 들어가보면 ‘안전함’이 뜹니다…!

생각보다 간단하게 HTTPS 환경을 구축할 수 있었습니다!

생각보다 간단합니다..?!?

하지만 몇가지 문제가 생겼으니…. HTTPS 로 바꾼 후 기존에 HTTP로 접속해 남긴 페북 댓글을 불러올 수 없게되는 사태가ㅠㅠ… 이렇게 HTTPS 환경으로 바뀌면 리소스를 가져올 때 몇가지 오류가 생길 수도 있으니 미리 염두하시길 당부드립니다..☆

올해는 좀 더 안전하게, Bsidesoft에서 글을 보세요!

 

---

summer| bsidesoft 신입사원
디자인을 공부했던 섬머는 개발까지 해버리겠다는 욕심으로 개발자의 세계에 입문하게 되었습니다. 개발왕이 되어 멋진 제품을 만들어내는 꿈을 꾸고 있습니다. 코드, 디자인을 포함한 세상의 모든 아름다운 것들과 미드, 그리고 달리기를 좋아합니다.