🔥 TIL - Day 30

간만에 CS 공부 !!

이번에는 HTTPS에 대해 알아봤다.
HTTPS에 앞서 HTTP 에 대해 간단하게 알아보자.

HTTP 쓰지 그냥 ..
은행, 쇼핑몰 등 직접적으로 결제가 이루어질 수 있는 웹 사이트의 경우 HTTP 요청에 공개되면 치명적인 정보를 포함할 수 있다. (카드, 계좌 등 ...) 이런 정보를 포함할 수 있는 HTTP 요청에 보안상 취약점이 있을수 없다.

원래는 이런 취약점이 치명적인 웹 사이트만 HTTPS를 사용했는데 이제는 여러 SEO (검색엔진최적화)에서도 HTTPS가 상위권 노출의 우선권을 갖는다고 발표할 정도로 표준으로 자리를 잡고 있다고 한다.

HTTPS ?
HTTP는 요청의 body 부분이 요청 그대로 서버로 전송되기 때문에 문제가 발생한다고 했다. 여기서 가장 단순한 해법이 HTTPS이다.

HTTP body 부분을 통째로 암호화하자.

이렇게만 알고 넘어가면 아쉬우니 어떻게 암호화를 하는 지에 대해서도 간단하게 알아보자.

공개키 방식으로 암호화
HTTPS 암호화가 이루어지는 절차를 가볍게 살펴보자.

1. 암호화된 요청을 받고 싶은 서버는 공개키와 개인키 쌍을 갖고 있어야 한다. 개인키는 서버가 갖고 있지만 공개키는 어떤 방법으로든 클라이언트에게 전달(공개)되어야 한다.
   자신의 공개키를 어떤 게시판에 올려두고 자신의 서버에 접근하는 브라우저가 알아서 가져가게 할 수는 없으니 이런 처리를 다른 서비스를 이용한다.
   공개키에 대한 관리를 도와주는 기관을 인증기관 CA라고 한다. (당연히 CA에 요금일 지불하고 서비스를 이용하는 것이다.)

2. CA는 서버로부터 공개키에 대한 관리를 위임받고 인증서 (SSL 인증서)를 만들어 서버로 발급하는데 인증서에는 인증서 발급자인 CA에 대한 정보와 CA의 디지털 서명, 서버의 공개키 등이 포함된다. 이 인증서는 CA의 개인키로 암호화 된다.

3. 클라이언트인 웹 브라우저가 서버에 접속했을 때 서버는 가장 먼저 인증서를 전달한다. 인증서를 전달받은 웹 브라우저는 자신이 해당 인증서를 발급한 CA의 공개키를 갖고 있는 지 확인하고 갖고 있다면 인증서를 복호화한다.

4. 브라우저는 서버로 요청을 보낼 때 복호화된 인증서에 담긴 서버의 공개키로 HTTP body 부분을 암호화한다.

5. 서버는 암호화된 HTTP 요청을 자신의 개인키로 복화할 수 있다.

복잡하다.. 복잡한 만큼 이런 방식이 우리에게 주는 이점이 있을 것이다.

1. 웹 브라우저는 우리 서버를 신뢰할 수 있게 되었다.

• CA는 믿을만한 기관을 말한다. CA를 믿을 수 있다면 CA의 공개키를 풀어서 확인한 서버는 신뢰할 수 있다.

2. 인증서가 변조되지 않음을 보장한다.

• 자세히 다루지는 않았지만 인증서에는 CA의 전자서명이 포함된다. 전자서명은 인증서의 내용을 해싱 한 결과를 CA의 개인키로 암호화한 것이다. 인증서를 확인하는 쪽에서 CA의 개인키로 암호화된 서명을 복호화해서 클라이언트가 해싱한 값과 복호화된 서명값을 비교하여 데이터의 위변조 여부를 확인한다.

3. 우리가 목표로 한 HTTPS 요청을 위한 키 관리도 또한 안전하게 이뤄진다.