SSL/TLS & Certificate Authority(CA)

1. Prerequisites 👩‍💻

일단 URL 주소를 입력했을 때 DNS 에 의해 실제 IP 주소를 얻는 과정은 생략하고 CA 만 집중해서 이야기해보도록 한다. 요즘 HTTP 를 사용하는 사이트는 없다고 봐도 된다. 그렇다면 HTTPS 는 어떻게 HTTP 보다 안전할 수 있는 것일까?

HTTP 는 HTTPS 에 암호화를 해서 좋다는데 무조건 암호화만 하면 되는것일까?

우선 대칭키(Symmetric Key) 암호화는 사용할 수 없다. 모두가 동일한 키로 암호화/복호화를 한다면 그저 에너지 낭비일 뿐이다. 그래서 우리는 비대칭키(Asymmetric Key) 암호화를 사용해야한다. 그러면 비대칭키 암호화만 하면 안전할까?

NO‼️ 여기서 놓치면 안 되는 가장 중요한 것이, 암호화를 통해 데이터를 주고 받기 이전에 상대를 신뢰할 수 있는지 여부다. 신뢰할 수 없는 상대와 비대칭키 암호화로 데이터를 주고 받는다면, 다른 사람들은 내가 보내는 정보를 훔칠 수 없겠지만 신뢰할 수 없는 상대에게 정보를 자발적으로 내 정보를 넘겨주고 있는 꼴이 되는 것이다.

이전 포스팅에서 Public Key & Private Key 가 특별하고 중요한 이유는 바로 서명(Signature)이라고 했다. 이 서명 덕에 우리는 상대를 신뢰할 수 있는 것이다.

그러면 어떻게 그 서명이 올바른 서버라는 것을 확신할 수 있을까? 아래 그림을 보자.

1. 서버가 자신의 비대칭키를 생성 후 공개키와 서버의 정볼르 인증 기관에 보낸다.
2. 인증 기관이 자신의 개인키로 서버의 공개키와 정보에 서명해 인증서를 발급 후 서버에 보낸다.

이렇게 신뢰할 수 있는 기관으로부터 서버는 인증기관의 개인키로 암호화된 인증서를 갖게 되고, 각 브라우저 제조사는 신뢰할 수 있는 여러 인증 기관이 배포한 공개키를 브라우저에 포함시킨다.

여기까지가 우리가 어떤 사이트에 접속하기 전에 완료되어 있는 것이다.

---

2. When I Connect the Site 👩‍💻

이제 우리가 서버에 접속할 차례다. 우리가 HTTPS 를 통해 어떻게 서버를 신뢰할 수 있는지 그림을 통해 알아보자.

1. 클라이언트가 서버에 접속 요청을 보낸다.
2. 서버는 인증기관이 발급한 인증서를 클라이언트에 보낸다.
3. 클라이언트는 브라우저에 내장된 공개키로 인증서를 복호화 한다. 이렇게 전자인증을 통해 우리는 서버의 정보와 공개키를 획득한다. 인증기관의 공개키로 복호화가 가능하다면 신뢰할 수 있는 서버임이 증명된다.
4. 클라이언트는 인증서에서 획득한 서버의 공개키로 자신의 대칭키를 암호화 시켜 서버에 안전하게 전송한다.
5. 서버는 자신의 개인키로 복호화 해 클라이언트의 대칭키를 획득한다.
6. 이제 대칭키를 유일하게 클라이언트와 서버만 가지고 있으므로 둘은 안전하고 빠르게 통신을 한다.

즉, 우리가 HTTPS 를 신뢰할 수 있는 이유는 Public Key & Private Key 의 서명(Signature) 기능과 신뢰할 수 있는 인증 기관과 브라우저를 바탕으로 이루어진다.

---

3. Certificate Authority 👩‍💻

신뢰할 수 있는 인증서 발급 기관은 여러 곳이 존재하는 데, 대부분 유료로 운영된다.

• IdenTrust (아이덴트러스트)
• Symantec (시만텍)
• GoDaddy (고데디)
• Comodo (코모도)
• GlobalSign (블로벌사인)
• DigiCert (디지서트)
• Verisign (베리사인)

HTTPS 의 보급을 높이기 위해 제공되는 Let’s Encrypt 는 무료로 제공된다. 기간은 짧지만 주기적으로 갱신이 가능해 개인 서버나 NAS 와 같은 곳에 무료로 인증서를 발급 받아 설치할 수 있다.