![[Network] HTTP와 HTTPS](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FdiOdrN%2FbtsL7vTmSKe%2FX99clb6KkFkJeO2mKoZoL1%2Fimg.jpg)
HTTP와 HTTPS는 웹을 구성하는 가장 기본적인 프로토콜이다. 웹 브라우저로 웹 페이지를 열 때마다 HTTP나 HTTPS를 통해 서버와 통신한다. 주소창에서 흔히 보는 http://와 https://가 바로 이 프로토콜을 나타낸다.
이 두 프로토콜의 가장 큰 차이점은 보안이다. HTTP는 텍스트를 암호화하지 않은 채로 주고받기 때문에 누군가 중간에서 내용을 들여다보거나 변조할 수 있다. 반면 HTTPS는 데이터를 암호화해 전송하므로 중간에서 정보를 가로채더라도 내용을 알아볼 수 없다.
모던 웹에서는 HTTPS가 선택이 아닌 필수가 되었다. 구글은 HTTPS를 사용하는 웹사이트에 검색 순위 가산점을 부여하고, 크롬 브라우저는 HTTP 사이트를 방문할 때 '주의 요함' 경고를 표시한다. 이제 안전한 웹을 위해 HTTPS를 이해하고 도입하는 것이 모든 개발자의 기본 소양이 되었다.
🌐 HTTP 기본 개념
HTTP의 정의와 역할
HTTP는 HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜이다. 웹에서 이루어지는 모든 데이터 교환의 기초이며, 클라이언트-서버 프로토콜이기도 하다. 예를 들어 브라우저에서 www.google.com을 입력하면, 브라우저(클라이언트)가 구글 서버에 웹 페이지를 요청하고 서버가 이에 응답하는 과정이 HTTP를 통해 이루어진다.
하나의 완전한 웹 페이지는 여러 개의 하위 리소스들로 구성된다. 예를 들어 네이버 메인 페이지를 열면, 브라우저는 먼저 HTML 문서를 요청한다. 이후 HTML 문서를 파싱하면서 필요한 CSS 파일, 로고 이미지, 광고 영상, JavaScript 파일들을 추가로 요청한다. 이렇게 받아온 리소스들을 조합해서 우리가 보는 완성된 웹 페이지가 만들어진다. 여기서 브라우저가 보내는 각각의 메시지를 요청$_{request}$이라 하고, 서버가 응답하는 메시지를 응답$_{response}$이라 한다.
클라이언트-서버 모델
HTTP는 클라이언트-서버 프로토콜이다. 요청은 하나의 개체, 사용자 에이전트(또는 그것을 대신하는 프록시)에 의해 전송된다. 대부분의 경우 사용자 에이전트는 브라우저지만, 검색 엔진 인덱스를 채워넣고 유지하기 위해 웹을 돌아다니는 로봇 같은 프로그램이 될 수도 있다.
브라우저는 웹 페이지를 보여주기 위해 여러 단계를 거친다. 먼저 페이지의 HTML 문서를 가져오기 위한 요청을 전송한 뒤, 파일을 구문 분석해 실행해야 할 스크립트와 페이지 내 포함된 하위 리소스들(보통 이미지와 비디오)을 잘 표시하기 위한 레이아웃 정보(CSS)에 대응하는 추가적인 요청들을 보낸다. 브라우저는 완전한 문서인 웹 페이지를 표시하기 위해 이런 리소스들을 혼합한다. 브라우저에 의해 실행된 스크립트는 이후 단계에서 더 많은 리소스들을 가져올 수 있으며 브라우저는 그에 따라 웹 페이지를 갱신한다.
각각의 개별적인 요청들은 서버로 보내지며, 서버는 요청을 처리하고 response라고 불리는 응답을 제공한다. 이 요청과 응답 사이에는 여러 개체들이 있는데, 예를 들면 다양한 작업을 수행하는 게이트웨이 또는 캐시 역할을 하는 프록시 등이 있다.
HTTP 요청/응답 구조
HTTP는 사람이 읽을 수 있는 메시지로 데이터를 주고받는다. HTTP/1.1 기준으로 모든 메시지는 텍스트 형태이며, 요청(request)과 응답(response) 두 가지 타입이 있다.
요청 메시지는 클라이언트가 서버에게 보내는 메시지다. 웹 브라우저가 서버에 리소스를 요청할 때는 아래와 같은 형태의 메시지를 보낸다.
GET / HTTP/1.1
Host: developer.mozilla.org
Accept-Language: fr요청의 첫 줄에는 HTTP 메서드, 리소스 경로, HTTP 버전이 들어간다. GET이나 POST 같은 HTTP 메서드는 클라이언트가 수행하고자 하는 동작을 정의한다. 그 다음 줄부터는 헤더가 들어가는데, 서버가 요청을 처리할 때 참고할 수 있는 추가 정보들이 담긴다. POST처럼 서버로 데이터를 전송하는 메서드는 요청 본문에 해당 내용을 포함할 수 있다.
서버는 클라이언트의 요청을 처리한 후 응답 메시지를 보낸다. 응답 메시지의 예시는 다음과 같다.
HTTP/1.1 200 OK
Date: Sat, 09 Oct 2010 14:28:02 GMT
Server: Apache
Content-Type: text/html
<!DOCTYPE html...>
응답의 첫 줄은 상태 라인으로, HTTP 버전과 함께 요청 처리 결과를 알려주는 상태 코드와 상태 메시지가 포함된다. 헤더에는 응답에 대한 추가 정보가 들어가며, 본문에는 실제 요청한 리소스의 데이터가 들어간다. 최신 버전인 HTTP/2에서는 이런 메시지들이 이진 프레임으로 캡슐화되어 전송되지만, 메시지가 가진 구조적인 의미는 변함없이 유지된다.
HTTP 메서드와 상태 코드
웹 서버와 브라우저가 서로 통신할 때는 HTTP 메서드로 어떤 동작을 할지 알려주고, 상태 코드로 그 결과를 전달한다. 예를 들어 브라우저가 GET 메서드로 웹 페이지를 요청하면, 서버는 200 OK 상태 코드와 함께 페이지 내용을 응답한다.
먼저 주요 HTTP 메서드를 살펴보면, GET은 특정 리소스를 조회할 때 사용한다. 예를 들어 웹 페이지를 불러오거나 API에서 데이터를 가져올 때 사용한다. POST는 새로운 리소스를 만들 때 사용하는데, 회원가입이나 글쓰기 같은 동작이 여기에 해당한다. PUT은 리소스를 완전히 대체할 때, PATCH는 일부만 수정할 때 사용한다. DELETE는 이름 그대로 리소스를 삭제하는 용도다.
상태 코드는 크게 다섯 가지 그룹으로 나뉜다. 100번대는 정보성 응답으로, 요청이 처리 중임을 알려준다. 200번대는 성공 응답으로, 요청이 제대로 처리되었음을 나타낸다. 300번대는 리다이렉션으로, 요청한 리소스가 다른 주소로 이동했음을 알려준다. 400번대는 클라이언트 오류로, 요청에 문제가 있음을 뜻한다. 500번대는 서버 오류로, 서버에서 문제가 발생했음을 알려준다.
실제로 자주 마주치는 상태 코드를 보면, 200 OK는 요청이 성공했을 때, 201 Created는 새 리소스가 생성되었을 때 사용된다. 404 Not Found는 요청한 페이지를 찾을 수 없을 때, 403 Forbidden은 권한이 없는 페이지에 접근했을 때 만나게 되는 응답이다. 500 Internal Server Error는 서버에서 예상치 못한 에러가 발생했을 때 보게 된다.
🌐 HTTP의 한계
평문 통신으로 인한 보안 취약점
HTTP는 데이터를 전송할 때 누구나 읽을 수 있는 평문을 사용한다. 예를 들어 브라우저가 서버에 보내는 GET 요청은 아래와 같은 텍스트 형태다.
GET /hello.txt HTTP/1.1
User-Agent: curl/7.63.0 libcurl/7.63.0 OpenSSL/1.1.l zlib/1.2.11
Host: www.example.com
Accept-Language: en이런 평문 통신 방식은 보안상 심각한 문제를 일으킨다. 네트워크 연결을 모니터링하는 누군가가 전송되는 모든 내용을 그대로 읽을 수 있기 때문이다. 특히 사용자가 웹 사이트에서 중요한 정보를 제출할 때 위험하다. 로그인할 때 입력하는 비밀번호, 결제 시 입력하는 신용카드 정보, 기타 민감한 개인정보가 모두 평문으로 전송되어 도청될 수 있다.
서버의 응답 역시 마찬가지로 평문으로 전송된다. 이는 악의적인 공격자가 사용자가 어떤 정보를 요청하고 받는지 정확히 파악할 수 있다는 것을 의미한다. 즉, HTTP를 사용하면 통신 세션을 모니터링하는 누구나 주고받는 모든 요청과 응답을 읽을 수 있다.
중간자 공격 가능성
HTTP의 또 다른 심각한 보안 취약점은 중간자 공격$_{Man-in-the-middle \space attack}$에 취약하다는 점이다. 중간자 공격이란 두 당사자 간의 통신을 공격자가 몰래 가로채서 도청하거나 내용을 변조하는 공격 방식이다.
가장 흔한 중간자 공격 시나리오는 공공 WiFi를 통한 공격이다. 공격자는 정상적인 WiFi 접속점을 모방한 가짜 접속점을 만들어놓고 사용자의 접속을 유도한다. 예를 들어 'Hotel_Guest'라는 정상적인 WiFi가 있다면, 공격자는 'H0tel_Guest'처럼 비슷한 이름의 접속점을 만든다. 사용자가 이 가짜 접속점에 연결하면, 공격자는 사용자와 인터넷 사이에서 모든 통신을 감시하거나 조작할 수 있다.
HTTP는 이러한 중간자 공격을 막을 수 있는 어떠한 보안 메커니즘도 가지고 있지 않다. 공격자는 사용자의 웹 페이지 요청을 가로채서 악성 코드를 주입하거나, 로그인 정보와 같은 민감한 데이터를 훔칠 수 있다. 특히 금융 거래나 개인정보를 다루는 웹사이트를 이용할 때는 치명적인 피해로 이어질 수 있다.
데이터 변조 위험
HTTP는 클라이언트와 서버 사이에서 주고받는 데이터의 무결성을 보장하지 않는다. 즉, 데이터가 전송되는 과정에서 변조되더라도 이를 탐지할 수 없다. 공격자는 이러한 취약점을 이용해 전송 중인 데이터를 가로채어 변조할 수 있다.
예를 들어 전자상거래 사이트에서 상품의 가격 정보가 HTTP를 통해 전송될 때, 악의적인 사용자는 네트워크 상에서 이 정보를 가로채 가격을 조작할 수 있다. HTML 폼의 hidden 필드에 다음과 같이 가격 정보가 포함되어 있다면,
<input type="hidden" id="1008" name="cost" value="70.00">
이런 식으로 공격자는 더 낮은 가격으로 변조할 수 있다. URL 파라미터를 통해 전달되는 정보도 마찬가지로 변조가 가능하다. 단순히 가격 정보뿐만 아니라 사용자 권한, 계좌 이체 금액 등 중요한 데이터가 변조될 수 있다.
🌐 HTTPS 등장 배경
보안 필요성 증가
1994년 말, HTTP 프로토콜에 가장 큰 변화가 일어났다. 당시 웹은 더 이상 학술 네트워크가 아닌, 광고주, 일반 사용자, 악의적인 공격자들이 민감한 개인정보를 차지하기 위해 경쟁하는 정글이 되어가고 있었다.
특히 전자상거래 웹사이트의 등장으로 보안의 필요성이 대두되었다. 넷스케이프 커뮤니케이션즈는 이 문제를 해결하기 위해 기존 TCP/IP 스택 위에 SSL$_{Secure \space Sockets \space Layer}$이라는 새로운 암호화 전송 계층을 추가했다. SSL은 서버와 클라이언트 사이에서 주고받는 메시지를 암호화하고 그 진정성을 보장했다.
웹 애플리케이션이 점점 더 강력해지고 주소록, 이메일, 사용자 위치 정보와 같은 민감한 정보에 접근해야 할 필요성이 커지면서, 보안 계층의 필요성은 전자상거래를 넘어 웹 전반으로 확대되었다. 이후 SSL은 표준화 과정을 거쳐 TLS$_{Transport \space Layer \space Security}$가 되었다.
SSL/TLS의 도입
보안 통신의 필요성이 커지면서, 1996년 넷스케이프는 보안 소켓 계층$_{SSL, \space Secure \space Sockets \space Layer}$을 발표했다. SSL은 클라이언트와 서버 간의 모든 통신을 암호화해 데이터를 안전하게 주고받을 수 있게 해주는 보안 프로토콜이었다.
이후 SSL은 전송 계층 보안$_{TLS, \space Transport \space Layer \space Security}$으로 발전했다. TLS는 웹 브라우징, 이메일, 메시징 등 다양한 통신에서 감청과 데이터 변조를 방지한다. 클라이언트와 서버가 TLS로 통신할 때는 어떠한 제3자도 메시지를 변조하거나 엿볼 수 없다.
TLS의 중요한 특징은 디지털 인증서를 통한 신원 확인이다. 현대의 모든 브라우저는 서버가 유효한 디지털 인증서를 제공하도록 요구한다. 이를 통해 사용자는 자신이 의도한 정확한 서버와 통신하고 있음을 확신할 수 있다. 클라이언트와 서버 모두 인증서를 제공하면 상호 인증도 가능하다.
보안 기술의 발전에 따라 TLS도 계속 진화하고 있다. 2020년 초부터는 대부분의 브라우저가 보안 취약점이 발견된 TLS 1.0과 1.1 버전의 지원을 중단했으며, 현재는 더욱 안전한 TLS 1.2나 1.3 버전의 사용을 권장하고 있다. TLS 1.2와 1.3은 아래의 'HTTPS 장단점 - 성능 오버헤드'에서 잠깐 다룬다.
인증서를 통한 신뢰 확보
웹에서 보안 통신의 핵심 과제는 '상대방이 진짜 내가 의도한 서버가 맞는가'를 확인하는 것이다. 예를 들어 온라인 쇼핑몰에서 결제할 때, 내가 입력하는 카드 정보가 정말 그 쇼핑몰로 전송되는 것인지, 아니면 해커가 만든 가짜 사이트로 전송되는 것인지 어떻게 알 수 있을까?
이 문제를 해결하기 위해 도입된 것이 디지털 인증서다. 디지털 인증서는 웹사이트나 서비스의 신원을 증명하는 전자 문서로, 고유한 디지털 서명, 인증서를 발급받은 웹사이트의 식별 정보, 발급 기관의 정보, 그리고 유효 기간 등을 포함한다. 브라우저가 HTTPS로 웹사이트에 접속하면, 해당 서버는 자신의 인증서를 브라우저에 제시한다.
이러한 인증서는 신뢰할 수 있는 인증 기관$_{Certificate \space Authority, \space CA}$에서 발급한다. GoDaddy, VeriSign, Entrust 같은 인증 기관들이 대표적이다. 브라우저들은 이런 신뢰할 수 있는 인증 기관들의 목록을 내장하고 있고 이들이 발급한 인증서를 신뢰한다. 만약 인증서가 유효하지 않거나 신뢰할 수 없는 곳에서 발급된 것이라면, 브라우저는 경고를 표시해 사용자에게 위험을 알린다.
🌐 HTTPS 동작 방식
TLS 핸드셰이크 과정
TLS 핸드셰이크는 TCP 연결이 수립된 후에 시작된다. 즉, 클라이언트와 서버는 먼저 TCP 3-way 핸드셰이크(SYN, SYN-ACK, ACK)를 통해 기본적인 연결을 만든 다음, 그 위에서 TLS 핸드셰이크를 수행한다. 그 다음 클라이언트와 서버가 안전한 통신을 시작하기 위해 서로를 인증하고 암호화 방식을 결정하는 과정이다.
아래와 같은 단계로 진행된다.
- 클라이언트가 'ClientHello' 메시지를 보내며 통신을 시작한다. 이 메시지에는 클라이언트가 지원하는 TLS 버전, 사용 가능한 암호화 알고리즘 목록, 그리고 '클라이언트 무작위'라는 임의의 데이터가 포함된다.
- 서버는 'ServerHello' 메시지로 응답하고, 이어서 자신의 인증서('Certificate')를 전송한다. 그리고 서버의 초기 협상이 끝났음을 알리는 'ServerHelloDone' 메시지를 보낸다.
- 클라이언트는 서버의 인증서를 확인한 후, 'ClientKeyExchange' 메시지를 통해 예비 마스터 암호를 서버의 공개 키로 암호화해 전송한다.
- 클라이언트는 이제 'ChangeCipherSpec' 메시지를 보내 앞으로의 모든 통신을 새로운 세션 키로 암호화할 것임을 알린다. 그리고 'Finished' 메시지를 보내 자신의 핸드셰이크가 완료되었음을 알린다.
- 서버도 마찬가지로 'ChangeCipherSpec' 메시지를 보내고, 이어서 'Finished' 메시지를 보내 핸드셰이크를 완료한다.
이후부터는 협상된 세션 키를 사용해 안전한 통신을 시작한다.
대칭키/비대칭키 암호화
HTTPS는 통신의 보안을 위해 대칭키와 비대칭키 암호화를 모두 사용한다. 두 방식은 각각의 장점을 살려 다른 목적으로 활용된다.
비대칭키 암호화는 공개키와 개인키라는 서로 다른 두 개의 키를 사용한다. 공개키로 암호화한 데이터는 오직 개인키로만 복호화할 수 있다. TLS 핸드셰이크 과정에서 클라이언트는 서버의 TLS 인증서에 포함된 공개키를 사용해 데이터를 암호화하고, 서버는 자신만이 가지고 있는 개인키로 이를 복호화한다.
반면 대칭키 암호화는 암호화와 복호화에 동일한 키를 사용한다. 양쪽이 같은 키를 공유해야 하지만, 비대칭키 암호화보다 처리 속도가 빠르다는 장점이 있다. HTTPS에서는 실제 데이터를 주고받을 때 이 대칭키 방식을 사용하고 이때 사용되는 키를 세션 키라고 한다.
세션 키는 하나의 통신 세션을 위해 무작위로 생성되는 임시 키다. 브라우저가 웹사이트에 접속할 때마다 새로운 세션 키가 생성되며, 해당 세션이 종료되면 그 키는 폐기된다. 이런 방식으로 보안을 강화하는데 만약 한 세션의 키가 노출되더라도 다른 세션의 통신은 안전하게 보호된다.
HTTPS는 이 두 방식을 조합해서 사용한다. 먼저 TLS 핸드셰이크 과정에서 비대칭키 암호화를 사용해 안전하게 세션 키를 공유한다. 이후 실제 데이터 통신은 공유된 세션 키를 사용한 대칭키 암호화로 이루어진다. 이렇게 함으로써 비대칭키 암호화의 보안성과 대칭키 암호화의 효율성이라는 두 가지 장점을 모두 활용할 수 있다.
인증서의 역할
SSL/TLS 인증서는 웹사이트의 신원을 보장하고 암호화 통신을 가능하게 하는 디지털 문서다. 인증서는 웹사이트의 서버에 설치되어 있는 데이터 파일로, 해당 웹사이트의 신원 정보와 공개키 등 여러 중요한 정보를 포함한다.
인증서에는 다음과 같은 정보들이 포함되어 있다.
- 인증서가 발급된 도메인 이름
- 웹사이트 소유자나 조직의 정보
- 인증서를 발급한 인증 기관의 정보와 디지털 서명
- 인증서의 유효 기간
- 웹사이트의 공개키
인증서는 웹사이트의 신원을 보증한다. 사용자가 접속한 웹사이트가 진짜 해당 도메인의 정당한 소유자인지 확인할 수 있게 해 공격자가 가짜 웹사이트를 만들어 사용자를 속이는 것을 방지한다. 또한 안전한 암호화 통신을 위한 공개키를 제공한다. 클라이언트는 인증서에 포함된 공개키를 사용해 데이터를 암호화해 서버로 전송할 수 있다. 이 데이터는 서버가 가진 개인키로만 복호화할 수 있어 통신의 기밀성을 보장한다. 마지막으로 HTTPS 통신을 가능하게 한다. 웹사이트가 HTTPS를 사용하려면 반드시 유효한 SSL/TLS 인증서가 필요하다. 현대 브라우저들은 인증서가 없거나 유효하지 않은 웹사이트에 접속할 때 사용자에게 보안 경고를 표시한다.
이러한 인증서는 신뢰할 수 있는 인증 기관$_{CA}$에서 발급받아야 한다. 자체적으로 인증서를 만들 수도 있지만, 이런 자체 서명 인증서는 브라우저가 신뢰하지 않아 보안 경고가 표시된다. 인증 기관은 인증서 발급 전에 해당 도메인의 소유권을 검증하고, 자신의 디지털 서명을 인증서에 포함시켜 그 인증서의 신뢰성을 보증한다.
| Rank | Issuer | Usage | Market Share |
|---|---|---|---|
| 1 | Let's Encrypt | 59.8% | 63.7% |
| 2 | GlobalSign | 20.8% | 22.2% |
| 4 | Sectigo | 5.7% | 6.0% |
| 6 | GoDaddy Group | 3.9% | 4.1% |
| 5 | DigiCert Group | 3.2% | 3.5% |
| 3 | Certum | 0.6% | 0.6% |
🌐 HTTPS의 장단점
보안성 향상
HTTPS는 기존 HTTP에 TLS 암호화를 추가하여 웹 통신의 보안을 크게 강화한다. 이는 마치 식당이 위생 검사에서 '합격' 판정을 받는 것과 같이, 웹사이트가 사용자의 데이터를 안전하게 처리할 수 있다는 것을 보증한다.
TLS 프로토콜은 통신 과정에서 데이터 도난을 방지한다. 사용자가 로그인할 때 입력하는 비밀번호나 결제 시 입력하는 신용카드 정보와 같은 민감한 데이터가 전송 중에 유출되는 것을 막을 수 있다. 또한 서버의 신원을 확인함으로써 공격자가 웹사이트를 사칭하는 것을 방지한다.
이런 보안상의 이점은 모던 웹에서 더욱 중요해지고 있다. 일례로 구글 크롬을 비롯한 주요 브라우저들은 2018년부터 HTTPS를 사용하지 않는 웹사이트에 '안전하지 않음' 경고를 표시하기 시작했다. 사용자들의 보안 의식이 높아지면서, HTTPS는 웹사이트의 신뢰성을 보여주는 필수적인 지표가 되었다.
특히 사용자의 위치 정보, 푸시 알림과 같은 현대적인 웹 기능들은 보안상의 이유로 HTTPS가 필수적이다. 이러한 민감한 데이터들이 악의적인 목적으로 사용되는 것을 방지하기 위해, 브라우저들은 HTTPS가 적용되지 않은 웹사이트에서 이러한 기능들의 사용을 제한하고 있다.
SEO 이점
HTTPS는 웹사이트의 보안을 강화할 뿐만 아니라 검색 엔진 최적화(SEO)에도 상당한 이점을 제공한다. 2014년 구글은 HTTPS를 공식적인 순위 결정 요소로 발표했다. 처음에는 전체 검색 쿼리의 1% 미만에만 영향을 미치는 경미한 신호였지만, 시간이 지나면서 그 중요성이 크게 증가했다.
HTTPS는 웹 분석의 정확성도 향상시킨다. HTTPS 웹사이트 간의 트래픽이 이동할 때는 참조$_{referral}$ 데이터가 보존되어 방문자의 유입 경로를 정확하게 파악할 수 있다. 반면 HTTP 사이트의 경우 이러한 데이터가 '직접 트래픽'으로 잘못 표시되어 방문자의 행동을 분석하고 최적화하는 것이 어려워진다.
또한 구글 서치 콘솔의 일부 기능은 HTTPS가 필수적이다. 구글은 서치 콘솔에서 HTTPS 리포트를 제공하여 보안 연결에 대한 통찰력을 제공한다. HTTPS를 사용하지 않는 사이트는 이러한 중요한 데이터와 인사이트를 활용할 수 없어 사이트 성능 개선에 제약이 생긴다.
이러한 SEO 이점들은 현대 디지털 환경에서 HTTPS가 선택이 아닌 필수가 되었음을 보여준다. 사용자의 보안과 개인정보 보호에 대한 관심이 높아지면서, 검색 엔진들은 안전한 웹사이트를 우선적으로 노출하고 있다.
성능 오버헤드
이전까지는 단점이었지만, 과거에 비해 HTTPS의 성능 오버헤드가 크게 개선되었다. 2010년대 초기에는 HTTPS가 성능 저하를 일으킨다는 우려가 있었지만 기술의 발전으로 이러한 문제들은 대부분 해결되었다. 특히 TLS 1.3의 도입으로 초기 연결 시 발생하는 지연 시간이 크게 줄었다. 이전 버전에서는 연결 수립을 위해 추가적인 왕복 통신이 필요했지만, TLS 1.3에서는 핸드셰이크 과정이 최적화되어 이러한 오버헤드가 감소했다.
CPU 부하 역시 더 이상 큰 문제가 되지 않는다. 실제로 구글은 Gmail을 HTTPS로 전환했을 때 CPU 부하는 1% 미만, 메모리는 연결당 10KB 미만, 네트워크 오버헤드는 2% 미만이었다고 발표했다. 요즘 나오는 하드웨어는 암호화 연산을 처리하는 데 특화된 기능이 내장되어 있어 스마트폰과 같은 저전력 기기에서도 HTTPS를 효율적으로 처리할 수 있다.
대역폭 사용량의 증가도 미미한 수준이다. HTTPS 프로토콜로 인한 오버헤드를 고려하더라도, 일반적인 MTU$_{Maximum \space Transmission \space Unit}$ 1500바이트 패킷 크기에서 실제 페이로드 데이터는 1400바이트 이상을 유지할 수 있어 대역폭 증가는 6-7% 정도에 불과하다.
비용 측면
HTTPS로 전환하면서 생기는 비용은 SSL/TLS 인증서 구매에서 발생한다. 인증서의 가격은 보호하는 도메인의 수와 인증 수준에 따라 다양하다.
가장 기본적인 단일 도메인 인증서는 연간 약 10달러 정도로, 하나의 도메인만 보호할 수 있다. 와일드카드 인증서는 연간 53달러부터 시작하며 하나의 도메인과 모든 서브도메인을 보호할 수 있다. 여러 도메인을 보호해야 한다면 멀티 도메인 인증서를 사용할 수 있는데 연간 43달러부터 시작한다.
인증 수준에 따라서도 가격이 달라진다. 도메인 소유권만 확인하는 도메인 검증$_{Domain \space Validation}$ 인증서는 가장 저렴하다. 조직의 실제 존재 여부를 확인하는 조직 검증$_{Organization \space Validation}$ 인증서는 연간 102달러부터 시작하고 가장 엄격한 확인 과정을 거치는 확장 검증$_{Extended \space Validation}$ 인증서는 연간 140달러부터 시작한다.
다만 많은 호스팅 제공업체들이 무료 SSL 인증서를 호스팅 패키지에 포함시키고 있어 추가 비용 없이도 HTTPS를 적용할 수 있는 방법이 늘어나고 있어 HTTPS 도입의 비용 장벽을 크게 낮추는 요인이 되고 있다.
🌐 모던 웹에서의 HTTPS
HTTPS 도입 현황
구글의 투명성 보고서에 따르면, 웹 트래픽의 HTTPS 암호화 비율은 꾸준히 증가하고 있다. 특히 데스크톱 사용자들의 경우 방문하는 페이지의 절반 이상이 HTTPS를 통해 로드되며, HTTPS 페이지에서 보내는 시간이 전체 브라우징 시간의 2/3를 차지한다.
도입 현황은 지역에 따라 차이를 보인다. 예를 들어 러시아는 HTTPS 도입률이 빠르게 증가한 반면, 일본은 상대적으로 증가 속도가 더딘 것으로 나타났다. 하지만 통계 대상으로 잡힌 모든 국가에서 HTTPS 브라우징 시간 비율이 90% 이상이다. 모바일 환경에서는 아직 데스크톱만큼 HTTPS가 보급되지 않았지만, 암호화 사용량은 지속적으로 증가하는 추세다.
다만 완전한 HTTPS 도입에는 여전히 몇 가지 장애물이 존재한다. 일부 국가나 조직에서는 HTTPS 트래픽을 차단하거나 성능을 저하시키는 정책을 펴고 있고 기술적 자원 부족이나 우선순위 문제로 HTTPS 구현을 미루는 경우도 있다. 또한 인증서 관리의 어려움도 특히 작은 조직이나 개인 웹사이트에서는 HTTPS 도입을 망설이게 만드는 요인이 되고 있다.
브라우저의 HTTPS 정책
브라우저들은 적극적으로 HTTPS 사용을 장려하는 정책을 펴고 있다. 2018년 7월 출시된 Chrome 68부터는 HTTP 사이트에 접속할 때 주소창에 "안전하지 않음"이라는 경고를 표시하기 시작했다.
브라우저들은 보안 강화를 위해 HTTPS가 필요한 웹 기능들도 정의하고 있다. 사용자의 위치 정보 접근, 푸시 알림 전송, 프로그레시브 웹 앱$_{PWA}$의 서비스 워커 실행과 같은 민감한 기능들은 반드시 HTTPS 환경에서만 동작하도록 제한하고 있다. 이는 이러한 기능들이 사용자의 프라이버시와 직접적으로 연관되어 있기 때문이다.
또한 브라우저들은 사이트 격리$_{Site \space Isolation}$ 정책을 통해 보안을 더욱 강화하고 있다. 이 정책은 서로 다른 출처의 웹사이트들을 별도의 프로세스에서 실행하고, HTTPS를 사용하지 않는 사이트와 사용하는 사이트 간의 상호작용을 제한해 악의적인 웹사이트가 다른 사이트의 데이터를 탈취하는 것을 더욱 어렵게 만든다.
Let's Encrypt 등 무료 인증서
HTTPS 도입의 비용 장벽을 낮추기 위해 무료 SSL/TLS 인증서를 제공하는 인증 기관들이 등장했다. 그중 가장 대표적인 것이 Let's Encrypt다. Let's Encrypt는 자동화된 인증서 발급 및 갱신 프로세스를 제공해 누구나 쉽게 웹사이트에 HTTPS를 적용할 수 있게 했다.
Let's Encrypt는 ACME$_{Automated \space Certificate \space Management \space Environment}$ 프로토콜을 사용해 인증서를 자동으로 발급하고 갱신한다. 도메인에 대한 통제권을 증명하면 무료로 인증서를 발급받을 수 있고 많은 호스팅 제공업체들이 Let's Encrypt를 기본 지원하고 있다. 서버에 대한 쉘 접근 권한이 있다면 Certbot과 같은 ACME 클라이언트를 통해 인증서 발급과 설치를 자동화할 수 있다.
무료 인증서의 등장은 웹의 HTTPS 도입을 크게 가속화했다. 과거에는 SSL/TLS 인증서 구매와 관리가 상당한 비용과 기술적 부담을 요구했지만 이제는 장벽이 크게 낮아졌다. 더 많은 웹사이트가 HTTPS를 도입하게 되는 계기가 되었고 전반적인 웹의 보안 수준을 향상시키는 데 기여하고 있다.
요약
- HTTP는 웹의 기본 프로토콜이지만 평문 통신, 중간자 공격, 데이터 변조 등의 보안 취약점을 가지고 있다.
- HTTPS는 TLS 암호화를 통해 통신을 보호하고, 인증서로 서버의 신원을 보장하며, 데이터 무결성을 검증한다.
- SSL/TLS 핸드셰이크는 비대칭키로 세션키를 안전하게 공유하고 이후 통신은 빠른 대칭키 암호화를 사용한다.
- HTTPS는 보안성과 SEO 이점을 제공한다. 한편 요즘 하드웨어에서는 성능 저하가 미미한 수준이다.
- Let's Encrypt의 등장으로 인증서 비용 부담이 크게 줄었고 주요 브라우저들의 HTTPS 의무화 정책으로 도입이 가속화되고 있다.
- 현대 웹에서 HTTPS는 선택이 아닌 필수가 되었고 더 안전한 인터넷을 만드는 기반이 되고 있다.
references
https://developer.mozilla.org/ko/docs/Web/HTTP
https://developer.mozilla.org/ko/docs/Web/HTTP/Status
https://developer.mozilla.org/ko/docs/Web/HTTP/Methods
https://www.cloudflare.com/ko-kr/learning/ssl/why-is-http-not-secure/
https://learn.snyk.io/lesson/man-in-the-middle-attack/
https://owasp.org/www-community/attacks/Web_Parameter_Tampering
https://developer.mozilla.org/ko/docs/Web/HTTP/Evolution_of_HTTP
https://developer.mozilla.org/ko/docs/Glossary/SSL
https://developer.mozilla.org/ko/docs/Glossary/TLS
https://www.cloudflare.com/ko-kr/learning/ssl/what-happens-in-a-tls-handshake/
https://www.cloudflare.com/ko-kr/learning/ssl/what-is-asymmetric-encryption/
https://w3techs.com/technologies/overview/ssl_certificate
https://www.cloudflare.com/ko-kr/learning/ssl/why-use-https/
https://serverfault.com/questions/570387/https-overhead-compared-to-http
https://letsencrypt.org/getting-started/
'CSE > 네트워크 (network)' 카테고리의 다른 글
| [Network] HTTP/0.9 (0) | 2025.02.22 |
|---|---|
| [Network] OSI Model과 7 Layer 별 장비 (0) | 2025.01.11 |
| TCP/IP 프로토콜 4판 - 연습문제 15장 (2) | 2024.01.12 |
| TCP/IP 프로토콜 4판 - 연습문제 14장 (1) | 2024.01.11 |
| TCP/IP 프로토콜 4판 - 연습문제 13장 (2) | 2024.01.10 |
컴퓨터 전공 관련, 프론트엔드 개발 지식들을 공유합니다. React, Javascript를 다룰 줄 알며 요즘에는 Typescript에도 관심이 생겨 공부하고 있습니다. 서로 소통하면서 프로젝트 하는 것을 즐기며 많은 대외활동으로 개발 능력과 소프트 스킬을 다듬어나가고 있습니다.
포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!
![[Network] HTTP/0.9](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2F7fH5a%2FbtsMt7dfp0P%2FRpvbmrzsSrGXmqjJBvkHKk%2Fimg.jpg)
![[Network] OSI Model과 7 Layer 별 장비](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FcnEMAv%2FbtsLJcn0jw1%2FZZZ3LXNzrEPCfFvvBCgN50%2Fimg.jpg)
