지난 주, 관심있는 서비스를 개발하고 운영하는 회사의 면접을 다녀왔다.
아직 크게 눈에 띄는 잘난 경력이나 경험은 없지만 그럼에도 긍정적인 부분을 보고 면접을 불러주신 만큼, 꼭 내가 가진 역량과 가능성을 다 보여드리고 싶었다.
너무 간절한 나머지 목소리도 떨렸지만 편안한 분위기를 만들어주셔서 금방 진정할 수 있었고, 최선을 다해 면접에 임했다. 이력서 기반과 기술 관련 질문에 대해서도 어려운 부분이 있었지만, 네트워크와 관련된 질문에서는 어떤 질문도 제대로 답 하기 어려웠다.
우주 최고의 백엔드 개발자를 꿈꾸지만 그동안 네트워크에는 너무 무관심했었다.
당장 스프링으로 서버를 구축해야해! 필요한 화면 정도는 간단하게라도 내가 만들 수 있어야해! 배포는 자동화 시켜야해!
아직도 모르는게 많고 배울게 많은 입장인데 너무 '개발'에만 치중해 공부하고 고민했던건 아닌가 하는 생각이 들었다.
어쩌다보니 회고가 되어가고 있는 것 같은데 다시 본론으로 돌아오면, 이 게시물은 내가 면접 때 제대로 대답하지 못한 HTTP와 HTTPS에 대해 공부해보고 그 내용을 정리하는 포스팅이다.
HTTP는 무엇인가?
HTTP는 Hyper Text Transfer Protocol의 약자이다.
여기서 Hyper Text는 html을 의미한다. Protocol은 통신 규약을 의미한다.
즉, HTTP는 html을 교환하기 위한 통신규약, 약속이라고 생각하면 된다.
기본적으로 서버가 80포트에서 요청을 기다리고 있기 때문에 클라이언트에서 80포트로 요청을 보낸다.
서버와 클라이언트는 특정한 구조를 갖고 요청과 응답을 통해 데이터를 전송하는데, 이 정보는 암호화 되어있지 않기 때문에 누군가가 해당 정보를 탈취한다면 그대로 모든 정보를 확인할 수 있다는 한계점이 있다.
HTTPS는 무엇인가?
HTTP의 보안상 취약점을 해결하기 위해 등장했다.
HTTP와 다르게 기본 포트를 80이 아닌 443을 이용한다.
HTTP 뒤에 붙은 S는 Secure를 의미하고, HTTP 데이터에 암호화가 추가되었다.
따라서 HTTPS를 사용한다면 클라이언트와 서버간 통신 데이터가 노출되어도 암호화가 되어있기 때문에 정보를 지킬 수 있다. 또한, 클라이언트에서 요청을 보내는 서버가 신뢰 가능한 서버인지도 확인할 수 있다.
대칭키와 비대칭키
HTTPS가 어떤 방식으로 구현되어 있는지 알기에 앞서 먼저 대칭키와 비대칭키의 개념에 대해 먼저 알면 좋을 것 같다.
대칭키
- 하나의 키를 활용해서 암호화와 복호화를 하는 방식
- 연산속도가 빠르다는 장점이 있지만, 서버와 클라이언트가 같은 키를 공유하는 과정에서 키가 탈취된다면 보안 문제가 생기는 단점이 있다.
예를 들어, 서버와 클라이언트 모두가 3이라는 것을 키로 갖고 있고, 키로 암호화/복호화 하는 알고리즘은 곱하기/나누기라고 가정해보자.
그렇다면 클라이언트가 4라는 데이터를 전송하기 위해 대칭키인 3으로 암호화를 해서 12를 서버로 전송했을 것이고, 서버 역시 대칭키은 3으로 12를 복호화해서 클라이언트가 4를 전달했다는 것을 알게 될 것이다.
하지만 아무리 이 키로 암호화를 해서 데이터를 전송한다고 해도, 누군가가 이 똑같은 키를 갖고 있다면 해당 데이터를 쉽게 알아낼 수 있다는 한계점이 있다.
비대칭키(공개키, 개인키)
- 대칭키의 한계점을 극복하기 위해 등장
- 한쌍의 키(공개키와 개인키)를 활용해서 암호화와 복호화를 하는 방식
- 공개키로 암호화 한 데이터는 개인키로만 복호화가 가능하고, 개인키로 암호화 한 데이터는 공개키로만 복호화가 가능하다.
- 대칭키를 통한 암호화 복호화보다 연산속도가 오래걸린다는 단점이 있지만, 하나의 키가 노출되어도 비교적 안전하다는 장점이 있다.
- 비대칭키를 발급받기 위해서는 CA(Certificate Authority)의 인증이 필요하다. (서버의 인증서를 CA의 개인키로 암호화)
HTTPS는 이 비대칭키를 적극적으로 활용한다.
서버에서는 개인키, 클라이언트에서는 공개키로 암호화를 하여 상대방에게 데이터를 전달한다.
앞서 언급했듯 공개키로 암호화한 내용은 공개키로 복호화가 불가능하기 때문에, 클라이언트에서 서버로 요청하는 데이터가 노출되어도 다른 클라이언트에서는 이 데이터를 복호화 할 수 없어 안전하다.
HTTPS의 동작 과정
그렇다면 HTTPS 방식은 이렇게 비대칭키 방식만을 이용해서 데이터를 전달할까?
정답은 아니다.
아무리 현대의 컴퓨터 성능이 비약적으로 상승했다고 해도 대량의 데이터를 비대칭키 방식만을 사용해 암호화/복호화 한다면 무리가 많이 갈 것이다.
HTTPS는 대칭키와 비대칭키를 혼합하여 사용하며 빠른 연산 속도와 높은 안정성으로 두마리 토끼를 모두 얻고 있다.
아래는 HTTPS가 동작하는 과정이다.
- 클라이언트가 랜덤 데이터를 생성해서 서버로 요청.
- 요청을 받은 서버 역시 랜덤으로 생성한 데이터와 인증서를 클라이언트로 응답.
- 브라우저에 내장된 CA 정보를 통해 서버로부터 전달받은 인증서가 CA로부터 인증받은 진짜 인증서인지 확인.
=> CA에서 인증받은 인증서들은 해당 CA의 개인키로 암호화가 되어있기 때문에, 브라우저에서 관리하고 있는 CA의 공개키로 해당 인증서를 복호화 할 수 있다.
만약 여기서 복호화에 실패하게 된다면 이는 CA의 인증을 받지 못한 인증서라는 의미가 되고, 해당 인증서를 발급한 서버는 신뢰할 수 없는 서버라고 판단할 수 있다. - 인증서 복호화를 통해 서버의 공개키를 얻은 클라이언트는 이 공개키로 세션키를 암호화하여 서버로 전송
- 서버에서는 개인키로 세션키를 복호화
- 클라이언트와 서버가 모두 갖고 있는 세션키를 활용하여 대칭키 방식으로 데이터를 암호화/복호화하여 요청과 응답
출처 : https://publib.boulder.ibm.com/tividd/td/TRM/GC32-1323-00/en_US/HTML/admin231.htm
즉, 서버와 클라이언트간 빠른 암호화/복호화를 위해 대칭키를 사용하는데, 이 대칭키를 안전하게 전달하기 위해 비대칭키를 활용한 암호화가 이루어진다.
참고
