HTTPS 통신이 이루어지는 원리

프로젝트에서 HTTPS를 적용하기 위해 학습했던 내용에 대해 정리해보려고 합니다. 학습과정에서 작성되었기 때문에 잘못된 내용이 있을 수 있습니다.

 

 

    - HTTPS와 부가개념

    - 동작원리

    - 결론 / HTTPS를 적용했던 이유

 

 

 

 

1. HTTPS 

---

HTTP는 정보를 텍스트로 주고 받기 때문에 네트워크에서 전송 신호를 가로채는 경우 원하지 않는 데이터 유출이 발생할 수 있습니다. 이러한 보안 취약점을 해결하기 위해 등장한 프로토콜이 HTTPS 입니다. **와이어샤크를 통해 패킷을 복호화시키는 과정에 대해 해당 블로그에서 잘 설명해주셨습니다. 

 

 

HTTPS는 HTTP와 거의 동일하지만 데이터를 주고 받는 과정에 보안 요소가 추가됩니다. HTTPS를 사용하면 서버와 클라이언트 사이의 모든 통신 내용이 암호화되는데, 즉 페이지를 암호화한 키가 그 페이지를 보는 특정 사용자에게만 알려지도록 합니다. SSL이나 TLS 프로토콜을 통해 세션 데이터를 암호화하며 기본 TCP/IP 포트는 443. SSL 프로토콜 위에서 동작합니다.

 

 

EC2 인스턴스를 사용하면서 443포트를 여는 이유다. 443포트로 들어오는 트래픽을 받을 수 있게 포트를 열어준다.

 

 

 

 

 

 

HTTPS를 이해하기 위해서는 SSL 인증서, CA, 암호화 방식과 같은 몇 가지 개념을 추가로 알고 있어야 하는데요, 이것들에 대해 간략하게 살펴보겠습니다. 

 

 

 

 

1-1. CA(Certificate authority)

공인된 인증기관으로 사이트에 대한 인증서를 발급해줍니다. 인증서는 접속한 서버가 클라이언트가 의도한 서버가 맞는지를 보장하는 역할을 합니다. 

 

 

 

1-2. SSL의 인증서의 역할과 정보

웹사이트의 신원을 확인하는 디지털 인증서. SSL(Secure Sockets Layer) 인증서는 클라이언트가 접속한 서버가 신뢰 할 수 있는 서버임을 보장합니다. 

 

   - 서비스의 정보(인증서를 발급한 CA, 서비스의 도메인 등)

   - 서버 측 공개키(공개키의 내용, 공개키의 암호화 방법)

 

 

 

1-3. 암호화

공개키 암호화 방식과 대칭키 암호화 방식을 함께 사용합니다. 대칭키는 공개키방식의 단점인 속도를 개선하기 위해 사용하는데요, 공개키 방식으로 대칭키를 전달한 뒤 공유하고 있는 대칭키를 통해 통신하게 됩니다. 각 방법에 대해 간략하게 알아보겠습니다. 

 

 

1-3-1. 공캐키 방식

공개키와 비밀키에 대해서는 위키에 잘 정리되어 있습니다. 자세한 내용은 위키 내용을 참조해주세요.

     

     - A키로 암호화를 하면 B키로 복호화를 할 수 있다.

     - B키로 암호화를 하면 A키로 복호화를 할 수 있다.

     - 둘 중 하나를 비공개키(Private Key) 혹은 개인키라 부르며, 이는 자신만 가지고 있고 공개되지 않는다.

     - 나머지 하나를 공개키(Public Key)라고 부르며 타인에게 제공한다. 공개키는 유출이 되어도 비공개키를
        모르면 복호화 할 수 없기 때문에 안전하다.

 

1-3-2. 대칭키 방식

동일한 키로 암/복호화가 가능한 방식. 대칭키는 매번 랜덤으로 생성되기 때문에 유출되더라도 다음에 사용할 때는 다른 키가 사용되기 때문에 안전합니다. 또한 이는 공개키보다 빠르게 통신할 수 있습니다. 

 

 

2. 동작 과정

---

