3차 데모데이 권장 요구사항 중 https 적용하기 라는 요구사항이 있었다. 권장 요구사항에 맞추어 https를 적용하게 되었는데 사실 권장 요구사항이 아니더라도 https는 보안과 관련해서 중요하므로 꼭 적용하고 알아야되는 내용중 하나라고 생각한다. 그래서 https의 작동원리에 대해 간단히 알아보고 추가로 프로젝트를 진행하면서 ssl 인증서를 발급받고 https를 적용한 과정을 공유해보자한다.
https란
먼저 https는 무엇일까? https는 http에서 보안이 곁들어진 프로토콜이다. https를 통해 클라이어트와 서버가 통신을 하게되면 데이터가 암호화되어 송수신되므로 http에 비해 보안이 더욱 강하다고 볼 수 있다.
ssl 인증서 역할
https를 적용하기 위해서는 ssl 인증서가 필요하는데 ssl 인증서에는 크게 두가지 역할이 있다.
- 클라이언트가 접속할 서버가 믿을만한 서버인지를 보증
- 클라이언트에게 암호화에 사용될 공개키를 제공
따라서 서버는 클라이언트와 통신할때 ssl인증서를 클라이언트에게 제공하므로서 자신의 서버가 안전하다는 인증을 할 수 있고 통신할 데이터를 암호화를 통해 보안을 강화 할 수 있다. 이때 서버는 클라이언트에게 제공할 ssl인증서가 필요한데 인증기관(CA)으로부터 ssl인증서를 발급받아야한다.
대칭키와 비대칭키
암호화가 어떤식으로 진행되는지 이해하기 앞서 대칭키와 비대칭키에 대해서 먼저 이해해야한다. 키를 이용하면 어떤 파일을 암호화 하거나 복호화 할 수 있는데 만약 대칭키로 어떤 파일을 암호화했다면 복호화할때도 똑같이 암호화했던 대칭키를 이용해서 복호화를 할 수 있다.
하지만 비대칭키는 공개키와 비공개키 두개로 이루어져있다. 대칭키와 달리 공개키를 이용해 어떤 파일을 암호화를 했다면 복호화는 반드시 비공개키로밖에 할 수 없고 공개키로는 복호화를 할 수 없다. 반대로도 마찬가지다. 만약 비공개키로 어떤 파일을 암호화를 했다면 복호화는 비공개키가 아닌 공개키로밖에 할 수 없다.
https 통신 과정 및 원리
먼저 ssl 인증서의 역할은 크게 두가지 역할이 있다고 했다.
- 클라이언트가 접속할 서버가 믿을만한 서버인지를 보증
- 클라이언트에게 암호화에 사용될 공개키를 제공
먼저 첫번째로 클라이언트는 서버로 부터 받은 ssl 인증서를 통해 어떻게 자신이 접속한 서버가 믿을만한 서버인지를 확인할수 있을까? 또한 받은 ssl 인증서가 진짜로 인증기관으로부터 발급받은건지 어떻게 신뢰할수있을까?
앞서 서버는 ssl인증서를 클라이언트에게 제공해주기 위해 인증기관으로부터 ssl인증서를 발급받아야한다고 했다. 인증기관은 ssl인증서를 서버에게 ssl인증서를 발급해줄때 해당 인증기관의 비공개키로 ssl 인증서를 암호화를 해서 발급해준다. 서버는 발급받은 암호화된 ssl 인증서를 클라이언트에게 제공하고 클라이언트는 해당 인증기관의 공개키를 이용해서 복호화를 하게된다. 해당 인증기관의 공개키로만 복호화가 가능하기때문에 복호화가 성공했다면 이 ssl 인증서는 해당 인증기관에서 발급받은 인증서라는걸 확인할수 있게되는것이다. (정확히는 인증서체인을 통해 확인한다.)
두번째로 클라이언트에게 암호화에 사용될 공개키를 제공한다고 했다. ssl인증서를 발급받을때 서버는 자신의 공개키를 인증기관에 알려주기때문에 ssl인증서 안에는 서버의 공개키가 있다. 이를 통해 클라이언트는 서버의 공개키를, 서버는 자신의 비공개키를 가지고 있으므로 클라이언트와 서버가 통신할때 공개키와 비공개키를 이용해서 암호화를 통해 통신을 할 수 있게되는것이다!
(하지만 사실 여기서 성능문제이슈로 실제 데이터를 암호화할때는 공개키와 비공개키가 아닌 대칭키를 사용하게 되는데 자세한 내용은 다음 블로그를 참고해보면 좋을거같다.)
https 적용하기
먼저 ssl 인증서를 발급받기위해 cloudFlare를 이용하는 방식과 certbot을 이용하는 방식이 있었는데 cloudflare를 이용해서 발급을 받아보았지만 머가 문제인지 적용이 안되서 certbot을 사용하게 되었다.(시도해보면서 느낀건 cloudflare을 통해 https를 적용할려면 가비아에서 DNS서버를 cloudflare로 바꿔주어야 하고 인증서와 같은 pem파일을 직접 다운받고 ec2로 파일을 옮겨줘야하는 번거로움이 있었지만 certbort은 간단하게 알아서 다해주어서 무척 편리했다.)
아무튼 적용과정은 위의 블로그에 자세한 내용이 나와있어 블로그글을 참고하는게 더 좋을거같지만 그래도 일단은 남겨보겠다
docker run -it --rm --name certbot \
-v '/etc/letsencrypt:/etc/letsencrypt' \
-v '/var/lib/letsencrypt:/var/lib/letsencrypt' \
certbot/certbot certonly -d 'example.com' --manual --preferred-challenges dns --server https://acme-v02.api.letsencrypt.org/directory서버에서 도커를 이용해 certbot을 실행준다. example.com 에 발급받을 서버의 도메인 주소를 입력해주면된다.
(우리는 서브도메인을 사용하고 있었기에 votogether.com 와 *.votogether.com 두개의 인증서를 발급받았다.)
하다보면 어쩌구저쩌구 화면이 뜨는데 동의 약관을 하고나면 마지막에 아래와 같은 내용이 뜬다.
Please deploy a DNS TXT record under the name:
_acme-challenge.votogether.com.
with the following value:
gf0Llud*********************************************
Before continuing, verify the TXT record has been deployed. Depending on the DNS
provider, this may take some time, from a few seconds to multiple minutes. You can
check if it has finished deploying with aid of online tools, such as the Google
Admin Toolbox: https://toolbox.googleapps.com/apps/dig/#TXT/_acme-challenge.votogether.com.
Look for one or more bolded line(s) below the line ';ANSWER'. It should show the
value(s) you've just added.여기서 gf0...으로 시작하는 내용을 가비아에 접속해 DNS 설정 레코드에서 설정해준다.
server {
listen 443 ssl;
listen [::]:443 ssl;
...
ssl_certificate /etc/letsencrypt/live/votogether.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/votogether.com/privkey.pem;
ssl_certificate /etc/letsencrypt/live/votogether.com-0001/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/votogether.com-0001/privkey.pem;
location / {
...
}
}그리고나서 발급받은 ssl 인증서(인증서 체인)와 개인키파일의 경로를 nginx에서 설정해주면 끝이다.
이렇게 certbot을 통해 ssl 인증서를 발급받고 적용해보았다. 해당 ssl 인증서는 let's encrypt라는 기관에서 발급 받은것이며 인증서 만료기간은 3개월이다. 따라서 자동 갱신을 설정해줘야하는데 설정은 레벨4때 설정할거 같다.
