http vs https

이전에는 많은 사이트들이 http를 사용했으나, 요즘 공신력 있거나 보안이 중요한 사이트들은 https를 사용하는 것을 볼 수 있다. 기관으로부터 검증된 사이트만 주소에 https 사용이 허가된다. 그냥 http를 사용하는 사이트의 경우 이제 주소창에 이처럼 '안전하지 않다'와 같은 표시가 뜨게 된다. 

 

http와 https 의 차이점을 알아보기 전, http는 무엇을 뜻하는 걸까?

 

HTTP - Hypertext Transfer Protocol

http는 한마디로 서로 다른 시스템들 사이에서 통신을 주고받게 해주는 가장 기초적인 프로토콜(통신 규약)이라고 설명할 수 있습니다. 즉, hypertext인 html을 전송하기 위한 통신규약을 의미한다.  웹 서핑을 할 때 서버에서 우리 브라우저로 데이터를 전송해 주는 용도로 가장 많이 사용된다. 

 

그렇다면 HTTPS와 다른 점은 무엇인가?

HTTPS 의 S는 Secure 즉 http에 보안이 추가된 것이라고 생각하면 된다. http의 문제는 서버에서부터 브라우저로 전송되는 정보가 암호화되지 않는다는 것이었다. 이 말은 즉슨, 데이터가 쉽게 도난당할 수 있다는 것이다. HTTPS 프로토콜은 SSL(보안 소켓 계층)을 사용함으로써 이 문제를 해결했다. 여기서 SSL은 무엇일까? 

 

SSL(Secure Socket Layer) 은 서버와 브라우저 사이에 안전하게 암호화된 연결을 만들 수 있게 도와주고, 서버 브라우저가 민감한 정보를 주고받을 때 이것이 도난당하는 것을 막아주는 역할을 합니다. 이 SSL 인증서가 http와는 다르게 https에서 보안 역할을 담당하는 것이다. SSL인증서란 클라이언트와 서버간의 통신을 제3자가 보증을 해주는 문서이다. 클라이언트가 서버에 접속하면 서버는 클라이언트에게 인증서를 전달한다. 그러면 클라이언트는 이 인증서를 보고, 신뢰할 수 있는 사이트인지 확인 후 데이터를 보내는 등 다음 절차를 수행하게 되는 것이다. 

 

SSL의 핵심은 암호화입니다. 암호화 기법에는 대칭키 방식과 비대칭키 방식이 있다. 

그 동안 널리 사용되어 온 암호화 방식은 대칭키 방식이다. 메시지를 보내는 쪽과 받는 쪽이 메시지를 암호화하고, 이를 다시 메시지로 바꾸는, 즉 복호화하는 같은 방식을 공유하는 것. 즉, 내가 암호화 키를 가지고 있어서 암호화 시킨다음 메시지를 전송하면 나와 동일한 암호화 키를 가진 상대방은 암호화된 메시지를 키로 풀어서 읽을 수 있는 것이다. 그렇다면 맨 처음에 이 키를 양쪽이 공유해야 메시지를 계속 암호화해서 주고받을 수 있는 것인데, 처음 키를 공유할 때 누가 중간에 이 키를 가로챈다면 아무리 암호화해서 전송해도 말짱 꽝이 될 수밖에 없는 것이다. 이게 대칭키의 한계라고 생각하면 된다. 

이러한 한계를 넘고자 비대칭키, 또는 공개키라고 불리는 시스템을 만들게 된다. 이 시스템에서는 두 키가 사용되게 된다. 이것은 위에 대칭키처럼 동일하지 않다. 각각 다른 키 두개가 한쌍으로 움직인다고 생각하면 된다. 즉, A키로 암호화한 메시지를 위에서는 A키로만 복호화할 수 있었다면, 비대칭키 방식에서는 A키로 암호화한 메시지를 B키로만 복호화할 수 있다. 따라서 암호화된 메시지(ex. 아이디, 비밀번호)를 받는 쪽에서(ex. 네이버) 비밀키(빨간색)를 가지고 있고, 공개키(초록색)는 말 그대로 대중들에게 공개한다. 사용자는 이 공개키를 통해 아이디와 비밀번호를 암호화해서 네이버에 전달하게 되고, 네이버는 개인키를 통해 아이디와 비밀번호를 인식하게 됩니다. 중간에 누군가 공개키와 로그인 정보를 가로채게 되더라도, 개인키는 네이버만 가지고 있기 때문에 공개키로는 아이디와 비밀번호를 풀 수 없게 된다. 

그렇다면, 네이버가 우리에게 뿌린 공개키를 네이버에서 뿌린 거라고 확신할 수 있어야 한다. 이것을 인증해주는 공인된 민간기업들이 있다. 줄여서 CA(Certificate Authorithy) 라고 부르는 곳이다. 우리가 사용하는 브라우저(크롬, 사파리, 파이어폭스...)에는 CA목록이 내장되어 있다.

 

우리가 사용하는 브라우저에서 네이버에 처음 접속할 때, 클라이언트와 브라우저는 일종의 탐색과정을 거치게 되는데 이 과정을 handshake라고 한다. 클라이언트는 일종의 랜덤 데이터를 생성해 서버에 보낸다. 이걸 받은 서버는 답변으로 서버측에서 만든 랜덤 데이터와 해당 서버의 인증서를 같이 실어 보낸다. 이걸로 악수를 했다고 생각하면 된다. 그럼 클라이언트는 이 실어보낸 인증서가 진짜인지 가짜인 지 브라우저에 내장된 CA목록을 통해 확인하게 된다. CA의 인증을 받은 인증서들은 해당 CA의 개인키로 암호화가 되어 있다. 이 개인키가 진짜라면 브라우저에 저장된 CA의 공개키로 복호화할 수 있게 된다. 이 공개키로 복호화될 수 있는 인증서를 발급할 수 있는 건 그에 대응하는 개인키를 가진 CA뿐이기 때문이다. 만약 CA안에 있는 인증서로 복호화할 수 없다면 위와 같이 not secure가 뜨게 된다. 

 

성공적으로 복호화된 인증서에는 이 서버의 공개키가 포함되어 있다. 이제 지금부터 받아지는 데이터들은 대칭키 방식과 비대칭키 방식이 혼합되어 서로 주고받게 된다. 보안이 중요한데 왜 대칭키 방식을 써서 정보를 교환하느냐에 대한 의문이 있을 것이다. 비대칭키 방식으로 메시지를 암호화 및 복호화하는 건 대칭키로 할 때보다 컴퓨터에 훨씬 큰 부담을 주게 된다. 일일이 암호화, 복호화하는 건 무리다. 따라서 이 대칭키를 공유할 때 비대칭키를 사용하게 되면 추후 대칭키 방식으로만 교환하게 되더라도 정보가 탈취될 수 없는 것이다. 처음 악수할 때 생성된 두 무작위 데이터로 클라이언트는 이걸 혼합해 어떠한 임시키를 만들게 됩니다. 이 임시키는 서버의 공개키로 암호화 되어 서버로 보내진 다음, 양쪽에서 일련의 과정을 거쳐 동일한 대칭키가 만들어지게 되는 것이다. 이제 이 대칭키는 서버와 클라이언트만 가지고 있기 때문에 제 3자가 알아볼 걱정은 없어지는 것이다. 

 

사실 이러한 보안 장치는 정말 최소한의 필수요건이라 할 수 있다.