인터넷을 접속해본 사람이라면 HTTP와 HTTPS는 당연히 접해본 적이 있을 겁니다.
지금 이 웹사이트의 주소 또한 https로 시작하는 것을 볼 수 있는데요 ㅎ ㅎ
그렇다면, 이것들이 무슨 뜻을 가지고 있는지 차이점은 무엇인지 알아봅시다 !
HTTP란 ?
HTTP란 Hyper Text Transfer Protocol의 약자로 인터넷에서 하이퍼텍스트를 교환하기 위한 통신 규약입니다.
이게 무슨 뜻인데 ..?
즉, HTTP는 서버와 클라이언트 모델을 따라 데이터를 주고 받기 위한 프로토콜으로 80번 포트를 사용하고 있습니다.
HTTP 서버가 80번 포트에서 요청을 기다리고 있으며 클라이언트는 80번 포트로 요청을 보내게 됩니다.
가장 기초적인 프로토콜으로 인터넷의 초기에 모든 웹사이트에서 기본적으로 사용되었던 프로토콜입니다.
HTTP 구조
HTTP는 어플리케이션 레벨의 프로토콜로 TCP / IP 위에서 작동합니다.
HTTP는 상태를 가지고 있지 않는 Stateless 프로토콜이며 Method, Path, Version, Headers, Body 등으로 구성됩니다.
하지만 HTTP는 암호화가 되지 않은 평문 데이터를 전송하는 프로토콜이였기 때문에 HTTP로 비밀번호나 주민등록번호 등을 주고 받으면 제 3자가 정보를 조회할 수 있습니다.
HTTP 문제점
1. HTTP는 평문 통신이기 때문에 도청이 가능합니다.
TCP / IP 구조의 통신은 전부 경로 상에서 엿볼 수 있기 때문에 패킷을 수집하는 것만으로 도청할 수 있습니다.
이를 보완하기 위해서 SSL이나 TLS라는 다른 프로토콜을 조합함으로써 HTTP의 내용을 암호화할 수 있습니다.
이렇게 SSL을 조합한 HTTP를 HTTPS라고 부릅니다.
2. 통신 상대를 확인하지 않기 때문에 위장이 가능합니다.
HTTP에 의한 통신에는 상대가 누구인지 확인하는 처리가 없기 때문에 누구든지 리퀘스트를 보낼 수 있습니다.
IP 주소나 포트 등에서 그 웹 서버에 접근 제한이 없는 경우 리퀘스트가 오면 상대가 누구든지 리스폰스를 반환합니다.
이러한 문제를 보완하기 위한 방법으로 SSL을 사용합니다.
SSL은 상대를 확인하는 수단으로 증명서를 제공합니다.
이 증명서를 이용함으로써 통신 상대가 내가 통신하고자 하는 서버임을 나타내고 이용자는 개인 정보 누설 등의 위험성이 줄어들게 됩니다.
또한, 클라이언트는 이 증명서로 본인 확인을 하고 웹 사이트 인증에서도 할 수 있습니다.
3. 완전성을 증명할 수 없기 때문에 변장이 가능합니다.
서버 또는 클라이언트에서 수신한 내용이 송신측에서 보낸 내용과 일치한다는 것을 보장할 수 없다는 뜻입니다.
리퀘스트나 리스폰스가 발신된 후에 상대가 수신하는 사이 누군가에 의해 변조되더라도 이 사실을 알 수 없습니다.
이와 같이 공격자가 도중에 리퀘스트나 리스폰스를 빼앗아 변조하는 공격을 중간자 공격이라고 합니다.
이를 보완하기 위해서는 역시 HTTPS를 사용해야 합니다.
SSL에는 인증이나 암호화 기능을 제공하고 있기 때문입니다.
이러한 문제들을 해결하기 위해 HTTPS가 등장하게 되었습니다.
HTTPS 란 ?
HTTPS란 HyperText Transfer Protocol Secure의 약자로 HTTP에 데이터 암호화가 추가된 프로토콜입니다.
즉, HTTPS는 새로운 어플리케이션 계층의 프로토콜이 아닌 HTTP 통신하는 소켓 부분을 SSL이나 TLS라는 프로토콜로 대체한 것입니다.
HTTP는 원래 TCP와 직접 통신했지만, HTTPS에서 HTTP는 SSL과 통신하고 SSL이 TCP와 통신하게 됩니다.
HTTPS는 HTTP와 다르게 443번 포트를 사용하며 네트워크 상에서 중간에 제 3자가 정보를 볼 수 없도록 암호화를 지원하고 있습니다.
SSL 이란 ?
SSL 이란 디지털 인증서로 불리며 브라우저(사용자의 컴퓨터)와 서버(웹사이트) 사이의 암호화된 연결을 수립하는 데 사용됩니다.
여기서 TLS가 등장하게 되는데, TLS는 SSL의 향상된 더욱 안전한 버전입니다.
현재 대부분의 최신 웹 브라우저는 SSL을 지원하지 않고 TLS를 지원합니다.
대칭키 암호화 vs. 비대칭키 암호화
HTTPS는 대칭키 암호화 방식과 비대칭키 암호화 방식을 모두 사용하고 있습니다.
1. 대칭키 암호화
- 클라이언트와 서버가 동일한 키를 사용해 암호화 및 복호화를 진행
- 키가 노출되면 매우 위험하지만 연산 속도 빠름
2. 비대칭키 암호화
- 한 개의 쌍으로 구성된 공개키와 개인키를 사용해 암호화 및 복호화를 진행
- 키가 노출되어도 비교적 안전하지만 연산 속도 느림
비대칭키 암호화에 대해 더 알아봅시다 . . !
- 공개키 : 모두에게 공개 가능한 키
- 개인키 : 나만 가지고 알고 있어야 하는 키
암호화를 공개키로 하느냐와 개인키로 하느냐에 따라 얻는 효과가 다릅니다.
- 공개키 암호화 : 개인키로만 복호화 가능 → 개인키는 나만 가지고 있으니까 나만 볼 수 있다 !
- 개인키 암호화 : 공개키로만 복호화 가능 → 공개키는 모두가 가지고 있으니까 내가 인증한 정보임을 알려 신뢰성 보장 가능 !
- 모두 복호화가 가능하다는 위험이 있음에도 공개키 제공자의 신원 확인이 보장된다는 점
그렇다면 모든 웹 페이지에서 HTTPS를 사용해도 될까 ?
암호화 통신은 평문 통신에 비해 CPU나 메모리 등의 리소스를 더 많이 요구합니다.
통신할 때마다 암호화를 하면 추가적인 리소스를 소비하기 때문에 서버 한 대당 처리할 수 있는 리퀘스트 수가 상대적으로 줄어들게 됩니다.
하지만 최근에 하드웨어 발달로 인해 HTTPS가 HTTP보다 더 빠르게 동작합니다.
따라서 웹은 과거의 민감한 정보를 다룰 때만 HTTPS에 의한 암호화 통신을 사용하는 방식에서 현재 모든 웹 페이지에서 HTTPS를 적용하는 방식으로 바뀌어가고 있습니다.
참고
https://mangkyu.tistory.com/m/98
'CS > 네트워크' 카테고리의 다른 글
| [네트워크] TCP 3-way handshake / 4-way handshake (0) | 2022.09.13 |
|---|---|
| [네트워크] TCP vs. UDP (0) | 2022.09.08 |
