HTTP와 HTTPS는 무엇이 다를까? 웹브라우저와 서버의 대화 방식

인터넷 주소를 입력하고 엔터를 누르면 화면이 잠시 멈춘다. 길게 느껴질 때도 있지만 대부분은 눈을 한 번 깜빡이기도 전에 새로운 페이지가 나타난다. 너무 익숙한 장면이라 그 짧은 시간 동안 무슨 일이 벌어지는지 생각해 볼 기회는 많지 않았다.

브라우저는 주소를 입력받았다고 해서 곧바로 화면을 그리지 못한다. 먼저 서버를 찾아야 하고, 어떤 프로그램과 연결할지도 알아야 한다. 앞선 글에서 살펴본 IP 주소와 포트 번호가 이 과정에 필요하였다.

목적지까지 찾아갔다면 이제 말을 걸 차례이다. 브라우저는 서버에 필요한 자료가 무엇인지 알려야 하고, 서버는 그 요청을 이해한 뒤 결과를 돌려주어야 한다. 요청한 자료가 없다면 없다고 말해야 하고, 권한이 부족하다면 접근할 수 없다는 사실도 알려야 한다.

결국 웹페이지를 연다는 것은 브라우저가 서버에 말을 걸고 답을 받는 과정이다. 여기에서 브라우저와 서버가 사용하는 대화의 규칙을 HTTP라고 부른다. 그리고 그 대화가 중간에서 드러나거나 바뀌지 않도록 보호한 방식이 HTTPS이다.

한줄 요약

HTTP는 브라우저와 서버가 요청과 응답을 주고받는 약속이고, HTTPS는 그 대화를 암호화하여 안전하게 보호하는 방식이다.

브라우저는 서버에 어떻게 말을 걸까?

웹브라우저는 서버에 접속한 뒤 필요한 자료를 구체적으로 요청한다. 첫 화면이 필요할 수도 있고, 게시물 한 편이나 이미지 한 장이 필요할 수도 있다. 로그인 버튼을 눌렀다면 사용자가 입력한 정보를 서버에 전달하고 확인해 달라고 요청해야 한다.

사람이 식당에 들어가 자리에 앉았다고 해서 음식이 저절로 나오지는 않는다. 메뉴를 고르고 주문해야 하며, 식당은 주문 내용을 확인한 뒤 음식을 내어준다. 웹 통신도 이와 비슷하다. 서버에 연결하는 일은 식당에 도착한 것에 가깝고, HTTP 요청은 원하는 메뉴를 주문하는 것에 가깝다.

다만 브라우저는 사람처럼 두루뭉술하게 말하지 않는다. 어느 주소의 자료가 필요한지, 어떤 방식으로 처리하기를 원하는지, 자신이 어떤 형식의 데이터를 받을 수 있는지를 일정한 형식에 맞추어 전달한다.

서버도 요청받은 자료만 던져주고 끝내지 않는다. 요청이 정상적으로 처리되었는지, 해당 자료가 존재하는지, 다른 주소로 이동해야 하는지 같은 정보를 결과와 함께 보낸다. 브라우저는 이 답을 확인한 뒤 웹페이지를 구성한다.

HTTP는 이러한 요청과 응답의 형식을 정해 둔 약속이다. 풀어 쓰면 Hypertext Transfer Protocol이지만, 이름을 외우는 것보다 브라우저와 서버가 같은 방식으로 대화할 수 있도록 만든 규칙이라고 이해하는 편이 쉽다.

크롬에서 잘 보이던 사이트가 엣지나 사파리에서도 열리는 이유도 여기에 있다. 브라우저와 서버를 만든 회사는 서로 다르지만 HTTP라는 공통 규칙을 따르기 때문에 기본적인 대화가 가능하다.

페이지를 여는 것도 로그인하는 것도 같은 요청은 아니다

브라우저가 서버에 보내는 요청은 목적에 따라 방식이 달라진다. 단순히 자료를 가져오는 요청과 새로운 정보를 전달하는 요청을 똑같이 처리할 수는 없기 때문이다.

