HTTPS 암호화방식

HTTPS는 HTTP Secure의 약자로, 단어 뜻 그대로 기존의 HTTP 프로토콜을 더 안전하게(Secure) 사용할 수 있음을 의미합니다.단지 뒤에 S가 붙었을 뿐인데 왜 HTTP보다 안전하다는 걸까요? 그 이유는 HTTPS가 HTTP와 달리 요청과 응답으로 오가는 내용을 암호화하기 때문입니다.

HTTP로 보낸 요청을 'wireshark'라는 패킷 분석 프로그램을 이용하여 캡처한 것입니다. 이미지를 확인해 보면, email과 password 같은 값을 그대로 볼 수 있는 것을 알 수 있습니다. 이는 제3자가 HTTP 요청 및 응답을 탈취한다면 전달되는 데이터의 내용을 그대로 확인할 수 있다는 뜻이기도 합니다.

이처럼 HTTPS가 HTTP 통신을 암호화하기 위해서 어떤 과정을 거치는지 조금 더 자세히 들여다보기 전에, 암호화 방식에는 어떤 것이 있는지 먼저 간단하게 살펴보도록 합시다.

 

 

 

인증서와 CA(Certificate Authority)

HTTPS를 사용하면 브라우저가 서버의 응답과 함께 전달된 인증서를 확인할 수 있습니다. 이러한 인증서는 서버의 신원을 보증해 줍니다. 이때 인증서를 발급해 주는 공인된 기관들을 Certificate Authority, CA라고 부릅니다.

인증기관(CA)에서 사용하는 공개키와 비공개키가 있고
서버에서 사용하는 공개키와 비공개키가 있다

서버에서 https 프로토콜을 연결하기 위해서 인증서를 받고 싶어함
서버가  CA 에 인증서를 요청함
서버는 공개키를 보내고 CA는 이 공개키를  암호화시키고 인증서로 만듦
그럼 서버는 인증서를 받게 됨 받음

브라우저는 신뢰하는 인증기관들의 공개키를 모두 내장하고 있다
이 인증서가 신뢰하는 기관의 인증서인가? 하면서
복호화를 하려함

복호화 가능 — 신뢰할 수 있는 인증서, 클라이언트가 서버의 공개키를 먹게 됨
복호화 불가능 - 믿을 수 없는 인증서 !

 

 

드디어 클라이언트는 서버의 공개키를 확보했습니다.
그럼 이 공개키를 사용해서 데이터를 주고받게 될까요?
아닙니다. 공개키 암호화방식은 보안은 확실하지만 소모적, 효율 down

 

 그럼 이 공개키는 어떻게 쓰이지?
클라이어언트와 서버가 같이 사용하게 될 대칭키를 주고받을 때 사용
대칭키는 탈취당할 위험이 있지만, 클라이언트가 서버로 대칭키를 보낼때 서버의 공개키를 사용해서 암호화해준다면,
서버의 비밀키를 가지고 있지 않은 이상, 해당대칭키를 복호화(해독) 할 수 없습니다

 

클라이언트는 대칭키를 서버의 공개키를 사용해서 암호화하고 서버에 보내준다.
서버의 비공개키로 복호화를 하고, 대칭키를 서버도 갖게 된다
이제 클라이언트도 서버도 모두 대칭키를 가지게 된다.

 

정리하자면, 이렇게 서버와 클라이언트간에 CA를 통해 서버를 인증하는 과정과 데이터를 암호화하는 과정을 아우르는 프로토콜을
SSL 이라고 하고, HTTP 에 SSL을 더한 것을 HTTPS 라고 합니다