TIL. HTTPS

배상건·2022년 4월 21일
0

TIL

목록 보기
10/15

1. 대칭 키

과거에는 데이터를 보내는 쪽(서버)와 데이터를 받는 쪽(클라이언트)이
데이터를 암호화하고, 이를 다시 메시지로 복호화하는 같은 방식을 공유했다.

예를 들어 임의의 문자열이 있다고 하자. 이때, 임의의 문자열을 '키'라고 부른다.

키 : a084#l%^q3_97

대칭 키 적용 : 암호화

4에 3을 곱하면, 12가 되듯이,
서버에서 클라이언트로 보내고자하는 데이터인 '안녕하세요'를
a084#l%^q3_97(키)와 함께 특정 알고리즘에 넣고 돌리면,
그 결과로 전혀 알 수 없는 암호문 '뛟빭썋줹훃흉'이 만들어진다.

대칭 키 적용 : 복호화

12에서 4을 얻어내려면, '3'으로 나눠야 하는 것처럼
서버로부터 클라이언트가 전달받은 '뛟빭썋줹훃흉'라는 암호문을 암호문을 해독하려면, a084#l%^q3_97(키)를 넣고 특정 알고리즘을 거꾸로 돌리면,
해독된 '안녕하세요'를 얻을 수 있다.
이 과정을 복호화라고 한다.

위 내용을 정리하면, '키'값을 알지 못한다면, 절대 암호문을 해독할 수 없
다.

대칭 키의 한계

클라이언트와 서버가 동일한 대칭키를 가지고 있다면,
클라이언트가 로그인할 때,
클라이언트에 있는 대칭키로 ID, PW를 '암호화' 하여 서버로 전달하게 된다.
서버에서는 전달받은 암호화 된 로그인 정보를
서버가 가지고 있는 대칭키로 복호화해서 인식할 수 있게 된다.

이 과정에서 제 3자가 개입하더라도, 제 3자는 대칭키를 가지고 있지 않기 때문에, 주고받는 데이터를 열람할 수 없기 때문에, 안전할 것이다.

그런데, 문제는 어떻게 이 동일한 키(대칭키)를 애초에 양쪽(클라이언트-서버)가 공유하느냐에 있다.

클라이언트와 서버가 교류하기 위해서는,
통신 초기에 서버에서 클라이언트로 대칭키를 전송해야 하는데,
이때, 제 3자가 대칭키를 탈취할 수 있는 한계를 가지게 된다.

2. 비대칭 키

비대칭 키는 많은 클라이언트를 대상으로 매번 적용하기에는
매우 연산이 복잡하기 때문에, 효율적이지 못한다.

따라서, 통신 초기에 공개키를 전달하는 용도로 비대칭 키를 사용한다.

통신의 단계는 아래 3단계로 나뉜다.
(1) Hand Shake
(2) 비밀 키 생성
(3) 상호 키 검증

(1) Hand Shake는 클라이언트와 서버가 서로 신뢰할 수 있는지 확인 하기 위한, 탐색과정이다.

탐색과정 : 랜덤 데이터 + 인증서 공유

  1. 클라이언트는 랜덤 데이터 A를 생성하여 서버로 보낸다.
  2. 랜덤 데이터 A를 받은 서버는 응답으로
    (1) 랜덤 데이터 B와 (2) 해당 서버의 인증서를 클라이언트로 보낸다.
    <중요>
    서버가 클라이언트로 전달한 인증서에는 서버의 공개 키가 포함되어 있다.

(2) '비밀 키 생성'은 다음의 과정이 필요하다.

비밀 키 생성 : CA들의 정보로 인증서 확인

  1. 클라이언트는 서버로부터 전달받은 인증서(공개키)가 정품인지 확인이 필요하다.
  2. 이를 위해 브라우저에 내장된 CA들의 정보와 대조해 정품 유무를 조회한다.
  3. CA의 인증을 받은 인증서는 해당 CA의 개인키로 암호화되어 있다.
  4. 따라서, 인증서가 정품이라면, 브라우저에 저장된 CA의 공개키로 복호화할 수 있게 된다.
    만약, 브라우저에 저장된 CA의 공개키로 인증서를 복호화 할 수 없다면,
    이는 서버로부터 전달받은 인증서가 가짜로 판단되어 브라우저 창에 "Not secure" 표시가 뜨게 된다.
  5. <중요>CA의 공개키로 복호화 된 인증서에는 서버의 공개키가 포함되어 있다.
  6. 여기서 착각하기 쉬운 것은, 클라이언트가 서버로부터 공개키를 받았으니, 비대칭키 방식을 적용하여 데이터를 주고받으면 되겟다고 생각하기 쉽지만, 비대칭키 방식으로 데이터를 암호화 및 복호화 하는 것은 대칭키 방식보다 PC에 더 큰 부담을 주기 때문에, 효율적이지 않다.

(3-1) '상호 키 검증'은 클라이언트가 Hand Shake에서 주고받은 랜덤 데이터 A와 랜덤 데이터 B를 혼합해서 임시 키를 만들게 된다.

(3-2) 이 임시 키는 인증서에 포함된 서버의 공개키로 암호화되어 서버로 보내진다.
(3-3) 서버는 클라이언트로부터 전달받은 암호화 된 공개키를


사진 참조

profile
목표 지향을 위해 협업하는 개발자

0개의 댓글