HTTPS를 왜 써야해? (Feat. 대칭키 & 공개키(비대칭키))

※ 개인 공부를 위한 공간입니다. 틀린 부분 지적해주시면 감사하겠습니다 (_ _)

 

최근 한 개발자에게 질문을 들었다.

"Http랑 Https 차이가 뭔지 아나?"

 

현재 재직중인 회사에서 상용화 준비중인 서비스에 SSL 인증서를 직접 붙여본 나로서는 당연히 대답할 수 있어야 했던 질문이었지만..

나의 대답은 짧았다.

"Http + secure의 약자로써, 보안이 추가된 인터넷 프로토콜.... 일 걸?"

 

역시나, 나는 또 습관처럼 '일단' 구현하고 봤던 것이다.

이제 어디가서 뭘 해봤다고 말하기가 정말 무섭다 ㅠㅜ

그래도, 성장의 기회로 삼고 정리를 해보려고 한다.

SSL 인증서에 사용되는 기본 암호화 인증 방식부터!

 

내용 상당 부분은 얄코님의 영상을 참고하였습니다.

https://www.youtube.com/watch?v=H6lpFRpyl14 

 

HTTP에(HypterText Transfer Protocol) 대하여

• 웹상에서 네트워크 통신을 통한 형식 혹은 구조, 규약이다.
• TCP/IP 기반이다. (osi 7 layer 중 layer3, layer4를 다루는 프로토콜)
• Stateless (즉, 상태를 저장하지 않는다라는 말이다.) - 요청(request)에 대한 응답(response)을 하고 그걸로 통신은 끝이다. 다음 요청 및 응답 때, 이전 요청, 응답에 대해 알 수가 없다.
• Request 구조 -> Startline(Method, URI, Version), Headers, Body
• Response 구조 -> Startline(Version, Status code, Status text), Headers, Body
• Methods: Get(읽기), Post(생성), Put(수정), Delete(삭제) (자주 쓰이는 메소드들이며, 실제로는 더 많다.)
• Status Code: 200번대(성공), 300번대(redirection), 400번대(Client Error), 500번대(Server Error) (에러코드 또한 상세하게 나눌 수 있다!)

 

암호화가 필요한 이유?

서버와 클라이언트가 통신 시, 데이터를 주고 받는데 민감한 정보 또한 주고 받게 되어 있다. ex. 로그인정보, 은행정보 등

기존의 HTTP 통신은 이러한 민감한 정보를 주고 받을 경우, 발생하는 보안적 이슈를 해결해 줄 수 없다고 한다.

1. 클라이언트에서 보내는 정보를 제 3자가 볼 수 없게 한다.
2. 접속한 사이트가 믿을만한 곳인지 검증해준다.

를 위하여, HTTPS가 탄생한 것이다.

본격적으로 어떻게 Secure를 구현하는지 알아보겠다.

 

대칭키와 공개키(비대칭키)란?

대칭키란 암복호화를 함에 있어 동일한 키가 사용된다.

암호화 시 a라는 키를 사용, 복호화 시 a라는 키를 사용한다.

공개키란 암복호화를 함에 있어 다른 키(개인키, 공개키)가 사용된다. 비대칭키라고도 불린다.

암호화 시 a(개인키) 사용, 복호화 시 b(공개키)를 사용한다. (반대도 가능)

 

암호화 방식이 어떻게 적용되는가?

• 공개키 방식이 필요한 이유

클라이언트와 서버가 통신을 할 때에 대칭키 방식으로 암복호화가 진행된다면,

중간에 대칭키를 탈취당한다면, 똑같은 대칭키로 복호화가 진행되기 때문에 민감한 정보들이 노출될 위험이 크다.

그리하여 공개키(비대칭키) 방식으로 암복호화가 진행된다.

• 통신을 하는 과정

예를들어, 네이버와 통신을 한다고 가정했을 때 네이버에서 개인키를 가지고 있고 우리는 공개키를 가지고 있습니다.

로그인을 한다고 가정하고, 우리가 가진 공개키로 아이디, 비밀번호를 암호화 합니다.

(혹시나 중간에 해커가 복호화를 하려고 해도, 같은 공개키로 복호화 할 수 없겠죠?)

그리고 네이버에서 가진  개인키로 복호화하여 정보를 주고 받습니다.

• 암호화 하는 과정

그렇다면, 우리는 어떻게 네이버에서 준 공개키임을 믿고 네이버와 통신을 할 수 있을까요?

정답은, 우리의 브라우저에 저장된 CA(Certificate Authority)라고 해서 검증된 기간에서 정품인지를 확인해줍니다.

1. 핸드쉐이크
   1. 클라이언트 ---무작위데이터1---> 서버
   2. 서버 ---무작위데이터2+인증서---> 클라이언트
2. 브라우저에 내장된 CA를 통한 인증서 검증
   1. 서버에서 보낸 인증서는 CA의 개인키로 암호화가 되어있다.
   2. 브라우저에 저장된 CA의 공개키로 복호화 (CA를 통해 인증을 받은 서버의 인증서라면 복호화 가능!!!)
   3. 성공적으로 인증서를 복호화를 하게 되면, 서버의 공개키가 포함되어 있다. (인증완료) -> 실패한다면 Not Secure 서버!
3. 대칭키 생성
   1. 매번 통신 시 마다 공개키를 활용하여 암복호화를 하는 건 컴퓨터에 무리를 줄 수 있다. 그래서, 더 간단한 대칭키 방식 채용 (공개키 방식을 활용한 대칭키 생성 및 교환)
   2. 클라이언트에 있는 무작위데이터1+무작위데이터2를 활용하여 무작위데이터3 을 만든다.
   3. 무작위데이터3을 공개키로 암호화하여 서버로 보낸다.
   4. 서버에서 개인키 활용 복호화 및 일련의 과정을 거치게 된다. 
   5. 이후 동일한 대칭키를 갖게 된다.
4. 동일한 대칭키를 가지고 통신!

(글로 이해가 되지 않으신다면, 얄코님의 영상을 보시기를 추천합니다!)

 

서버를 HTTPS화 하는 것은 사실상 최소한의 필수 요건이라고 한다.

 

원리도 모른 채, https 적용을 했던 내 자신을 되돌아보니 "왜?" 라는 질문에 대답조차 못 했었다.
(물론, 모든 원리를 이해한 채 구현을 하려면 시간이 너무 오래 걸려서 힘들겠지만..)
그래도 꼭 구현 뒤, 공부하는 습관을 가지도록 노력해야겠다. 오늘도 새로운 지식에 감사!!!
(향후에, https가 적용되지 않은 서버를 구현하여 직접 공개키를 탈취해보는(?) 시간도 가져보고 싶다..)