웹페이지나 게시물을 읽을 때 자주 사용하는 방식이 GET이다. 말 그대로 서버에 있는 자료를 가져오겠다는 뜻에 가깝다. 검색 결과에서 글을 누르거나 뉴스 기사를 열고 이미지를 불러오는 과정에서도 GET 요청이 사용될 수 있다.

반면 로그인 정보를 보내거나 게시물을 등록하고 파일을 올리는 일에는 POST 방식이 자주 쓰인다. 브라우저가 서버에 정보를 전달하고 그에 따른 처리를 요청하는 경우이다.

사용자 눈에는 모두 버튼을 한 번 누르는 행동으로 보인다. 그러나 서버 입장에서는 자료를 보여 달라는 요청과 새로운 내용을 저장해 달라는 요청이 전혀 다르다. HTTP는 이 차이를 구분할 수 있도록 여러 요청 방식을 마련하였다.

서버가 돌려주는 답에도 일정한 번호가 붙는다. 웹사이트를 이용하다가 한 번쯤 본 404도 그 가운데 하나이다. 브라우저는 서버를 찾았고 대화에도 성공했지만, 서버 안에서 요청한 자료를 찾지 못했다는 뜻이다.

페이지가 정상적으로 전달되었을 때는 주로 200번대 상태가 사용된다. 주소가 다른 곳으로 바뀌었다면 300번대, 사용자의 요청에 문제가 있다면 400번대, 서버 내부에서 문제가 생겼다면 500번대 상태가 나타날 수 있다.

구분	서버에 전달하는 의미	쉽게 볼 수 있는 상황
GET	서버에 있는 자료를 보내 달라고 요청한다.	웹페이지와 게시물, 이미지 등을 불러올 때 사용한다.
POST	정보를 전달하고 새로운 처리를 요청한다.	로그인하거나 게시물을 작성하고 파일을 전송할 때 사용한다.
200	요청이 정상적으로 처리되었다.	페이지와 데이터가 문제없이 전달되었다.
404	요청한 자료를 서버에서 찾지 못하였다.	주소를 잘못 입력했거나 페이지가 삭제된 경우 나타난다.
500	서버 내부에서 문제가 발생하였다.	서버 프로그램이 요청을 처리하지 못한 경우 나타난다.

상태 코드는 사람에게 보여주기 위한 장식이 아니다. 브라우저와 서버, 검색엔진과 각종 프로그램이 처리 결과를 빠르게 판단하기 위한 약속이다. 사용자는 오류 화면만 보게 되지만 그 안에서는 이미 어떤 문제가 발생했는지에 대한 답이 오간 셈이다.

짧은 생각

웹사이트에서 오류가 나타나면 인터넷 전체가 고장 났다고 생각하기 쉽다. 그러나 404처럼 서버가 정확한 이유를 알려주는 오류도 있다. 문제가 생겼을 때 어디까지 정상적으로 연결되었는지를 살펴보면 원인을 훨씬 차분하게 찾을 수 있다.

대화는 되었지만 누군가 듣고 있다면?

HTTP 덕분에 브라우저와 서버는 같은 방식으로 대화할 수 있었다. 문제는 그 대화의 내용이 항상 안전하게 보호되는 것은 아니라는 점이다.

초기의 웹은 지금처럼 많은 개인정보와 금융정보를 다루지 않았다. 공개된 문서를 읽고 다른 문서로 이동하는 일이 중심이었다. 웹이 단순한 문서 열람 공간에 가까웠을 때는 통신 내용을 암호화해야 한다는 요구가 지금만큼 크지 않았다.

그러나 인터넷에서 로그인하고 물건을 사고 은행 업무를 처리하기 시작하면서 상황이 달라졌다. 아이디와 비밀번호, 카드번호와 주소처럼 외부에 드러나서는 안 되는 정보가 웹을 통해 오가기 시작하였다.

암호화되지 않은 HTTP 통신은 봉투에 넣지 않은 편지와 비슷하다. 보내는 사람과 받는 사람 사이에서 누군가 내용을 볼 수 있는 위치에 있다면 편지에 적힌 내용을 읽을 가능성이 생긴다.