이제 어떻게 동작하는지 살펴보겠습니다. 간단히 요약해보면 CA를 통해 인증서를 발급받고 대칭키/비대칭키 방식을 사용해 통신의 효율성과 신뢰성을 보장합니다. 

 

   

     1. 서버는 공개키/개인키를 만들어 신뢰할 수 있는 인증 기관(CA)과 계약해 자신의 정보와 공개키 관리를 맡깁니다.

     2.  인증 기관에는 자신들의 공개키/개인키가 존재하는데 인증 기관 개인키로 서버가 전달한 정보를 암호화해
          인증서를 만들어 제공합니다. 

     3. 서버는 CA로부터 인증서를 발급받으며 이후 인증 기관은 웹 브라우저에 자신의 공개키를 제공합니다.

 

 

 

 

    4. 사용자가 서버에 접속하면 서버는 자신의 인증서를 클라이언트에게 전송합니다.

    5. 웹 브라우저는 이전에 전송받은 인증기관의 공개키로 인증서를 해독/검증해서 서버의 정보와 서버의 공개키를

        알아냅니다.

    6. 이렇게 얻은 서버의 공개키를 대칭키를 암호화해 다시 사이트에 보내고, 서버는 서버 개인키로 암호문을 해독해
         대칭키를 얻어 데이터를 전송할 수 있게 됩니다. 

 

그림이 안맞을 수 있는데 4번에 해당하는 내용이 왼쪽 그림의 1번 단계(서버에 접속) 입니다. **그림은 추가로 그려서 넣을 예정

 

 

 

 

 

여기서 추가로 고민해볼 사항이 있는데요, 브라우저가 어떻게 CA의 공개키를 알 수 있는지입니다. 이 부분에 대해서는 아래 글들을 참조하실 것을 권장드립니다.

 

How browser come to know that SSL certificate provided by server is signed by CA?

 

 

 

 

 

 

3. Conclusion

---

HTTPS에 대한 개념에 대해 간략하게 정리해봤는데요, 프로젝트에 이를 적용했던 이유는 보안관련사항을 체크하다 내 패킷을 상대방이 가로챌 수 있다는 것을 알게되었기 때문입니다. 우리가 데이터를 전송할때 패킷들은 여러 노드(라우터)들을 거쳐가게 되는데 예를들어 네이버 서버에 접속하기 위해서는 아래와 같이 1부터 10까지의 여러 노드들을 거쳐서 가게됩니다. 

 

traceroute -w 1 www.naver.com 명령어를 통해 여러개의 노드를 거쳐 가는 것을 볼 수 있습니다.

 

 

 

 

 

이 과정에서 HTTPS가 적용되어있지 않으면 패킷들의 정보를 중간에서 볼 수 있습니다. 그 과정들은 해당 블로그에 정리되어 있는데요, 여튼 와이어샤크와 같은 패킷분석툴을 통해 우리들의 데이터를 읽을 수 있기 때문에 이를 방지하고 싶어 적용하게 되었습니다. **보안은 전문 분야이고 이 부분만 평생 다루시는 분들(화이트/블랙 해커)이 계시기 때문에 HTTPS를 단순히 적용했다고 모든 보안 요소들이 해결되지 않습니다. 다만 최소한의 안전성을 획득할 수 있다 정도로 이해하시면 될 것 같습니다.

 

출처 https://hiseon.me/network/decrypt-ssl-traffic/

 

 

 

 

HTTPS가 적용되어 있으면 무조건 좋냐? 라는 생각을 할 수 있는데 또 그렇지는 않습니다. HTTPS의 경우 HTTP보다 상대적으로 느리기 때문인데요, 상대방이 봐도 상관없는 단순 조회의 경우에는 굳이 HTTPS를 적용할 필요가 없습니다. 따라서 무조건 HTTPS가 좋지는 않으며 같은 망 내에서 요청하는 정보, (어드민 관련 정보가 아닌)단순한 정보요청의 경우에는 HTTP를 사용하고 보안이 필요한 경우에 HTTPS를 사용하면 될 것 같습니다. 긴 글 읽어주셔서 감사합니다.