https의 동작 원리

hjkim·2022년 1월 11일
2
post-custom-banner

https란 Hypertext Transfer Protocol Secure의 준말로, 컴퓨터 네트워크를 통한 보안 통신에 사용되고 있다. 단순히 http보다 보안이 강화되었다고만 알고 있었는데, https의 어떤 동작 부분 때문에 보안이 강화되었다는 평가를 받는지 알아보고자 한다.

https에서 통신 프로토콜은 TLS(Transport Layer Security) 또는 이전에는 SSL(Secure Sockets Layer)을 사용하여 암호화된다. 우선 암호화에 대해 나왔으니 대칭키 암호화 방식과 비대칭키 암호화 방식에 대해 살펴보도록 한다.


대칭키 암호화

대칭키 암호화 방식에서는 동일한 키를 사용하여 암복호화 한다는 특징이 존재한다. 자물쇠를 생각하면 이해가 빠르다. 사물함이나 자전거 등을 자물쇠로 잠근 뒤 가족끼리 열쇠를 나누어 갖는다. 이때 가족끼리 나누어 갖는 열쇠는 모두 자물쇠를 열고 잠그는 데 쓰이므로 동일한 모양을 갖는다.

이러한 방식의 특징은 자물쇠의 열쇠가 가족 외의 사람들에게 탈취당할 경우 문제가 발생할 수 있다. 가족들만 열 수 있었던 자물쇠를 다른 사람이 열게 되어 가족들의 자산이나 귀중품 등을 훔칠 수 있게 된다. 해당 키를 복제하여 여러 사람들에게 나누어주게 된다면 그 문제가 더 커진다.

대칭키 암호화 방식도 위와 동일하게 동일한 대칭키를 공유하여 암복호화 하는 방식이라 대칭키가 탈취되어 암호화된 문서가 평문이 되어 제 3자의 손에 들어갈 수 있다는 단점이 존재한다.

비대칭키 암호화

비대칭키 암호화 방식은 위의 그림과 같이 암호화를 할 때와 복호화를 할 때 서로 다른 키를 이용하는 방식이다. A와 B가 서로 평문을 주고받아야 한다. 위 그림의 왼쪽 사람을 A, 오른쪽 사람을 B라고 가정한다. 평문을 주고받기에 앞서 A와 B는 모두 자신의 키 쌍을 생성한다. 키 쌍에는 public key와 private key가 존재한다.

  • public key : 공개키, 사람들에게 공개된 키이며 정보를 암호화 할 수 있다.
  • private key : 개인키, 사용자만 알고 있는 암호를 풀 수 있는 키이다.

용어 자체가 지닌 의미와 같이 A와 B는 각각 자신들이 생성한 키 쌍 중 pulic key를 공개키 저장소에 공유하고 private key를 자신들만 아는 공간에 보관해 둔다. private key는 절대 타인에게 노출되어서는 안 된다.

이제 서로 문서를 주고받을 준비가 되었다. A는 B에게 문서를 전달하고자 한다. 이 문서는 중요한 문서라 외부에 공개되면 곤란하므로 암호화가 필요하다. 이 문서는 B에게 전송될 문서이므로 A는 공개키 저장소에서 B의 public key를 찾아 그 key로 문서를 암호화 해 B에게 전송한다. B는 해당 암호화 문서를 받게 되는데, 암호화 된 형태는 문서의 내용을 알아볼 수 없어 복호화를 진행한다. 이때 복호화는 B의 private key를 통해 이루어진다.

해당 방법을 사용하면 좋은 점은 public key가 아무리 탈취되어도 private key를 알 수 없다면 문서의 내용을 알 수 없다는 점이다. 더불어 private key는 각 개인만이 가지고 있으므로 누군가 문서를 복호화했을 때, 누가 복호화 해 읽을 수 있는지 명확하다는 점이다. C에게 전송하고자 C의 public key로 암호화한 문서를 전송했는데 이를 B도 받아보고자 할 경우, B는 C의 private key를 알 수 없어 실패하고 만다. 따라서 C에게 전송된 문서는 오직 C만 복호화가 가능하고, 전송자는 해당 문서를 C만 읽을 것이라고 보장받을 수 있다. 이러한 알고리즘의 방식으로는 대표적으로 RSA가 존재한다. 암호화한 키가 탈취되어도 암호문을 복호화할 수 없어 안전한 전달을 가능하게 해주는 대신 통신 속도가 느리다는 단점이 존재한다.