인터넷 데이터는 출발지에서 목적지로 한 번에 건너가지 않는다. 여러 네트워크와 통신장비를 지나 목적지에 도착한다. 이 과정에서 통신 내용을 엿보거나 데이터를 가로챌 수 있는 환경이 만들어지면 사용자가 어떤 정보를 보냈는지 드러날 수 있다.

내용을 훔쳐보는 것만 문제가 되는 것도 아니다. 전달 중인 정보를 바꾸어 사용자가 원하지 않은 화면이나 파일을 받게 만들 수도 있다. 사용자는 정상적인 서버와 대화한다고 생각하지만 실제로는 중간에서 누군가 통신에 끼어들었을 가능성도 있다.

연결되었다는 사실만으로는 부족하였다. 대화 내용이 보이지 않아야 했고, 이동하는 동안 바뀌지 않았다는 것도 확인해야 했다. 무엇보다 지금 말을 나누는 상대가 사용자가 찾던 진짜 서버인지 확인할 방법이 필요하였다.

HTTPS는 대화를 감추는 것에서 시작한다

HTTPS는 HTTP의 대화 방식에 보안 기능을 더한 것이다. 브라우저가 요청하고 서버가 응답하는 기본 구조는 그대로 유지한다. 대신 본격적인 대화를 시작하기 전에 서로를 확인하고 안전한 통신 경로를 만든다.

주소가 HTTP로 시작하는 웹서비스는 일반적으로 TCP 80번 포트를 사용한다. HTTPS는 주로 TCP 443번 포트를 사용한다. 앞선 글에서 포트 번호를 살펴본 이유가 여기에서도 이어진다. 브라우저는 주소에 표시된 통신 방식에 따라 서버의 어느 포트로 연결할지를 판단한다.

HTTPS에서 실제 통신 보호에 사용되는 대표적인 기술이 TLS이다. 예전에는 SSL이라는 이름이 널리 알려졌고 지금도 SSL 인증서라는 표현을 자주 사용한다. 다만 오늘날의 보안 통신에서는 SSL을 발전시킨 TLS가 주로 사용된다.

브라우저와 서버가 HTTPS 연결을 시작하면 바로 웹페이지부터 보내지 않는다. 먼저 어떤 암호화 방식을 사용할지 확인하고, 서버가 내놓은 인증서도 살펴본다. 이 과정이 정상적으로 끝나야 암호화된 통신이 시작된다.

그 뒤에 오가는 HTTP 요청과 응답은 알아보기 어려운 형태로 바뀌어 전달된다. 중간에서 데이터를 가져가더라도 통신에 사용한 키를 모르면 원래 내용을 바로 읽기 어렵다.

전송 중인 데이터가 바뀌었는지도 확인할 수 있다. 공격자가 통신 내용을 중간에서 고치려고 하면 브라우저와 서버는 전달된 정보가 원래 상태와 다르다는 사실을 알아낼 수 있다.

자물쇠가 있다고 모두 믿어도 될까?

암호화된 통로만 만든다고 문제가 모두 해결되지는 않는다. 가짜 사이트와 안전하게 암호화 통신을 한다면 사용자의 정보는 엉뚱한 상대에게 안전하게 전달되는 셈이다.

그래서 HTTPS에서는 서버가 누구인지 확인하는 과정이 중요하다. 서버는 브라우저에 디지털 인증서를 제시한다. 인증서에는 사이트의 주소와 인증서를 발급한 기관, 사용할 수 있는 기간과 공개키 같은 정보가 들어 있다.

브라우저는 접속한 주소와 인증서에 적힌 주소가 일치하는지 확인한다. 인증서의 사용기간이 끝나지 않았는지, 신뢰할 수 있는 인증기관이 발급했는지도 살펴본다.

이 과정에서 문제가 발견되면 브라우저는 경고 화면을 띄운다. 사이트 주소와 인증서가 다르거나 인증서가 만료되었을 때 나타나는 보안 경고가 대표적이다.

