HTTPS 통신 방식

현대 웹에서는 암호화를 위해 HTTPS 프로토콜을 사용해 통신이 이루어진다. 

하지만, HTTPS 프로토콜을 통해서 암호화가 된다는 사실만 알고 있을 뿐 내부적으로 어떤 인증체계를 가지고 있는지 알지 못한다. 

이번 글에서 HTTPS 통신이 내부적으로 어떤 인증체계를 갖추고 있는지 한번 알아보자.

사전 지식 

암호 기술에 대한 이해 

대칭키 

• 하나의 키로 암호화/복호화를 모두 하는 방식이다. 
  • 암호화 : 보안성을 부여한다. 
  • 일상생활에서 키를 사용하는 방식과 동일하다. 
• 대칭키는 효율이 좋기 때문에, HTTPS 방식에서 데이터를 암호화 하는데 사용된다. 
• 대칭키가 노출되는 순간 암호화는 의미가 없어지기 때문에 키를 저장, 전달하는 방식이 매우 중요하다!
  (대칭키는 매우 중요한 개인정보로 취급된다.)

비대칭키 

• 한쌍의 키(공개키, 비밀키)가 서로 상호작용 하는 구조를 갖는다. 
• 두 키중 하나로 암호화를 한다면 다른 하나의 키로 복호화를 한다. 
  • 각각의 키는 암호화, 복호화 중 하나의 기능만 수행한다. 
• 대칭키 방식에 비해 훨씬 복잡한 수학적 연산(소인수분해의 어려움, 타원곡선 연산 등)을 사용하기 때문에 계산 비용이 높고 처리 속도가 현저히 느리다. 
• 하지만, 하나의 키가 노출되더라도 다른 하나의 키를 가지고 있지 않는다면 암호화 된 데이터를 복호화 할 방법이 없기 때문에, 보안성이 뛰어나다!

공개키 신뢰를 위한 검증체계 

대칭키 인터넷 환경 문제 

• 대칭키 체계에서 키는 매우 중요한 개인정보인데, 이 정보를 어떻게 안전하게 보낼 것인가? 
• 하지만, 대칭키를 인터넷 환경에서 일반적인 송수신으로는 안전하게 전달할 수 없다.. 
  • 통신의 효율을 위해서 대칭키를 사용해 데이터를 암복호화 해야 한다..
• 이를 해결하기 위한 방식이 비대칭키를 통한 대칭키 송수신이다. 
  • SSL 인증의 기반이다!

효율 극대화를 위한 혼합(대칭키, 비대칭키) 활용

대칭키, 비대칭키를 모두 활용한 방법은 다음과 같다. 

1. 서버는 비대칭키(공개키, 비밀키) 를 만든다. 
2. 서버의 공개키를 기반으로 클라이언트는 대칭키를 암호화한다. 
3. 암호화된 대칭키를 송수신한다. 
4. 서버는 공개키로 암호화 된 대칭키를 비공개키를 사용해 복호화한다. 
5. 클라이언트 - 서버 는 공유된 대칭키를 기반으로 암복호화 해 통신한다. 

하지만 여기에서 서버의 공개키를 해커가 가로채 해커의 공개키로 클라이언트에게 전달한다면? 

• 클라이언트는 해커의 공개키로 대칭키를 암호화해서 서버에게 요청을 보내게 된다. 
• 요청을 보내는 중간에 해커는 암호화 된 대칭키를 확인하고 서버의 공개키로 다시 암호화 후 서버에 전달해준다. 

위 상황이 완성된다면, 해커는 중간에서 클라리언트와 서버의 모든 송수신 정보를 도청할 수 있다!

공개키 신뢰를 위한 검증 체계 

앞서 비대칭키 방식은 컴퓨팅 파워를 많이 소모하는 방식이라고 설명했다. 때문에, 한 번 만들어진 비대칭키는 여러번 사용되어야 한다. 

• 일반적으로 WEB 에서는 SSL 인증서 1회 생성 시 6개월 ~ 1년 사용한다.

일반적으로 WEB(HTTP) 상에서는 비대칭키 형식이 아닌, X509 문서 형식의 SSL 인증서 형식으로 사용한다.

