클라이밍 앱 '클밋'을 제작하며 고민/개발 내용을 기록한 글입니다.
당장 key파일을 옮겨서 해결하는 것보다 다시는 비슷한 일을 겪지 않게 위해 통신과정부터 개념을 이해하고자한다.
이전처럼 따라하지만 말고 왜 HTTPS를 써야하는지부터 이해해보자!
HTTP통신은 OSI7계층중 애플리케이션 계층에서 작동하는 프로토콜이다.
HTTP는 평문으로 통신을 해 중간자가 가로채면 그대로 읽을 수 있다.
와이어샤크를 통해 패킷을 확인해보자!
이전에 진행했던 프로젝트 중에https를 적용하지 못했던 좋은 예시가 있다.
쇼핑몰 프로젝트 기록
회원가입을 했다. 프론트에서 서버로 아이디와 패스워드 이메일이 담긴 패킷이 날라갈 것이다.
비밀번호를 가로챌 수 있는지 확인해보자
와이어샤크 상단에 서버 ip로 필터링을 했다.
3-way handshake 이후 http통신한 것을 볼 수 있다.
이제 패킷을 자세하게 보면
와이어샤크를 사용법을 블로그에서 잠깐 본 나도 손쉽게 중요정보를 확인할 수 있었다.
이번에는 HTTPS를 확인해보자. HTTPS가 되어있는 클밋 스테이징 서버의 관리자 회원가입을 진행해봤다.
공격자는 난수밖에 볼 수 없다.
http
라고 감청이 쉽게 되는 것은 아니지만 HTTPS
에 비해서는 상대적으로 취약하다.
보안이 좋은데다가 구글의 검색엔진 최적화까지 챙기기 위해서 HTTPS
는 필수라고 봐야한다.
HTTP 통신은 공공와이파이, 악성 소프트웨어,
로컬 네트워크 등으로 감청이 가능하다고한다. [출처 : 지피티]
SSL이라는 하나의 통신 레이어를 추가해서 암호화를 한다. HTTPS는 SSL레이어 위에서 HTTP를 통과시키는 방식이라고 한다.
아까 본 평문의 데이터가 SSL레이어를 통과하면서 암호화되고 다시 목적지의 SSL레이어를 통과하면서 복호화되는 것이다.
그럼 아무나 복호화를 할 수 있나?
그건 또 아니다.
이를 알기 위해서는 비대칭키의 개념이 중요하다.
간단히 말해 한 쌍의 서로 다른 2개의 키가 있다고 생각하자.
A키로 암호화를 하면 무조건 B키로만 복호화를 할 수 있다.(대칭키)
그럼 네이버는 B키를 가지고 있고 A키를 공개한다. 그러면
1. 유저들은 공개된 A키를 통해 암호화한다.
2. 네이버는 서버에서만 갖고 있는 B키를 통해 복호화한다.
이렇게만 되면 문제가 없지만 한가지 문제가 있다.
다른 악의를 가진 제3자가 가짜 네이버 서버를 만들어 유저들에게 공개키 A'를 뿌린 것이다.
그럼 유저들은 네이버에 로그인하기 위해 정보들을 정성스레 A'키로 암호화한 후에 다른 목적지로 보내게 된다. 이를 제3자는 악용할 수 있다.
따라서 이를 막기 위해 암호화, 복호화에 다른 키를 쓰는 것이 비대칭키이다.
하지만 비대칭키가 장점만 있는 것은 아니다.
암호화, 복호화에 대칭키에 비해 시간이 걸린다는 단점이 있다.
따라서 HTTPS 통신은 키 방식 두가지를 섞어서 쓰고 있다.
간단히 말하면 핸드쉐이킹시 비대칭키
를 사용하고 이후 세션 유지 기간동안 통신에는 대칭키
를 사용하는 것이다.
자세히 과정을 살펴보자.
사실 2번에서 한가지 과정을 더 거쳐야한다.
브라우저단에서 공개키가 네이버것인지 확인해야하는데 이를 인증해주는 기관이 Certificate Authority, CA이다.
네이버는 CA에 SSL 인증서
를 요청하여 인증서를 발급받는다. 그러면 유저들은 CA기관에서 미리 받아 브라우저(크롬, 사파리)에 저장된 인증서 리스트와 비교한다.
만약 있다면 인증서 안에 공개키를 얻을 수 있다.
이를 그림으로 정리해봤다.
이제 각자의 세션키로 데이터를 암호화해서 대칭키 통신을 하게 된다.
때문에 앞서 와이어샤크로 봤을 때 암호화가 되어 보인 것이다.
이제 이론에 대해 살펴봤으니 다음 포스팅으로는 클밋에 적용한 방식과 어떤 문제점이 있는지, 어떻게 해결할 지에 대해 작성할 것이다.
참고 : 재능없는 개발자 - HTTP와 HTTPS 그리고 SSL
100100e - Https는 공개키?
tiptopsecurity - How Does HTTPS Work?