주소창에 표시되는 자물쇠는 이러한 확인을 거쳐 암호화 통신이 이루어지고 있다는 뜻이다. 다만 자물쇠가 사이트 운영자의 양심이나 제공하는 정보의 정확성까지 보증하지는 않는다.

가짜 쇼핑몰이나 악성 사이트도 자신이 가진 도메인으로 인증서를 발급받을 수 있다. 그 사이트와의 통신 자체는 암호화될 수 있지만 사이트의 목적까지 안전하다는 뜻은 아니다.

결국 자물쇠와 함께 주소도 확인해야 한다. 익숙한 사이트와 철자가 한두 글자 다른 주소는 아닌지, 필요 이상으로 많은 개인정보를 요구하지는 않는지 살펴볼 필요가 있다. HTTPS는 중요한 안전장치이지만 사용자의 판단까지 대신해 주지는 않는다.

짧은 생각

자물쇠 표시를 보면 사이트 전체가 안전하다고 생각하기 쉽다. 그러나 자물쇠가 보장하는 것은 주로 통신하는 상대와 연결 구간이다. 기술이 만들어 준 신뢰의 범위를 정확히 아는 일도 보안의 한 부분이다.

처음에는 복잡하게, 그다음에는 빠르게

HTTPS가 데이터를 암호화하는 방식은 하나만 사용하지 않는다. 처음 연결을 만들 때와 실제 데이터를 계속 주고받을 때 서로 다른 암호 기술의 장점을 활용한다.

서버 인증서에는 공개할 수 있는 키와 관련된 정보가 포함된다. 공개키 방식은 서로 다른 두 개의 키를 사용하는데 하나는 외부에 공개하고 다른 하나는 서버가 안전하게 보관한다.

이 방식은 상대방을 확인하고 안전하게 정보를 교환하는 데 유리하다. 그러나 웹페이지의 모든 이미지와 글, 영상 데이터를 공개키 방식으로 처리하면 계산해야 할 양이 많아진다.

그래서 브라우저와 서버는 처음 연결할 때 공개키 기술을 이용해 안전하게 통신 준비를 하고, 실제 웹 데이터를 주고받을 때는 속도가 빠른 대칭키 암호화를 사용한다.

대칭키 방식은 암호화와 복호화에 같은 비밀키를 사용한다. 처음에는 안전한 방법으로 둘만 아는 열쇠를 정하고, 그 뒤의 대화는 그 열쇠로 잠가서 주고받는다고 생각하면 이해하기 쉽다.

사용자는 이러한 과정을 직접 보지 못한다. 주소를 입력한 뒤 페이지가 열리기를 기다릴 뿐이다. 하지만 그 짧은 시간 동안 브라우저는 인증서를 확인하고 암호화 방법을 정하며, 데이터를 보호할 키를 마련한다.

HTTPS를 사용하면 HTTP보다 해야 할 일이 늘어난다. 그럼에도 오늘날의 컴퓨터와 서버는 이 과정을 빠르게 처리하며, 안전한 통신으로 얻는 장점이 훨씬 크기 때문에 대부분의 웹서비스가 HTTPS를 기본으로 사용한다.

정보가 중요해질수록 확인해야 할 것도 많아진다

HTTPS는 인터넷 쇼핑이나 인터넷뱅킹에만 필요한 기술이 아니다. 기업의 업무시스템과 공공기관의 행정정보체계, 병원의 의료정보시스템처럼 중요한 정보를 다루는 웹 기반 서비스에서도 안전한 통신은 기본 조건이 되었다.

과거에는 업무용 컴퓨터마다 전용 프로그램을 설치하여 정보체계에 접속하는 경우가 많았다. 지금은 브라우저를 통해 서버에 접속하고 기능을 사용하는 웹 기반 방식도 널리 활용된다. 사용자는 브라우저에서 자료를 조회하고 입력하며, 서버는 중앙에서 기능과 데이터를 관리한다.

