[네트워크] HTTP와 HTTPS

HTTP란?

- WWW 상에서 정보를 주고 받을 수 있는 프로토콜로, 클라이언트와 서버 사이에 이루어지는 요청/응담 프로토콜
- 주로 HTML 문서를 주고 받는데 사용되며, TCP(HTTP/1, HTTP/2)와 UDP(HTTP/3)를 사용
- 클라이언트(웹브라우저)가 HTTP를 통해 서버에게 정보 요청 → 서버가 해당 정보를 전달 → 웹 브라우저를 통해 출력

구분	설명
HTTP/1.0	- 한 연결당 하나의 요청을 처리하도록 설계 - 서버로부터 파일을 가져올때마다 TCP의 3웨이 핸드셰이크를 계속 열어야해서 RTT 증가하는 단점    (RTT: 패킷이 목적지에 도달하고나서 다시 출발지로 돌아오기까지 걸리는 시간)
HTTP/1.1	- 매번 TCP에 연결하지 않고, 한 번 TCP를 초기화한 후 keep-alive 옵션 통해 여러 개의 파일을 송수신할 수 있게 함 - 문서 안에 다수의 리소스(이미지, css, script 파일)를 처리하려면 리소스 개수에 비해 대기 시간이 길어짐 - 헤더에 쿠키 등 많은 데이터가 있고 압축되지 않아 무거움
HTTP/2	- 지연 시간과 응답시간을 줄이고, 멀티플렉싱, 헤더 압축, 서버 푸시, 요청의 우선순위 처리 지원 - HTTPS 위에서 동작
HTTP/3	- QUIC라는 계층 위에서, TCP가 아닌 UDP기반으로 돌아감 - Zero RTT, 패킷 손실에 대한 빠른 대응, 사용자 IP가 바뀌어도 연결이 유지됨 - 동영상 서비스에서 Wifi에 연결하여 시청하다가 셀룰러 신호로 바뀌더라도 HTTP/3의 경우 끊기지 않고 영상 시청 가능

[ HTTP의 문제점 ] 

문제점	보완 방법
1. TCP/IP는 도청 가능 - 패킷 수집만으로 도청 가능	- 통신 자체를 암호화 프로토콜(SSL, TLS)와 조합함으로써 암호화(HTTPS) - HTTP 메시지에 포함되는 콘텐츠만 암호화하며, 전송 받은 측에서 그 암호를 해독하여 출력하는 처리 필요
2. 통신 상대를 확인하지 않기 때문에 위장 가능 - IP 주소나 포트 에서 웹 서버에 엑세스 제한이 없는 경우, 리퀘스트가 오면 상대가 누구든 리스폰스를 반환 - 어디에서, 누가, 접근이 허가된 상대인지 알 수 없으며, 의미 없는 리퀘스트도 수신하여 DoS 공격 방지 불가	- SSL을 통해 상대 확인 가능 - SSL은 상대를 확인하는 수단으로 증명서 제공하며 통신 상대가 내가 통신하고자 하는 서버임을 나타냄
3. 완전성을 증명할 수 없기 때문에 변조 가능 - 서버 또는 클라이언트에서 수신한 내용이 송신측에서 보낸 내용과 일치한다는 것을 보장할 수 없음 - 리퀘스트나 리스폰스가 발신된 후 상대가 수신하는 사이 누군가에 의해 변조가 되더라도 알 수 없음(Main-in-the-Middle)	- MD5, SHA-1 등의 해시값을 확인하거나 파일의 디지털 서명을 확인하는 방법 등이 존재 - 확실히 방지하기 위해서는 HTTPS를 통해 인증이나, 암호화, 다이제스트 기능을 사용하는 것이 좋음

HTTPS란?

