61.01_[인증/보안] 기초_HTTPS_22.11.17

>인증

: 암호화를 이용하여 사람의 디지털 정체성을 확인하는 과정

>보안

: 여러 위협으로부터 정보를 보호하는 것

: 소 잃기전에 미리 최대한 튼튼한 외양간을 만드는 것이 목적

 

>HTTPS

: HTTP + Secure

: HTTP 프로토콜 내용을 암호화

>HTTPS 특징

1. 기밀성 : 메세지를 암호화함 ( 읽을 수 없음 )

2. 무결성 : 메세지를 조작(수정) 할 수 없음

>인증서

: 데이터 제공자의 신원을 보장하는 문서

: CA라고 표현하는 기관들에서 인증서를 발급함.

: OS 또는 브라우저에는 CA의 리스트들이 내장되어 있고, 이를 근거로 서버에서 제공받는 인증서가 인증된 CA에서 발급

된 문서인지 검증함.

>CA

: 인증서를 발급해주는 기관

: 각 브라우저마다 신뢰하는 CA의 인증서를 가지고 있다.

: CA는 자격을 박탈당할 수도 있다.

>TLS

: 서버와 클라이언트 간에서 이루어지는 CA를 통한 서버 인증 과정과 데이터 암호화 과정을 아우르는 프로토콜이 TLS

: SSL과 같은 말이기도하지만, SSL이 표준화된 명칭이 TLS이다.

 

>암호화

-대칭키 암호화

: 키 한 개로 암호화 및 복호화를 함

: 하나의 자물쇠를 하나의 키로 열고 닫는 개념

: 키를 복사하여 상대에게 제공

: 다루기는 쉽지만 보안에 취약한 면모를 보인다. (키를 가로채면 암호화, 복호화 모두 가능)

-비대칭키 암호화

: 키 두 개로 각각 암호화와 복호화를 함. 각각의 역할을 암호키, 복호키라고 부름.

: 각각의 키를 공개키(public), 개인키(private)이라고 함.

: 하나의 자물쇠를 여는 키가 따로 있고, 닫는 키가 따로 있는 개념

: 공개키가 암호키이면 개인키가 복호키가 되고, 공개키가 복호키이면 개인키가 암호키가 된다.

: 공개키(혹은 비밀키)가 암호키 역할을 하는지, 복호키 역할을 하는지에 따라 암호화의 성격(목적)이 달라짐.

 

==비대칭키 암호화 ( 개인키: 암호키 / 공개키: 복호키 )

: 전자 서명의 성격을 띈다.

: 전송할 데이터에 데이터 제작자의 서명을 개인키로 암호화하여 동봉하는 상황을 가정하자. 개인키로 암호화하였기 때문에 공개키가 복호키가 된다. 공개키가 복호키이기 때문에 누구나 제작자의 서명을 복호화하여 데이터의 제작자를 확인할 수 있지만 데이터를 수정하여 다시 암호화할 수는 없다.

==비대칭키 암호화 ( 공개키: 암호키 / 개인키 : 복호키)

: 보안의 성격을 띈다.

: 누구나 정보를 암호화할 수 있지만 내용을 확인할 수 있는 사람, 즉 복호화할 수 있는 사람은 개인키를 가진 사람뿐이다.

 

>HTTPS의 암호화 방식

: HTTPS는 대칭키 암호화 방식과 비대칭키 암호화 방식을 모두 사용한다.

: 비대칭키 암호화 방식을 사용하는 것이 보안에 이점이 있지만, 알고리즘이 복잡하고 서버에 무리를 줄 수 있다. 그렇다고 대칭키 암호화 방식만 사용하기에는 서버에는 무리는 안가겠지만 보안에 취약한 면이 있다. 그렇게 때문에 HTTPS는 두 가지 방식을 모두 사용하여 키를 제작한다.

: 기본적으로 대칭키를 교환하는 것이 목표지만, 이 대칭키를 만드는 방식을 비대칭키 암호화 방식을 통해 제작하여 보안성을 높이는 방법이다. (자세한 내용은 HTTPS 통신 과정에서 설명)

>HTTPS의 통신 과정 (요약 버젼)

-인증서 : 전자 서명
-클라이언트에서 만든 대칭키
-대칭키를 암호화하여 전달 : 비대칭키(공개키) 암호화

 

>HTTPS의 통신 과정

-HandShake

1. 클라이언트가 서버를 확인함

(클라 : 서버, 안녕!)

2. 서버가 클라이언트를 확인함

(서버 : 오 클-하~)

3. 서버에서 클라이언트로 공개키와 인증서 전달

(서버 : 클라, 나야! 이거받아!)

-비밀 키 생성

4. OS 혹은 브라우저에 내장되어 있는 CA 리스트들을 근거로 서버가 제공한 인증서를 검증함.

(클라: 5252 서버 너 맞구만~)

5. 대칭키 암호화 방식을 사용하기 위해 클라이언트에서 대칭키를 생성함.

(클라: 서버! 좀만 기다려봐 이거 줄게)

6. 생성한 대칭키를 서버에 제공하기 전에 서버에게 받았던 공개키(3)로 암호화함.

(클라: 야, 근데 이거 너만봐야해. 포장해줄게)

7. 서버는 본인이 가지고 있던 개인키로 암호화된 대칭키를 받아서 복호화시킴.

(서버: 오키오키 나만볼게!)

8. 클라이언트와 서버는 둘 다 같은 대칭키를 갖게됨.

-상호 키 검증

9. 대칭키 확인을 위해 서버는 클라이언트에게 제공받은 대칭키로 암호화한 정보를 클라이언트에게 전달함.

(서버: 야 나 받았는데 이거 맞지?)

10. 클라이언트는 가지고 있던 대칭키로 정보를 복호화하여 확인함.

(클라: ㅇㅇ 맞음~)

-대칭키 소통

11. 클라이언트의 확인이 끝나면 이후부터는 클라이언트와 서버는 대칭키로 소통이 가능해짐.

(클라, 서버: 우리 이제 찐친이다! 편하게 얘기하자!)