HTTP?
HTTP는 Hyper Text Transfer Protocol의 줄임말으로써 서버와 클라이언트간에 데이터를 주고 받는 프로토콜입니다. HTTP는 텍스트, 이미지,영상, JSON 등등 거의 모든 형태의 데이터를 전송할수 있습니다.
HTTP는 보안적으로 안전한가?
HTTP 통신은 클라이언트와 서버간의 통신에 있어서 별다른 보안 조치가 없기때문에 만약 누군가 네트워크 신호를 가로챈다면 HTTP의 내용은 그대로 외부에 노출됩니다.
중요 정보가 없는 소규모의 프로젝트라면 문제가 되지 않겠지만 고객의 개인정보나 비밀을 취급하는 대규모 서비스라면 큰 보안적 허점이 될 것입니다.
이런 문제를 해결하기 위해 등장한 것이 HTTPS입니다.
HTTPS?
기존의 HTTP 프로토콜은 전송계층의 TCP위에서 동작합니다. 여기서 SSL(Secure Sockets Layer)이라는 보안계층이 전송계층 위에 올라갑니다. HTTPS는 SSL 위에 HTTP를 얹어서 보안이 보장된 통신을 하는 프로토콜입니다. 이 통신 방식을 SSL 암호화 통신 이라고도 합니다. SSL 암호화 통신은 공개키 암호화 방식이라는 알고리즘을 통해 구현됩니다.
공개키 암호화 방식에는 공개키와 개인키 두 종류의 키가 존재합니다.
한쪽 키로 데이터를 암호화 했다면 오직 다른쪽 키로만 복호화를 할 수 있습니다. 개인키는 보통 서버를 운영하는 회사가 가지고 공개키는 CA(Certificate Authority)라는 인증받은 기업들에서 관리합니다.
-
먼저 애플리케이션 서버(A)를 만드는 기업은 HTTPS를 적용하기 위해서 공개키와 개인키를 만듭니다.
-
그 다음에 신뢰할 수 있는 CA 기업을 선택하고 그 기업에 내 공개키를 관리해달라고 계약하고 돈을 지불합니다.
-
계약을 완료한 CA 기업은 또 CA 기업만의 공개키와 개인키가 있습니다.
CA 기업은 CA기업의 이름과 A서버의 공개키, 공개키의 암호화 방법 등의 정보를 담은 인증서를 만들고, 해당 인증서를 CA 기업의 개인키로 암호화해서 A서버에게 제공합니다.
-
A서버는 암호화된 인증서를 갖게 되었습니다. 이제 A서버는 A서버의 공개키로 암호화된 HTTPS 요청이 아닌 요청(Request)이 오면 이 암호화된 인증서를 클라이언트에게 줍니다.
-
이제 클라이언트 입장에서, 예를 들어 A서버로 index.html 파일을 달라고 요청했습니다. 그러면 HTTPS 요청이 아니기 때문에 CA기업이 A서버의 정보를 CA 기업의 개인키로 암호화한 인증서를 받게되겠지요.
-
여기서 중요합니다. 세계적으로 신뢰할 수 있는 CA 기업의 공개키는 브라우저가 이미 알고 있습니다!
-
브라우저가 CA 기업 리스트를 쭉 탐색하면서 인증서에 적혀있는 CA기업 이름이 같으면 해당 CA기업의 공개키를 이미 알고 있는 브라우저는 해독할 수 있겠죠? 그러면 해독해서 A서버의 공개키를 얻었습니다.
-
그러면 A서버와 통신할 때는 A서버의 공개키로 암호화해서 Request를 날리게 되겠죠.
