1일 1질문으로 개발자가 되어보자. (One Day One Question)
분야: 네트워크
주제: HTTP vs HTTPS
HTTP vs HTTPS
잘 알고 있는지
- 조금
내가 아는 만큼 설명
- HTTP는 하이퍼텍스트 트랜스퍼 프로토콜이다.
- 클라이언트와 서버가 요청과 응답 형식으로 데이터를 주고받는 방식이다.
- HTTPS는 HTTP에 보안이 추가된 것이다.
- HTTPS를 써야 쿠키 전달이 되고 그런 게 있었던 기억이 난다.
답을 본 뒤 알게 된 것
- HTTP는 평문 통신이고, HTTPS는 HTTP에 TLS 암호화 계층을 추가한 것이다.
- 즉, HTTPS = HTTP + TLS 라고 볼 수 있다.
- HTTP는 웹에서 클라이언트와 서버가 요청(Request)과 응답(Response) 형식으로 데이터를 주고받는 애플리케이션 계층 프로토콜이다.
- HTTP는 stateless 프로토콜이다.
- stateless는 서버가 클라이언트의 이전 상태를 기본적으로 기억하지 않는다는 뜻이다.
- 그래서 로그인 상태 같은 것을 유지하기 위해 쿠키와 세션을 사용한다.
- HTTP는 데이터를 평문으로 전송하기 때문에 중간에서 가로채면 내용이 그대로 노출될 수 있다.
- 이처럼 중간에서 데이터를 훔쳐보는 것을 스니핑이라고 한다.
- 또한 중간자 공격(MITM)을 통해 데이터가 위조되거나 변조될 위험도 있다.
- HTTPS는 HTTP over TLS라고도 한다.
- HTTP 메시지를 TLS로 암호화해서 주고받는 방식이다.
- 예전에는 SSL이라고 불렀지만, 지금은 TLS가 표준이다.
- 관습적으로 SSL/TLS라고 부르기도 한다.
- TLS는 기밀성, 무결성, 인증을 보장한다.
- 기밀성은 데이터를 가로채도 내용을 읽을 수 없게 하는 것이다.
- 무결성은 데이터가 중간에 변조되었는지 감지할 수 있게 하는 것이다.
- 인증은 접속한 서버가 진짜 그 서버가 맞는지 인증서로 검증하는 것이다.
- HTTPS는 단순히 대칭키 하나만 사용하는 것이 아니다.
- 비대칭키와 대칭키를 함께 사용하는 하이브리드 방식이다.
- 비대칭키는 공개키와 개인키를 사용한다.
- 비대칭키는 안전하지만 느리고, 대칭키는 빠르지만 키 전달이 위험하다.
- 그래서 처음에는 비대칭키 방식으로 대칭키를 안전하게 교환한다.
- 이후 실제 데이터 통신은 빠른 대칭키로 암호화한다.
- TLS 핸드셰이크는 암호화 통신을 시작하기 전에 필요한 준비 과정이다.
- 클라이언트가 서버에 접속하면 서버는 공개키가 포함된 인증서를 보낸다.
- 브라우저는 이 인증서를 CA의 서명으로 검증한다.
- 이때 도메인, 유효기간, 발급자 등을 확인한다.
- 인증서 검증이 끝나면 공개키를 이용해 세션키, 즉 대칭키를 안전하게 합의하거나 교환한다.
- 이후 실제 HTTP 데이터는 이 세션키로 대칭키 암호화되어 주고받는다.
- 기본 포트는 HTTP가 80번, HTTPS가 443번이다.
- Secure 속성이 붙은 쿠키는 HTTPS 연결에서만 전송된다.
- 내가 기억한 “HTTPS를 써야 쿠키 전달이 된다”는 내용은 이 Secure 쿠키와 관련된 것이었다.
- SEO와 브라우저 정책상 HTTPS는 사실상 필수에 가깝다.
- HTTP 사이트는 브라우저에서 “안전하지 않음” 경고가 표시될 수 있다.
틀렸거나 부족했던 부분
- HTTP가 stateless 프로토콜이라는 점을 정확히 설명하지 못했다.
- HTTP가 평문 통신이라 스니핑에 취약하다는 점을 몰랐다.
- HTTPS가 단순히 “보안이 있는 HTTP” 정도가 아니라, HTTP에 TLS 암호화 계층을 씌운 것이라는 점을 몰랐다.
- TLS가 기밀성, 무결성, 인증을 보장한다는 점을 몰랐다.
- HTTPS의 암호화 방식이 대칭키와 비대칭키를 함께 쓰는 하이브리드 방식이라는 점을 몰랐다.
- 비대칭키로 대칭키를 교환하고, 실제 통신은 대칭키로 한다는 흐름을 몰랐다.
- TLS 핸드셰이크 과정은 거의 몰랐다.
- Secure 쿠키가 HTTPS 환경에서만 전송된다는 점을 어렴풋이만 알고 있었다.
면접용 1분 답변
- HTTP는 HyperText Transfer Protocol의 약자로, 클라이언트와 서버가 요청과 응답 형식으로 데이터를 주고받는 애플리케이션 계층 프로토콜입니다.
- HTTPS는 여기에 TLS 암호화 계층이 추가된 방식입니다.
- 즉, HTTPS는 HTTP over TLS라고 볼 수 있습니다.
HTTP는 기본적으로 stateless한 특성을 가지고 있기 때문에 서버가 클라이언트의 이전 상태를 기억하지 않습니다.
- 그래서 로그인 상태 유지 같은 기능을 위해 쿠키나 세션을 사용합니다.
- 또한 HTTP는 데이터를 평문으로 전송하기 때문에 중간에서 데이터를 가로채면 내용이 그대로 노출될 수 있고, 중간자 공격을 통한 위변조에도 취약합니다.
- HTTPS는 이런 문제를 해결하기 위해 TLS를 사용합니다.
- TLS는 크게 기밀성, 무결성, 인증을 보장합니다.
- 기밀성은 데이터를 가로채도 내용을 읽을 수 없게 하는 것이고, 무결성은 데이터가 중간에 변조되었는지 확인할 수 있게 하는 것입니다.
- 인증은 접속한 서버가 진짜 서버가 맞는지 인증서를 통해 검증하는 것입니다.
- HTTPS의 암호화 방식은 대칭키와 비대칭키를 함께 사용하는 하이브리드 방식입니다.
- 비대칭키는 안전하지만 느리고, 대칭키는 빠르지만 키 전달이 어렵기 때문에, 처음에는 비대칭키 방식으로 대칭키를 안전하게 교환하고 이후 실제 데이터 통신은 대칭키로 암호화합니다.
- TLS 핸드셰이크 과정에서는 클라이언트가 서버에 접속하면 서버가 공개키가 포함된 인증서를 보내고, 브라우저가 이 인증서를 CA의 서명으로 검증합니다.
- 그 후 세션키를 안전하게 합의하고, 이후 실제 HTTP 데이터는 이 세션키로 암호화되어 주고받습니다.
- 기본 포트는 HTTP가 80번, HTTPS가 443번입니다.
- 또한 Secure 속성이 붙은 쿠키는 HTTPS 환경에서만 전송됩니다.
한 줄 요약
- HTTP는 평문 기반 요청/응답 프로토콜이고, HTTPS는 HTTP에 TLS를 더해 기밀성, 무결성, 인증을 보장하는 보안 통신 방식이다.
'공부 > 1D1Q' 카테고리의 다른 글
| [1D1Q | Network] HTTP(Hypertext Transfer Protocol) (0) | 2026.07.10 |
|---|---|
| [1D1Q | Frontend] CRP(Critical Rendering Path) (0) | 2026.07.09 |
| [1D1Q | Network] 주소창에 URL을 입력하면 일어나는 과정 (0) | 2026.07.09 |
