HTTPS는 HTTP 통신을 TLS로 보호하는 방식입니다. 요청과 응답이라는 HTTP의 역할은 유지하면서, 통신 경로에서 데이터를 읽거나 바꾸기 어렵게 만듭니다.
HTTP만 사용하면 생기는 문제
암호화되지 않은 HTTP에서는 전송 내용을 관찰할 수 있는 공격자가 요청과 응답을 읽거나 변조할 수 있습니다. 로그인 정보뿐 아니라 서버가 보내는 페이지나 다운로드 파일도 공격 대상이 됩니다.
TLS가 제공하는 세 가지 보호
| 보호 | 의미 |
|---|---|
| 기밀성 | 통신 내용을 암호화해 제삼자가 읽기 어렵게 함 |
| 무결성 | 전송 중 내용이 바뀌었는지 검출 |
| 인증 | 인증서 검증을 통해 접속 대상 서버의 신원을 확인 |
브라우저는 인증서가 요청한 호스트 이름에 맞는지, 유효 기간과 신뢰 체인에 문제가 없는지 확인합니다. 인증서 경고를 무시하면 서버 인증의 전제가 깨질 수 있습니다.
연결 과정의 큰 흐름
- 클라이언트와 서버가 지원하는 TLS 설정을 협의합니다.
- 서버 인증서 등을 검증하고 키 교환을 수행합니다.
- 합의한 키를 이용해 HTTP 데이터를 암호화하여 주고받습니다.
실제 핸드셰이크 메시지는 TLS 버전과 연결 재개 여부에 따라 달라집니다. 공개키 기술은 인증과 키 교환 등에 사용하며, 이후 데이터를 효율적으로 보호하는 데는 대칭키 암호가 사용됩니다.
HTTPS가 모든 보안을 해결하지는 않는다
HTTPS는 전송 구간을 보호합니다. 서버에 저장한 평문 비밀번호, 애플리케이션의 XSS·SQL 주입 취약점, 사용자가 속아서 접속한 피싱 사이트까지 해결하지는 않습니다.
또한 URL의 경로와 쿼리는 전송 구간에서는 암호화되지만, 브라우저 방문 기록이나 서버 로그에는 남을 수 있습니다. 비밀번호 같은 민감한 값을 URL에 넣지 않아야 합니다.
SSL은 역사적으로 사용된 이름이며, 실제 서비스에서는 안전한 TLS 구성을 사용해야 합니다. “HTTPS니까 사이트 자체를 믿어도 된다”보다 “이 호스트와의 통신이 보호된다”로 이해하는 것이 정확합니다.
참고