또한 악의적인 목적을 가진 사용자가 public key를 공유 저장소에 제공하면 해당 public key로 암호화된 평문은 악의적인 목적을 가진 사용자만 조회할 수 있게 된다. 이러한 문제를 해결하기 위해 나온 방법이 바로 CA(Certificate Authority)를 두는 것이다. 인증기관(CA)은 데이터 검증절차를 거치게 한다.


https 통신

https 통신은 대칭키와 비대칭키 방식을 전부 사용하는 하이브리드 방식이다.
https는 보안을 위해 SSL '인증서'를 사용하고 있다. 이 인증서는 CA로부터 발급받는다. 즉, public key와 private key쌍의 정보가 거짓이 없고 유효한 정보라는 사실을 CA로부터 인증받는 것이다. 그 절차는 다음과 같다.

  1. 서버에서 public key와 private key를 생성한다.
  2. 인증서 발급을 위해 서버에서 생성한 public key와 각종 서버 정보를 전달한다.
  3. 서버로부터 받은 정보와 서버의 공개키를 담아 SSL 인증서를 발급한다.
  4. 발급된 인증서를 암호화하기 위해 CA의 private key로 SSL 인증서를 암호화하여 서버에 전달한다.

이제 https로 사용자가 접속한 경우 어떠한 일이 발생하는지 살펴본다.

  1. Client Hello : 말 그대로, 클라이언트가 인사를 건넨다는 의미이다. 즉, 클라이언트에서 통신하고 싶은 서버로 연결을 시도하는 패킷을 전송한다. 패킷에는 클라이언트에서 사용 가능한 cipher suite 목록과 이 cipher suite에 어떤 프로토콜(TLS/SSL)을 사용할지, 인증서 검증 또는 데이터를 어떤 방식으로 암호화할지 등이 표시된다.

  2. Server Hello : 1에서 받은 인사에 대해 서버가 응답을 한다. cipher suite 목록 중 1개의 cipher suite, 사용할 프로토콜의 버전 정보 등을 응답으로 보낸다.

  3. Certificate : CA로부터 발급받은 인증서를 전송한다.

  4. Server Key Exchange : 3번의 Certificate 패킷을 전달할 때 SSL 인증서 내부에 서버의 public key가 존재한다면 해당 과정은 생략된다. 하지만 SSL 인증서 내부에 public key가 존재하지 않는다면 서버에서 직접 public key를 전달하는 과정이 이에 해당한다.

  5. Certificate Request : client에서 server의 SSL 인증서 검증이 이루어진다. 클라이언트는 CA의 공개키를 통해 암호화된 인증서를 복호화한다. 이때, CA의 공개키를 이용해 인증서를 복호화했을 때, 복호화가 가능했다는 것은 인증서가 해당 CA에서 발급되었다는 것을 검증하는 의미를 갖는다.

  6. Server Hello Done : Server Hello 절차가 완료되었음을 client에 알리는 Server Hello Done 메시지를 client에 전송한다.

  7. Client Key Exchange, Change Cipher Spec : client에서 pre-master-key라는 것을 전송한다. 이 key는 1, 2 단계에서의 난수를 조합하여 생성하며 대칭키로 사용하게 된다. 이 대칭키를 서버에 안전하게 전달하기 위해 비대칭키 암호화 방식을 사용한다. 즉, 서버의 public key로 암호화 하여 서버에 전달한다. 그러면 서버의 private key로만 복호화가 가능하여 서버 쪽에서만 대칭키를 전달받을 수 있다.
    서버의 public key는 4번 과정에서 SSL 인증서를 복호화해 받는다. SSL 인증서 내부에 없을 때에는 서버로부터 직접 전달받는다.
    이제 서버와 client는 대칭키를 나누어 갖게 된다.

  8. Change Cipher Spec : client로부터 전송받은 pre-master-key를 정상적으로 복호화 한 후 master-key로 승격한 뒤 통신할 준비가 완료되었다는 Change Cipher Spec을 보낸다.

https 통신에서는 안전한 대칭키 전송을 위해 비대칭키 암호화 방식을 사용하였고 빠른 통신을 위해 대칭키 암호화 방식을 사용하고 있다. 각각의 장점을 사용해 단점을 보완하고 있음을 알 수 있었다.


[참조] https://devdy.tistory.com/14
[참조] https://devlimk1.tistory.com/135
[참조] https://mysterico.tistory.com/30
[참조] https://nuritech.tistory.com/25
[참조] https://blog.naver.com/PostView.nhn?blogId=chodahi&logNo=221406287669&parentCategoryNo=&categoryNo=13&viewDate=&isShowPopularPosts=true&from=search
[참조] https://blog.naver.com/taeyoun795/220818138527

profile
피드백은 언제나 환영입니다! :)
post-custom-banner

0개의 댓글