HTTP 프로토콜
HTTP(Hyper Text Transfer Protocol)은 서버와 클라이언트간에 데이터를 주고 받을 때 쓰는 통신 규약을 말한다.
HTTP는 상태 정보를 저장하지 않는 Stateless의 특징과 클라이언트의 요청에 맞는 응답을 보낸 후 연결을 끊는 Connectionless의 특징을 가지고 있습니다.
- 장점
- 통신간의 연결 상태 처리나 상태 정보를 관리할 필요가 없어 서버 디자인이 간단하다.
- 각각의 HTTP 요청에 독립적으로 응답만 보내주면 된다.
- 단점
- 이전 통신의 정보를 모르기 때문에 매번 인증을 해줘야 한다.
- 이를 해결하기 위해 쿠키(cookie)나 세션(session)을 사용해서 데이터를 처리한다.
HTTP 통신은 클라이언트와 서버간의 통신에 있어서 별다른 보안 조치가 없기때문에 만약 누군가 네트워크 신호를 가로챈다면 HTTP의 내용은 그대로 외부에 노출될 수 있다.
- 평문 통신이기 때문에 도청이 가능하다.
- 통신 상대를 확인하지 않기 때문에 위장이 가능하다.
- 완전성을 증명할 수 없기 때문에 변조가 가능하다.
따라서 이를 해결하기 위해 보안 계층을 추가한 프로토콜이 HTTPS이다.
HTTPS의 동작과정을 이해하기 위한 준비 과정 - 암호화 방식
1) 대칭키 암호화 방식
암호화, 복호화에 같은 암호 키를 쓰는 알고리즘이다.
비밀 키 전달을 위한 키 교환이 먼저 필요하며, 암호화 및 복호화의 속도가 빠르다.
2) 공개키 암호화 방식 ( = 비대칭키 암호화 방식)
사전에 비밀 키를 나눠가지지 않은 사용자들이 안전하게 통신하는 방법이다.
공개키와 개인 키가 존재하며, 공개키는 누구나 알 수 있지만 그에 대응하는 개인 키는 키의 소유자만이 알 수 있어야 한다.
공개키로 암호화 된 메시지는 반드시 개인 키로 복호화 해야 한다.
HTTPS의 동작과정을 이해하기 위한 준비 과정 - CA(Certificate Authority)
인증서의 역할은 클라이언트가 접속한 서버가 의도한 서버가 맞는지 보장하는 것이다. 이러한 역할을 하는 기업을 CA(Certificate authority) 혹은 Root Certificate라고 부른다.
CA는 신뢰성이 엄격하게 공인된 기업들만 참여할 수 있고, 개발자 입장에서 HTTPS를 적용하려면 신뢰할 수 있는 CA 기업의 인증서를 구입해야 한다.
이 인증서를 구입하게 되면 CA 기업의 개인 키를 이용하여 암호화 한 인증서를 받는다.
HTTPS의 동작과정
- 어플리케이션 서버(A)를 만드는 기업은 HTTPS를 적용하기 위해 공개키와 개인키를 만든다.
- 신뢰할 수 있는 CA 기업을 선택하고 그 기업에 내 공개키를 관리해달라고 계약하고 돈을 지불한다.
- 계약을 완료한 CA 기업은 CA 기업만의 공개키와 개인키가 있다.
CA 기업은 기업의 이름과 A서버의 공개키, 공개키의 암호화 방법 등의 정보를 담은 인증서를 만들고, 해당 인증서를 CA 기업의 개인키로 암호화해서 A서버에 제공한다. - A서버는 암호화된 인증서를 가지게 되고 A서버에 요청이 오면 클라이언트에게 인증서를 준다.
- 클라이언트 입장에선 A서버의 정보를 CA 기업의 개인키로 암호화한 인증서를 받게 된다.
- CA 기업의 공개키는 브라우저는 알고 있다.
- 브라우저는 CA 기업 리스트를 쭉 탐색해서 공개키로 인증서를 해독하여 A서버의 공개키를 얻는다.
- A서버의 공개키로 암호화해서 요청을 날리게 된다.
(4~5번은 handshake 하는 과정이다. https 전송전에 요청을 통해서 받게 된다.)
SSL HandShake
SSL은 암호화된 데이터를 전송하기 위해서 공개키와 대칭키를 혼합해서 사용한다.
클라이언트와 서버가 주고 받는 실제 정보는 대칭키 방식으로 암호화하고, 대칭키 방식으로 암호화된 실제 정보를 복호화할 때 사용할 대칭키는 공개키 방식으로 암호화한다.
- 클라이언트가 서버에 접속한다(Client Hello)
이 때 클라이언트 측에서 생성한 랜덤 데이터, 암호화 방식들, 세션 아이디 등을 서버 측에 전송한다 - 서버는 Client Hello에 대한 응답으로 Server Hello를 하게 된다.
서버 측에서 생성한 랜덤 데이터, 암호화 방식, 인증서를 클라이언트에게 전송한다. - 인증서 확인
인증서가 CA에 의해서 발급된 것인지를 확인하기 위해서 클라이언트에 내장된 CA의 공개키를 이용해서 인증서를 복호화한다. 복호화에 성공했다면 인증서는 CA의 개인키로 암호화된 문서임이 암시적으로 보증된 것이다.
클라이언트는 상기 2번을 통해서 받은 서버의 랜덤 데이터와 클라이언트가 생성한 랜덤 데이터를 조합해서 pre master secret라는 키를 생성한다. - pre master secret를 서버로 전송
서버로부터 받은 인증서 안에 있는 서버의 공개키를 이용해서 pre master secret 값을 암호화한 후에 서버로 전송한다. - 서버는 클라이언트가 전송한 pre master secret 값을 자신의 비공개키로 복호화한다.
이로서 서버와 클라이언트가 모두 pre master secret 값을 공유하게 되었다.
이후 통신은 공유된 비밀키로 암호화되어 통신한다. - 클라이언트와 서버는 핸드쉐이크 단계의 종료를 서로에게 알린다.
공개키와 개인키를 혼합해서 쓰는 이유
공개키 방식은 컴퓨팅 리소스가 많이 들고, 대칭키 방식에 비해서 속도가 매우 느려서, 전자 서명이나 간단한 메시지 암호화 등에는 사용할 수 있지만 실시간 암호화 통신에서는 사용하기 어렵다.
그래서 데이터는 대칭키로 암호화 할 것이지만, 최초에 서로 대칭키를 통시하는 과정은 비대칭키로 암호화 하여 보안을 확보한다는 의미다.
'Computer Science > 네트워크' 카테고리의 다른 글
| 웹 통신의 흐름 (0) | 2023.03.13 |
|---|---|
| TCP와 UDP (1) | 2023.03.12 |
| 네트워크 계층 구조 (0) | 2023.03.12 |
| REST의 정의와 HTTP 메소드 (0) | 2023.03.10 |
| CORS 에러 해결하기 (0) | 2023.03.09 |
