갑자기 생각이 들었다. 이렇게 대충 알고 있어서야 내가 과연 네카라 개발자가 될 수 있을까 라고.
어쨌든 내 뇌를 깨어나게 해준 HTTP 완벽 가이드 와 후배 yom-hardy 에게 감사를 표한다.
Https 란
우선 Https 는 무엇에 대한 약자인가.
wikipedia 에서는 다음과 같이 표현하고 있다.
HyperText Transfer Protocol over Secure Socket Layer
HTTP over TLS
HTTP over SSL
HTTP Secure
https 를 사용하면 모든 http 요청과 응답 데이터는 네트워크로 보내지기 전에 암호화된다.
간단하게 https 에 대해서 알고 싶다면 위의 내용만 알면 된다.
https 는 http 와 다르게 SSL, TLS 를 이용하여 구현된다. 그리고 https 는 tcp 위에 놓인 보안 계층 위의 http 이다.
우선 우리는 TLS 기반으로 구현된 https 프로토콜을 사용하는 것이다.
그러나 일반적으로 SSL 사용하기 때문에 TLS 라고 부르기 보다는 SSL 로 부르는 것 같다. 물론 TLS 도 SSL 3.0 기반으로 구현된 듯 하다. (openSSL 도 그렇고,, 나도 TLS 가 익숙치는 않다.)
어쨌든 HTTP 완변 가이드에서는 다음과 같이 얘기한다.
SSL 과 TLS 는 매우 비슷하기 때문에,
이 책에서는 SSL 과 TLS 양쪽 모두를 표현하는 용어로 엄밀하지는 않지만 'SSL' 이란 단어를 사용한다.
그렇기에 나도 SSL 이라고 표현하여 글을 작성해보도록 하겠다.
먼저 알아보는 간단한 Https 의 동작 과정
우선 위 그림과 같이 Client, CA, Server 이 3가지로 표현을 할 수 있다.
CA(Certificate Authority) 는 인증 기관을 뜻하는 것으로 다른 곳에서 사용하기 위한 디지털 인증서를 발급하는 하나의 단위이다.
Server 는 쉽게 예를 들면 티스토리(tistory.com)이라고 생각하도록 하자.
Client 는 지금 현재 크롬으로 티스트로 블로그를 접속하려는 나 이다.
신뢰할 수 있는 사이트
크롬 브라우저에서 티스토리 블로그를 접속해보면 아래 사진과 같이 나타난다.
보안 연결이 사용 되었다고 나와있으며, [인증서: (유효)] 라고 표시 돼 있다.
이것은 말 그대로 크롬 부라우저에서 이 tistory.com 을 신뢰한다는 얘기이다.
그렇다면 우리는 어떤 과정으로 크롬 브라우저에서 tistory.com 을 신뢰하게 되었는지 알아야 한다.
 |
 |
먼저, windows 나 iOS, Anroid 에는기본적으로 신뢰할 수 있는 루트 인증서 목록이 존재한다. 만약 서버의 인증서가 신뢰할 수 있는 루트 인증서 목록에 존재한다면 해당 서버의 인증서는 믿을 수 있는 기관에서 발급한 것이라고 생각한다.
바로 위 사진과 같이 윈도우에 설치 되어 있는 인증서도 볼 수 있을 것이다.
그리고 가장 하단에 보면 "발급 대상" 에 DigiCert Global Root G2 에 "발급자" DigiCert Global Root G2 라고 되어 있는 부분도 볼 수 있다.
그렇기 때문에 tistory.com 에 적용 되어 있는 루트 인증서가 위 사진과 같이 인증서 목록에 있기 때문에 신뢰할 수 있다고 나오는 것이라고 생각하면 된다.
SSL 인증서 발급 받기
그렇다면 서버는 인증서를 어떻게 받을까?
우리는 수동으로 신뢰할 수 있는 루트 인증 기관에서 인증서를 구매를 해야 한다. 구매하기 위해서 사이트 도메인 등 여러 가지 정보를 입력해야 한다.
그리고 루트 인증 기관은 해당 사이트를 신뢰할 수 있다고 판단하면 해당 사이트의 인증서를 회원가입 시 입력했던 메일이나 파일로 다운 받을 수 있도록 해준다.
그렇다면 서버에서는 해당 인증서를 aws eb 에 등록시켜주는 식으로 하면 된다.
https 로 클라이언트와 서버 간 요청 시
다시 본론으로 돌아와 이제 https 로 클라이언트와 서버 간 요청 시 어떻게 동작을 하는가에 대해서 자세히 살펴보도록 하자.
좀 많이 생략해서 저렇게 표현할 수 있을 것 같다.
그래서 https 로 통신할 때는 대칭키와 비대칭키를 이용한다고 할 수 있다.
처음에 클라이언트에서는 SSL 인증서에서 주는 공개키를 이용하는 것이고, 서버에서는 SSL 인증서의 비밀키를 갖고 있는 것이다. 클라이언트에서는 주고 받았떤 랜덤 값으로 pre-master key 를 생성하고 공개키를 이용하여 pre-master key 를 암호화 하여 서버로 보낸다. 서버에서는 해당 pre-master key 를 SSL 인증서 비밀키로 복호화 한다. 이제 서버와 클라이언트 모두 pre-master key 를 갖고 있기에 master key 라고 표현을 한다. 이제 요청과 응답에 대한 평문, 데이터를 클라이언트와 서버에서 지원하는 암호화 알고리즘에 master key 를 이용하여 암호화 또는 복호화하여 서로 통신한다.
그러면 왜 대칭키를 사용하냐? 라고 생각할 수 있다. 그러나 비대칭키로 공개키, 비밀키를 이용할 때 비용이 크기 때문에 평문, 데이터에 대해서는 대칭키를 사용하는 것으로 생각하면 된다.