- HTTP의 보안상 문제를 해결하기 위해 등장한 프로토콜로, 보안이 더 강화된 버전의 프로토콜
- HTTP에 SSL(Secure Socket Layer) 또는 TLS(Transport Layer Security)를 이용해 암호화하여 주고 받음
- 모든 HTTP 요청과 응답 데이터는 네트워크로 보내지기 전에 전송 계층과 응용 계층 사이에서 암호화
- 통신 패킷을 Sniffing(네트워크 상에서 다른사람의 패킷 등을 엿보는 보안 공격) 하더라도 정보 보호 가능
- 보안을 위해 사용하는 세션키를 생성 및 교환하는 과정 필요 (SSL Handshake)

📍SSL Handshake
- 공개키/비대칭키를 이용한 인증과정을 통해 서로 공유하는 대칭키를 생성
- CA(Certificate Authority)를 통해 서버의 공개키를 확인하게 되고 증명된 사이트의 경우 공개키 서명방식을 이용해 서로 인증

📍 공개키 암호화 방식 진행 과정
- A가 웹 상에 공개된 'B의 공개키'를 이용해 평문을 암호화하여 B에게 보냄
- B는 자신의 비밀키로 복호화한 평문을 확인, A의 공개키로 응답을 암호화하여 A에게 보냄
- A는 자신의 비밀키로 암호화된 응답문을 복호화
➡️ Confidentiality만 보장될 뿐, Integrity나 Authenticity는 보장해주지 못함

📍 대칭키와 공개키를 함께 사용하는 하이브리드 방식 (SSL 탄생의 시초)
- A가 B의 공개키로 암호화 통신에 사용할 대칭키를 암호화하고 B에게 보냄
- B는 암호문을 받고, 자신의 비밀키로 복호화함
- B는 A로부터 얻은 대칭키로 A에게 보낼 평문을 암호화하여 A에게 보냄
- A는 자신의 대칭키로 암호문을 복호화함
- 앞으로 이 대칭키로 암호화 통신을 함
➡️ 대칭키를 주고 받을 때만 공개키 암호화 방식 사용, 이후에는 계속 대칭키 암호화 방식으로 통신! 

[ HTTPS 통신 흐름 ]

1. 인터넷 사이트(서버)는 공개키, 개인키를 만들고 인증기관(CA)에 자신의 정보와 공개키 관리 계약을 맺음
2. 계약을 완료한 인증기관은 기관만의 공개키, 개인키를 가지고 있으며 사이트가 제출한 데이터를 검증하고,
    인증기관의 개인키로 사이트에서 제출한 정보를 암호화하여 인증서를 만들어 서버에 제공
3. 인증 기관은 웹 브라우저(클라이언트)에게 자신의 공개키 제공
4. 사용자가 사이트에 접속하면 서버는 자신의 인증서를 웹 브라우저(클라이언트)에게 제공
5. 웹 브라우저는 3에서 미리 알고 있던 인증기관의 공개키로 인증서를 해독하여 검증
    사이트 정보와 서버의 공개키를 알 수 있게 됨(서보로부터 온 응답임을 확인할 수 있음, 보안상 의미는 없음)
6. 얻은 서버의 공개키로 대칭키를 암호화하여 다시 사이트에 보냄
7. 사이트는 개인키로 암호문을 해독하여 대칭키를 얻게 되고, 이 후부터는 전달 받은 대칭키로 데이터를 주고 받음
8. 세션이 종료되면 대칭키는 폐기됨

[ HTTPS의 단점 ]

- 인터넷 연결이 끊긴 경우 재인증 시간이 소요 (HTTP는 비연결형으로 웹페이지를 보는 중 인터넷이 끊겨도 페이지를 볼 수 있음)
   HTTPS는 소켓(데이터를 주고 받는 경로) 자체에서 인증을 하기 때문에 인터넷 연결이 끊기면 소켓도 끊어져 재인증이 필요
- 신뢰받는 CA가 아닌 기업 자체 인증서를 발급한 경우 등이라면 안전하지 않을 수 있음(브라우저에서 "안전하지 않은 사이트"와 같은 알림으로 주의를 줌)

출처

https://eun-jeong.tistory.com/27

https://github.com/jobhope/TechnicalNote/blob/master/network/HTTPAndHTTPS.md