국방 분야의 정보체계도 이러한 웹 기술과 완전히 떨어져 있지 않다. 작전 상황과 각종 보고자료를 조회하거나 업무정보를 입력하는 일부 화면은 브라우저와 서버가 요청과 응답을 주고받는 구조로 구현될 수 있다.

다만 다루는 정보가 중요할수록 HTTPS 하나만으로 충분하다고 볼 수는 없다. 사용자 신원을 더 엄격하게 확인해야 하고, 직책과 임무에 따라 볼 수 있는 정보도 달라져야 한다. 접속 기록을 남기고 이상한 접근을 찾아내는 일도 필요하다.

군 정보체계에서는 폐쇄된 통신망과 별도의 암호체계, 보안장비와 사용자 인증수단을 함께 적용한다. 일반 인터넷에서 사용하는 HTTPS의 개념이 사라지는 것이 아니라 더 높은 보호 수준을 위한 여러 장치가 그 위에 더해지는 셈이다.

처음부터 군 이야기를 꺼내지 않아도 HTTP와 HTTPS를 이해하다 보면 자연스럽게 같은 질문에 도달한다. 누가 정보를 요청했는가, 그 사람에게 보여주어도 되는가, 이동하는 동안 누군가 내용을 보거나 바꾸지는 않았는가 하는 문제이다.

쇼핑몰의 결제정보와 작전정보는 중요도의 차이가 크다. 그러나 신뢰할 수 있는 사용자가 신뢰할 수 있는 서버와 안전하게 정보를 주고받아야 한다는 원리는 닮아 있다.

작은 자물쇠 뒤에서 이루어지는 일

HTTP는 브라우저와 서버가 서로 알아들을 수 있도록 만든 대화의 규칙이다. 브라우저가 필요한 자료나 작업을 요청하면 서버는 결과와 함께 처리 상태를 알려준다.

그러나 대화가 가능하다는 사실만으로 안전한 것은 아니었다. 통신 내용을 다른 사람이 볼 수 있었고, 중간에서 데이터가 바뀔 가능성도 있었다. 사용자가 접속한 서버가 진짜 서버인지 확인하는 문제도 남아 있었다.

HTTPS는 이 문제를 줄이기 위해 서버의 인증서를 확인하고 통신 내용을 암호화한다. 브라우저와 서버는 안전한 연결을 먼저 만든 뒤 그 안에서 HTTP 요청과 응답을 주고받는다.

주소창의 자물쇠는 아주 작게 보인다. 하지만 그 뒤에서는 인증서의 주소와 유효기간을 확인하고, 암호화 방식을 정하고, 데이터를 보호하기 위한 키를 교환하는 과정이 이루어진다.

그렇다고 자물쇠만 보고 모든 사이트를 믿어서는 안 된다. HTTPS는 통신 구간을 보호하지만 허위정보와 악성 프로그램, 약한 비밀번호와 잘못된 권한 설정까지 해결하지는 못한다. 통신 보안은 전체 보안의 중요한 부분이지만 전부는 아니다.

지금까지 IP 주소는 목적지 컴퓨터를 찾았고 포트 번호는 그 안에서 통신할 프로그램을 구분하였다. HTTP는 브라우저와 서버가 나눌 대화의 형식을 정했고, HTTPS는 그 대화를 안전하게 보호하였다.

그런데 우리가 주소창에 입력하는 문자열에는 통신 방식과 서버의 위치만 들어 있는 것이 아니다. 서버 안에서 어떤 자료를 찾아야 하는지도 함께 담겨 있다. 다음 글에서는 인터넷 주소인 URL이 어떤 부분으로 나뉘며, 하나의 주소가 원하는 페이지까지 어떻게 안내하는지 살펴본다.

짧은 생각

인터넷은 보이지 않는 약속이 겹겹이 쌓여 움직인다. 주소를 찾고 통신할 프로그램을 고른 뒤 같은 규칙으로 대화하고, 그 대화를 안전하게 감싼다. 화면에 페이지 한 장이 나타나는 짧은 순간에도 많은 기술이 자신의 역할을 나누어 수행하고 있다.