• X509 문서는 SSL 인증서 정보, 공개키, Hash 값 등 다양한 정보를 포함하고 있다.
• Hash 값은 CA 의 비밀키로 암호화 되어있다.

SSL 인증서 발급 방식은 다음과 같다.

1. WEB Server 담당자가 인증서 발급을 위해 RA(인증서 등록 대행) 업체에 구매요청을 한다.
2. 요청을 받은 RA 업체는 CA(인증서 발급) 업체에 인증서 발급 요청을 한다.
3. CA 업체는 X509 문서 형식의 SSL 인증서와 비밀키를 발급해 RA 업체에 전달한다.
4. RA 업체는 WEB Server 담당자에게 인증서와 비밀키를 전달하고, 담당자는 WEB Server 에 인증서와 비밀키를 등록한다.

SSL 인증서를 통한 HTTPS 통신 방식 

1. 클라이언트 인사(Client Hello) 
   • 클라이언트 브라우저가 웹사이트(서버) 에 접속을 시도하면, "안녕? 우리 암호화된 통신을 할 것인데, 인증서를 줄 수 있어?" 라고 인사를 보낸다. 
2. 서버의 응답 및 신분증 제시(Server Hello + Certificate)
   • 서버는 클라이언트의 인사를 받고 "그래, 안녕 너랑 나는 이 신분증(SSL/TLS 인증서) 내에 있는 암호화 방식을 쓸 거야. 그리고 이건 내 신분증이야, 이걸로 내가 진짜 이 웹사이트 주인인지 확인해봐." 라고 응답한다. 
   • 핵심 : 여기서 서버는 자신의 '공개키' 를 직접 주는 것이 아니라, '공개키'가 포함된 '신분증' 을 준다는 것이다. 이 신분증은 서버의 신분을 증명하는 일종의 전자 신분증이다. 
3. 클라이언트의 신분증 검사(인증서 유효성 검사) 
   • 클라이언트 브라우저는 서버가 준 신분증(SSL/TLS 인증서) 을 받고서 서버의 신원을 검증해야 한다. 
   • 클라이언트 브라우저는 기관인증서(CA의 공개키) 를 통해서 인증서 내 서명값을 복호화하고(복호화하면 Hash 값이 나온다), 인증서 내부 정보로 만든 Hash 값과 비교해 올바른 인증서인지 검증한다. 
     • 이 부분이 중요하다. 서버의 신분증은 공인된 기관(CA: Certificate Authority) 이 "이 서버는 진짜입니다." 라고 서명한 것이다. 이 서명은 CA 의 비밀키로 암호화되어 인증서에 포함되어야 한다. 
     • 클라이언트는 운영체제 업데이트를 통해서 미리 신뢰할 수 있는 CA 공개키가 잔뜩 심어져 있다. 
       • 운영체제 보안 업데이트를 할 때 CA 값이 갱신된다고 생각하면 된다.
     • 클라이언트는 미리 심어져 있는 CA 공개키를 사용해 서버 인증서 내 서명값을 복호화하고 인증서 내부 정보로 만든 Hash 값과 동일한지 비교한다. 
     • 만약 서명값을 복호화한 값과 인증서 내부 정보로 만든 Hash 값이 동일하다면 "아, 이 인증서는 CA 가 발급한 인증서가 맞네? 신뢰할 수 있겠다!" 라고 판단한다. 
4. 공개키 암호화 및 전달(Client Key Exchange) 
   • 신분증이 진짜라고 판단된다면, 인증서 내 공개키를 사용해 대칭키를 암호화 해 서버로 전달한다. 
     • 해당 대칭키를 실제 서버와 통신 시 암복호화에 사용될 대칭키이다. 
5. 공개키 공유 완료 및 암호화 통신 시작(Change Cipher Spec + Finished) 
   • 서버는 자신의 개인키로 클라이언트가 보낸 암호화된 대칭키를 복호화해 대칭키를 확보한다. 
   • 이제 클라이언트와 서버는 동일한 대칭키를 확보하게 되었다. 
   • 공유된 대칭키를 활용해 안전하게 통신을 시작한다. 

결론적으로 HTTPS 통신에는 2가지 비대칭 키가 사용된다.

1. 인증서 검증을 위한 CA 비대칭 키 
2. 실제 대칭키를 암복호화 하기 위한 비대칭 키