이번 글에서는 왜 HTTP가 아닌 HTTPS를 사용 하는 것이며 HTTPS는 어떠한 동작방식으로 작동하는지에 대해서 알아보겠습니다.
평상시에 인터넷을 하면서 HTTP, HTTPS에 대해서는 많이 들어봤을 것입니다.
일반적인 웹 사이트들을 보면 위와 같이 http://, https://와 같이 되어 있을 것입니다. http에는 자물쇠가 잠겨있지 않고, https에는 자물쇠가 잠겨있는 것을 보아 https가 좀 더 안전해보입니다. 왜 더 안전하고 http에는 어떠한 단점이 존재하는지 먼저 알아보겠습니다.
평문(암호화 하지 않은) 통신이기 때문에 도청 가능통신 상대를 확인하지 않기 때문에 위장 가능완전성을 증명할 수 없기 때문에 변조 가능
HTTP는 좋은 점과 편리한 점이 많은 프로토콜이지만, 위와 같은 단점을 가지고 있습니다. 하나씩 어떠한 내용인지 알아보겠습니다.
HTTP를 사용할 리퀘스트나 리스폰스 통신 내용은 HTTP 자신을 암호화하는 기능은 없기 때문에 통신 전체가 암호화 되지는 않습니다. 즉, 평문으로 HTTP 메세지를 보내게 됩니다.
TCP/IP는 도청 가능한 네트워크이기 때문에 암호화를 하지 않고 통신을 하게 되면 중간에 누가 흠쳐볼 수 있다는 뜻입니다. 세계의 많은 네트워크 장비와 기기 등등이 다 연결되어 있을텐데 그 과정에서 누군가 메세지를 흠쳐보는 것은 그렇게 어려운 일이 아닙니다.
만약 로그인/회원가입 같이 비밀번호를 입력하는 중요한 경우에 HTTP 평문으로 통신하면 어떻게 될까요? 누군가 중간에 통신을 도청해서 비밀번호를 그대로 볼 수 있다는 뜻이 됩니다. 이러면 당연히 보안에 좋지 않습니다. 이렇게 누군가 중간에서 도청을 하지 않기 위해서는 암호화가 필요합니다. 암호화에는 몇 가지 방법이 있지만 그 중에 통신 암호화에 대해서 알아보겠습니다.
HTTP에는 암호화 구조가 없지만 SSL(Secure Socket Layer)이나 TLS(Transport Layer Security)이라는 다른 프로토콜을 조합함으로써 HTTP 통신 내용을 암호화할 수 있습니다. 이렇게 HTTP + SSL을 조합한 프로토콜을 바로 HTTPS라고 합니다. (이 내용은 아래에서 자세히 다루겠습니다.)
HTTP를 사용한 리퀘스트나 리스폰스에서는 통신 상대를 확인하지 않습니다. 어떤 말인가 하면 만약에 http://www.gyunny.com 이라는 주소가 있다고 가정해보겠습니다. A, B, C 라는 사람이 모두 해당 URL로 접속할 수 있는데 이 때 서버 입장에서는 클라이언트가 누군지 확인할 수 없습니다. 즉, 리퀘스트를 보낸 곳이 신뢰할 수 있는 클라이언트 인지, 서버인지를 알 수 없다는 뜻입니다.
이러한 단점을 어떻게 보완할 수 있을까요? 이럴 때 사용하는 것이 SSL 증명서 입니다. HTTP에서는 통신 상대를 확인할 수 없지만 SSL로 상대를 확인할 수 있습니다. SSL은 암호화뿐만 아니라 상대를 확인하는 수단으로 증명서를 제공하고 있습니다.
(해당 내용도 아래에서 자세히 알아볼 것입니다.)
완전성이란 정보의 정확성을 가르킵니다. 어떤 말인가 하면 제가 A라는 웹 사이트에서 파일을 다운 받았는데, 해당 파일이 A 웹 사이트 서버의 파일과 같은 파일인지를 확신할 수 없다는 뜻입니다.
통신 도중에 변조될 수 있다는 가능성이 남아있습니다.(이렇게 중간에 리퀘스트나 리스폰스를 빼앗아 변조하는 공격을 중간자 공격이라고 합니다.) 만약 통신 중간에 변조가 되었다고 해도 알 수 있는 방법이 없습니다.
위의 이유들을 보면선 왜 HTTP가 아닌 HTTPS를 사용해야 하는구나 정도의 느낌은 올 것입니다. 이제 HTTPS에 특징과 작동 방식에 대해 알아보면서 위에서 얘기했던 내용들을 좀 더 자세히 알아보겠습니다.
아까 위에서 HTTPS는 HTTP + SSL 프로토콜을 합친 것이라고 하였습니다.
위와 같이 HTTP가 직접 전송 계층과 통신하는 것이 아니라 중간에 SSL이라는 계층을 넣어 HTTP는 SSL와 통신하고 SSSL이 TCP와 통신하게 됩니다. 이와 같이 SSL을 사용함으로써 HTTP는 HTTPS로서 암호화와 증명서와 완전성 보호를 이용할 수 있게 됩니다.
이제 HTTPS의 특징은 간략하게 알아보았으니 동작 방식에 대해서 알아보겠습니다. HTTPS 동작방식을 이해하려면 대칭키(공통키), 비대칭키(공개키) 방식에 대한 이해가 필요합니다.
대칭키는 공통키라고도 불립니다. 공통키는 무엇일까요? 단어에서 어느정도 예상할 수 있듯이 암호화와 복호화에 하나의 키를 사용하는 방식을 공통키 암호라고 부릅니다.
즉, 클라이언트, 서버 모두 하나의 키로 암호화 복호화를 하는 것입니다. 통신할 때 공통키를 상대방에게 전달할 필요는 없다는 장점을 가지고 있습니다. 하지만 반면에 공통키만 가지고 있으면 누구든 복호화를 할 수 있다는 단점이 될 수도 있습니다.
클라이언트, 서버 모두 같은 공통키를 가지기 위해서 최초 통신에서는 공통키를 통신에 담는 과정이 필요합니다. 이 때 공통키를 탈취당할 가능성이 존재하기에 공통키 암호 방식에도 한계점이 존재합니다.
그래서 나온 것이 바로 비대칭키(공개키) 방식 입니다.
공개키 암호에서는 서로 다른 두 개의 키 페어(쌍)을 사용합니다. 한쪽은 비밀키(private key)라 부르고 다른 한쪽은 공개키(public key)라고 부릅니다. 이름에서 알 수 있듯이 비밀키는 누구에게도 알려져서는 안되는 키이며 공개키는 누구에게나 알려져도 되는 키입니다.
공개키 암호화를 사용한 암호화는 암호를 보내는 측이 상대의 공개키를 사용해 암호화합니다. 그리고 암호화된 정보를 받아들인 상대는 자신의 비밀키를 사용해 복호화를 합니다. 이 방식은 암호를 푸는 비밀키를 통신으로 보낼 필요가 없기 때문에 도청에 의해서 키를 빼앗길 걱정은 없습니다.
그러면 비대칭키만 사용해서 통신하면 문제가 없을테니 이것만 사용하면 되겠다 라고 생각할 수 있습니다. 하지만 비대칭키는 대칭키에 비해서 속도가 많이 느릴 뿐 아니라 컴퓨터에 많은 부하를 준다는 단점을 가지고 있습니다.
그래서 현재는 대칭키 + 비대칭키를 사용하는 방식인 하이브리드 암호 시스템을 사용하고 있습니다. 어떠한 방법으로 같이 사용하고 있을까요?
키를 교환하는 곳에서는 공개키 암호를 사용하고 그 후의 통신에서 메세지를 교환하는 곳에서는 공통키 암호를 사용합니다.
말로만 보면 무슨 말인가 싶지만 점점 하나씩 알아보면 이해가 될 것입니다.
공개키 암호에는 느리고 컴퓨터에 부하를 많이 준다는 단점 말고 하나 더 존재합니다. 문제점은 공개키가 진짜인지 아닌지를 증명할 수 없다는 것입니다. 예를들어 네이버 서버의 공개키 암호를 사용해서 통신을 시작하려 할 때 해당 공개키가 네이버의 진짜 공개키인지를 어떻게 증명할 수 있을까요?
도중에 공격자가 공개키를 바꿔치기 했을지도 모르는데 말이죠...
이 문제를 해결하는 데는 인증 기관(CA:Certificate Authority)에서 발행하는 공개키 증명서가 이용되고 있습니다. 인증 기관은 아무나 할 수 있는 것이 아니라 엄격한 심사의 과정을 거치게 됩니다. 즉, 서버, 클라이언트가 모두 신뢰할 수 있는 제3자 기관입니다.
- 먼저 서버에서 인증 기관에
서버 공개키를 제출합니다. - 인증 기간은
서버로부터 제출된 공개키를 자신의 비밀키를 통해 암호화한 후에 합니다. - 인증기관이 발급한 인증서에 2번에서 암호화한 서버의 공개키를 인증서에 담아서 서버에게 보내줍니다.
- 서버는 이 인증 기관에 비밀키로 암호화된 자신의(서버의) 공개키를 담은 인증서를 클라이언트에게 보냅니다.
- 인증서를 받은 클라이언트는
인증 기관 CA의 공개키를 사용해서 서버의 공개키를 복호화 합니다. 이 때 복호화가 잘 된다면 인증 기관이 발급한 인증서라는 것과 실제 서버의 공개키라는 것을 알 수 있습니다.(즉, 신뢰할 수 있습니다.)
여기서 4번의 과정을 보면 클라이언트는 CA 기관의 비밀키로 암호화 되어 있는 서버의 공개키가 담긴 인증서를 받게 됩니다. 인증서에 들어있는 서버의 공개키를 복호화 하기 위해서는 CA의 공개키가 필요합니다. 그러면 어떻게 CA 기관의 공개키를 클라이언트에게 전달할 수 있을까요?
통신 중에는 어떤 방법을 사용하더라도 안전하게 전달하는 것은 어렵기 때문에 많은 브라우저가 주요 인증 기관의 공개키를 사전에 내장한 상태로 제품을 내놓고 있습니다. 다음으로는 SSL HandShake는 어떠한 과정으로 이루어지는지 알아보겠습니다.
TCP 3-way-Handshake 과정 이후에 SSL Handshake가 진행됩니다.
- 클라이언트가
Client Hello 메세지(랜덤 메세지)를 서버에게 보내면서 SSL 통신을 시작합니다. 메세지에는 클라이언트가 어떤 암호 알고리즘을 사용할 수 있는지 등등이 포함되어 있습니다. - 서버가 SSL 통신이 가능한 경우에는
Server Hello 메세지(랜덤 메세지)로 응답합니다. 클라이언트가 보낸 암호 알고리즘 중에 가능한 알고리즘을 하나 선택해 클라이언트에게 응답해줍니다. 그리고서버가 Certificate(인증서)를 클라이언트에게 전송합니다즉, 신뢰성 있는 CA 기관으로 부터 발급 받은 증명서를 클라이언트에게 보내게 됩니다. - 클라이언트는 서버로부터 받은 증명서를 브라우저에 내장되어 있는 인증 기관의 공개키로 검증하고,
인증서가 진짜 CA 기간으로 부터 발급 받은 것인지 확인합니다. 여기서인증서 안에 들어있는 CA 기관의 비밀키로 암호화 되어있는 서버의 공개키를 복호화하여 서버의 공개키를 클라이언트에서 얻을 수 있습니다. - 서버가 Server Hello Done 메세지를 송신하고 최초의 SSL 통신이 끝났음을 통지합니다.
- 클라이언트는 클라이언트에서 서버로 보낸
Client Hello(랜덤 메세지)와서버에서 클라이언트로 응답한 Sever Hello(랜덤 메세지)를 조합하여Pre-Master-Secret-Key를 만듭니다.(Pre-Mster-Secret-Key는 클라이언트와 서버 사이에공통키로 사용될 키이기 때문에 절대로 외부로 노출되어서는 안됩니다.) - 클라이언트는
증명서에 들어있던 서버의 공개키를 이용해서 Pre-Master Secret Key를 암호화한 후에 서버로 보냅니다.(Pre-Master-Secret-Key는 외부에 노출되면 안되기 때문에 이 과정에서비대칭키(공개키)방식으로 통신하게 됩니다.) - 서버는 자신의 공개키로 암호화 되어 있는
Pre-Master-Secret-Key를자신의 비밀키로복호화한 후에 클라이언트와 서버에서 사용할공통키를 가지게 됩니다. - 클라이언트와 서버는 모두
Pre-Master-Secret-Key라는공통키를 가졌기 때문에 이후 통신에는대칭키(공통키)방식으로 사용해서 통신하게 됩니다.
인증기관 CA가 자신의 비밀키로 인증서를 암호화하여야 해당 인증서가 자기가(CA) 발급한 것이라는 것을 증명할 수 있기 때문입니다.
즉, CA의 비밀키로 인증서를 암호화한 것은 CA의 공개키로 복호화할 수 있습니다. 다시 말해, CA 공개키로 복호화가 된다면 CA가 발급한 인증서라는 것을 알 수 있습니다.
CA에서 발급한 인증서라는 것을 증명하기 위해 CA 기관만 알고 있는 자신의 비밀키를 사용해서 증명서를 암호화하는 것입니다.