HTTP
HyperText Transfer Protocol로 약자로 웹에서 데이터를 주고받기 위해 사용되는 프로토콜이다.
HTTP는 단순히 데이터를 전송하기 위한 프로토콜이기에 취약점이 다수 존재한다.
먼저, 데이터가 평문 형태로 전송되기에 중간에 누군가가 데이터를 들여다볼 수도 있고, (스니핑)
누군가 요청을 가로채서 데이터를 악의적으로 변조해도 이를 검증할 방법이 없다. (중간자공격)
이 문제점을 해결하기 위해서 새로 나온 프로토콜이 HTTPS이다.
HTTPS
HTTP + Secure로 HTTP의 보안 취약점을 해결하기 위해 나온 프로토콜이다.
SSL/TLS 프로토콜을 이용하여 데이터를 암호화하여 전송하고, SSL/TLS 인증서를 이용해 웹 사이트의 신뢰성을 검증할 수 있다. SSL/TLS를 이용한 데이터 암호화 전송에 대칭키와 공개키/비대칭키가 사용되고, SSL/TLS 인증 과정에서 공개키/비대칭키가 사용된다.
이제 방금 말한 내용들이 무슨 소리인지 알기 위해 나왔던 개념들인 SSL/TLS, 대칭키 그리고 공개키/비대칭키에 대해 알아보자.
SSL/TLS
SSL은 Secure Socket Layer의 약자로 위 HTTP의 취약점들을 해결해 주는 프로토콜이다.
주요 역할이 데이터 암호화, 신뢰성 보장, 데이터 무결성 보장이다.
SSL은 1995년에 나온 프로토콜인데 현재는 보안 취약점이 많아서 더 이상 사용되지 않고 이제는 이를 개선한 TLS가 표준으로 사용되고 있다.
대칭키와 공개키/비대칭키
결론부터 알아보면 HTTPS는 데이터를 암호화하여 전송할 때 대칭키와 공개키/비대칭키를 모두 사용한다.
간단하게, 대칭키를 이용하여 데이터를 암호화하여 주고받고, 이러한 대칭키를 공유하기 위 공캐기/비대칭키를 사용한다.
대칭키
하나의 동일한 키를 가지고 데이터를 암호화/복호화하는 방식이다.
즉, 이 방식을 이용하여 데이터를 암호화하여 주고받으려면 클라이언트가 키를 이용해 데이터를 암호화하여 전송하면 서버에서도 클라이언트가 암호화에 사용한 키를 이용하여 복호화해야 한다.
자.. 근데 대칭키는 하나의 문제가 있다.
대칭키 자체가 암/복호화에 사용되기에 너무나도 중요한데 이러한 대칭키를 양쪽이 가지고 있으려면 어느 한쪽에서 상대에게 최초 대칭키 전송을 해줘야 하는데 그 과정은 어떻게 안전하게 진행하나?
이때 이용하는 것이 공개키/비대칭키이다.
공개키/비대칭키
공개키/비대칭키는 키가 두 개다. 개인키와 공개키가 존재하고 여기서 개인키는 서버 또는 클라이언트가 혼자만 보관하는 키이다. 공개키는 말 그대로 누구나 볼 수 있도록 공개해 둔 키이다. 공개키를 이용해 암호화한 데이터는 해당 공개키의 주인만 개인키를 이용하여 복호화할 수 있다. 또 반대로 개인키를 이용하여 암호화한 데이터는 해당 주인의 공개키로만 복호화를 할 수 있다.
즉, 개인키를 이용해 암호화하여 데이터를 주면 받는 쪽에서는 해당 데이터의 주인의 공개키로 복호화를 하기에 누구로부터 온 데이터인지 검증할 수 있고 (신뢰성 보장)
내가 원하는 쪽에 데이터를 보낼 때 공개키를 이용해 암호화한 데이터를 원하는 쪽에서만 데이터를 읽을 수 있다. (기밀성 보장)
암호화도 가능하고 키를 전송할 필요도 없기 때문에 이 방식이 그냥 대칭키보다 더 좋은 거 아닌가? 싶을 수도 있는데 그냥 단점이 명확하다.
비대칭키 암호화는 연산량이 대칭키 방식에 비해 많기 때문에 느리다. 그렇기에 대칭키의 빠른 속도를 이용하고 대칭키의 문제점인 대칭키 공유 과정에서만 비대칭키 방식을 이용하는 것이다. < 이게 HTTPS 가 둘 다 사용하는 이유이다.
HTTPS의 동작 정리
즉, 다시 정리해 보면 대칭키를 이용하여 데이터를 암호화하여 주고받는데, 이 대칭키를 서로 공유하는 과정에 있어서 공개키/비대칭키를 이용하여 안전하게 대칭키를 공유하는 것이다. 이 과정이 TLS hand-shake 과정에서 일어나는 것이다.