도서 HTTP 완벽 가이드를 읽고 알게 된 지식을 정리한 글입니다.
비밀키 암호화 공개키 암호
암호 알고리즘은 누구에게나 열려 있지만, 키는 닫혀 있다.
비밀 키 암호
- 대칭 키 암호라고도 불린다.
- 발송자와 수신자 모두 동일한 키를 갖는다.
- 인코딩할 때 키 == 디코딩할 때 키
공개키 암호
- 두 개의 비대칭 키를 사용한다.
- 인코딩 키는 모두에게 공개되어 있다.
- 메시지를 디코딩하는 능력은 소유자에게만 보유한다.
- RSA는 유명한 공개 키 암호 방식이다.
그래서...?
공개 키 암호 방식은 더 안전하지만 알고리즘 계산이 느리기 때문에, 실제로는 두 가지 방식을 섞은 것을 쓴다. 예를 들어, 노드들 간의 안전한 의사소통 채널을 수립할 때는 공개 키 암호화 방식를 사용하고, 이후에 전송 데이터를 암호화할 때는 대칭 키 암호화 방식을 사용한다.
디지털 서명
- 누가 메시지를 썼는지 알려주고 그 메시지가 위조되지 않았음을 증명하기 위해 사용한다.
- 저자는 저자만 알 수 있는 개인 키를 가지고 체크섬을 계산한다. 즉, 체크섬은 저자의 개인 서명처럼 동작한다.
- 메시지 위조를 방지한다. 만약 악의적인 공격자가 송신 중인 메시지를 수정했다면, 그 메시지는 체크섬과 다르게 된다.
- 수신자 측에서는 체크섬을 통해 메시지가 유효한지 검사할 수 있다. 수신자는 저자의 개인 키로 변형된 서명에 공개키를 이용한 역함수를 적용하여 풀어낸 결과가 수신한 메시지를 요약한 결과와 일치하는지 확인하는 방식으로 메시지의 유효성을 검사한다.
서버 인증을 위한 디지털 인증서
- 보안 커넥션을 위해, 디지털 인증서를 사용한다.
- 서버의 디지털 인증서는 웹 사이트의 이름과 호스트 명, 웹 사이트의 공개키, 서명 기관의 이름, 서명 기관의 서명 필드를 가진다.
- 브라우저에서 디지털 인증서의 무결성을 검사한다.
- 서명 기관을 검사한다. 만약 브라우저가 모르는 서명 기관이라면, 사용자에게 해당 서명 기관에 대한 신뢰 여부를 물어본다.
- 디지털 서명을 서명 기관의 공개키로 요약한 결과와 서버의 디지털 인증서의 정보를 요약한 결과가 같은지 확인한다.
HTTPS에 대해
- HTTP의 가장 유명한 보안 버전으로, 주류 상용 브라우저와 서버에 구현되어 있다.
- HTTP 프로토콜에 대칭, 비대칭 인증서 기반 암호 기법을 결합한 것이다.
- 보안 계층을 통해 전송되는 HTTP이다.이를 위해 HTTP 메시지를 TCP로 보내기 전에 먼저 그것들을 암호화하는 보안 계층(애플리케이션 계층과 전송 게층 사이에 존재한다.)으로 보낸다.
- SSL은 TLS로 발전하였다. 최근에는 SSL과 TLS 모두를 의미하는 단어로 SSL을 사용한다.
- 만약 URL이 https 스킴을 갖고 있다면, 클라이언트는 서버에 443번 포트로 연결하고, 서버와 바이너리 포맷으로 된 몇몇 SSL 보안 매개변수를 교환하면서 '핸드셰이크'를 하고, 암호화된 HTTP 명령을 주고받는다.
보안 전송 과정
- 서버의 443 포트로 커넥션 수립
- SSL 보안 매개변수 핸드셰이크
- 클라이언트에서 SSL에 HTTP 요청을 보내고, SSL은 TCP를 통해 암호화된 요청을 보낸다.
- 서버에서 SSL에 HTTP 응답을 보내고, SSL은 TCP를 통해 암호화된 응답을 보낸다.
- 서버가 클라이언트에 SSL이 닫힌 것을 통지한다.
- TCP 커넥션이 닫힌다.
SSL 핸드셰이크
- 클라이언트가 암호 후보들을 보내고 인증서를 요구한다.
- 서버는 선택된 암호와 인증서를 보낸다.
- 클라이언트가 비밀정보를 보낸다. 클라이언트와 서버는 키를 만든다.
- 클라이언트와 서버는 서로에게 암호화를 시작한다고 말해준다.
서버 인증서
보안 HTTPS 트랜잭션은 항상 서버 인증서를 요구한다. 서버 인증서는 조직의 이름, 주소, 서버 DNS 도메인 이름 등을 보여주는 인증서이다. 사용자와 사용자의 클라이언트 소프트웨어는 모든 것이 믿을 만한 것인지 확인하기 위해 인증서를 검증할 수 있다.
사이트 인증서 검사
SSL 자체는 사용자에게 웹 서버 인증서를 검증할 것을 요구하지 않는다. 하지만 최신 웹브라우저 대부분은 인증서에 대해 간단한 검사를 하고 그 결과를 사용자에게 알려준다. 검사 단계는 다음과 같다.
- 날짜 검사: 인증서의 시작 및 종료일 검사
- 서명자 신뢰도 검사: 신뢰할 만한 서명 기관이 서명한 인증서인가?
- 서명 검사: 서명기관의 공개키를 서명에 적용하여 체크섬과 비교함으로써 인증서의 무결성을 검사한다.
- 사이트 신원 검사: 호스트 명이 인증서의 신원과 일치하는지 확인
가상 호스팅을 할 경우
만약 사용자가 인증서의 이름과 정확히 맞지 않는 가상 호스트 명에 도착한다면 경고한다. 이러한 문제를 피하기 위해 어떤 사이트는 보안 트랜잭션을 시작하는 모든 사용자를 인증서의 이름에 맞는 사이트로 리다이렉트한다.
프락시를 통한 보안 트래픽 터널링
클라이언트가 웹 프락시 서버를 이용한다면, 클라이언트는 서버의 공개키로 암호화된 HTTP 헤더를 읽을 수 없을 것이다.
HTTPS가 프락시와도 잘 동작할 수 있게 하는 방법 중 한 가지는 HTTP SSL 터널링 프로토콜이다. 이 방식은 다음과 같이 동작한다.
- 클라이언트가 프락시에게 자신이 연결하고자 하는 안전한 호스트와 포트를 평문으로 말해준다.
- 클라이언트와 서버 사이에서 데이터가 직접적으로 오갈 수 있게 해주는 터널을 만든다.
'CS > Network' 카테고리의 다른 글
| HTTP: 리다이렉션과 부하 균형 (0) | 2023.04.10 |
|---|---|
| HTTP: 엔터티와 인코딩 (1) | 2023.03.27 |
| HTTP: 기본 인증 (0) | 2023.03.20 |
| HTTP: 클라이언트 식별과 쿠키 (0) | 2023.03.20 |
| HTTP: 캐시 (0) | 2023.03.13 |