[Network] SSL/TLS, 그리고 HTTPS

HTTPS(HyperText Transfer Protocol Secure)

 

전에 포스팅에서 HTTP 프로토콜에 대해 다루었다. HTTP는 데이터를 암호화하지 않으므로 네트워크 지식이 있는 사람이라면 누구나 패킷의 정보를 어렵지 않게 확인하고 위변조할 수 있다는 문제점이 있다. 심지어 패킷이 위변조 되었는지 알 방법도 없다. 패킷 정보 확인의 경우는 Wireshark라는 패킷 분석기를 통해 클라이언트와 서버 사이에서 주고받는 패킷을 쉽게 확인할 수 있다. 즉, HTTP의 문제점은 다음과 같다.

• 데이터가 암호화가 되어있지 않고 평문으로 되어있어서 제 3자가 패킷을 살펴볼 수 있다.
• 제 3자는 데이터를 악의적으로 위변조할 수 있다. 서로 데이터가 완전한지 확인하지를 않는다.
• 신뢰성있는 상대인지도 확인하지도 않는다.

이러한 문제를 해결하기 위한 필요조건은 다음과 같을 것이다.

• 데이터를 클라이언트와 서버끼리만 확인할 수 있도록, 데이터를 암호화할 것
• 서버의 신분을 확인할 수 있는 인증 과정을 거칠 것

그리고 이를 만족시키는 통신 프로토콜이 HTTPS이다. HTTPS는 HTTP에 TLS(SSL)를 적용한 프로토콜이다. 이를 통해 웹 브라우저와 서버 간의 데이터가 암호화되며, 인증 과정을 통해 서버의 신분을 확인할 수 있다.

 

HTTPS의 장점은 다음과 같다.

• 보안성: 암호화를 통해 데이터를 안전하게 전송한다.
• 신뢰성: 인증서를 통해 웹사이트의 신원을 확인할 수 있다.
• SEO 혜택: HTTPS를 사용하는 웹사이트는 검색엔진에서 더 높은 순위를 받을 가능성이 크다.
• 브라우저 경고 차단: HTTP를 사용하는 사이트는 브라우저에서 "안전하지 않음" 경고가 표시되지만, HTTPS는 이러한 문제를 피할 수 있다.

그럼 그 동작 방식을 자세하게 살펴보자! 이를 위해서는 SSL/TLS에 대해 알 필요가 있다.

---

SSL/TLS

SSL(Secure Sockets Layer)의 등장 배경과 역할

SSL은 인터넷 초기 시절, 네트워크 통신의 보안 문제를 해결하기 위해 개발된 프로토콜이다. 인터넷은 데이터를 평문으로 전송했기 때문에, 중간에 공격자가 데이터를 도청하거나 변조할 위험이 있었다. 이를 방지하기 위해 Netscape사가 1995년에 SSL을 개발했다.

• SSL의 역할
  • 클라이언트와 서버 간 데이터 암호화
  • 통신 상대방의 신원 인증
  • 데이터 무결성 보장
• SSL의 역사
  • SSL 1.0: 1994년에 개발되었지만, 심각한 보안 문제로 공개되지 않았다.
  • SSL 2.0: 1995년에 공개되었으나 취약점이 많아 빠르게 대체 필요성이 제기되었다.
  • SSL 3.0: 1996년에 등장하여 널리 사용되었지만, 이후 보안 취약점이 발견되었다.

SSL은 보안 강화라는 측면에서 큰 진전을 이루었지만, 보안상의 문제와 기술적 한계로 인해 더 발전된 프로토콜이 필요했다.

TLS(Transport Layer Security)의 등장과 SSL과의 관계

TLS는 SSL의 후속 프로토콜로, SSL의 문제점을 해결하고 더 강력한 보안을 제공하기 위해 1999년에 IETF(Internet Engineering Task Force)에 의해 표준화되었다. 사실상 TLS는 SSL의 발전된 버전이다.

• SSL vs. TLS
  • SSL은 사실상 더 이상 사용되지 않으며, 오늘날 SSL이라고 불리는 대부분의 보안 기술은 실제로는 TLS다.
  • TLS 1.0은 SSL 3.0을 기반으로 설계되었지만, 더 안전한 암호화 방식과 프로토콜 개선을 도입했다.
  • 최신 버전은 TLS 1.3(2018년 발표)으로, 성능과 보안을 대폭 개선했다.
• TLS의 주요 차이점
  • 더 강력한 암호화 알고리즘 지원
  • 보안 취약점 개선(예: SSL의 CBC 취약점 해결)
  • 핸드셰이크 과정 최적화로 성능 향상

 

 

TLS가 Transport Layer Secure를 의미하는 것에서 알 수 있듯이, TLS는 Transport Layer와 연관이 깊다. 웹은 Transport layer로 TCP를 사용하므로 TCP와 밀접한 연관이 있다.

 

일반적으로 HTTP 통신은 TCP로 3-way handshake를 해서 연결을 만든 직후 바로 시작된다. 연결이 완성되면 그 위에서 바로 HTTP 통신을 한다. 반면 HTTPS는 HTTP와 TCP 사이에 TLS라는 보안 레이어를 거친 후에 HTTP통신을 하는 형태이다.

 

이제부터 TLS라는 보안 레이어의 동작 방식에 대해 알아볼 것이다. 하지만, 그 전에 꼭 알아야 하는 개념들에 대해 먼저 알아보자..!

---

TLS 이해를 위한 사전 개념

암호화 & 복호화

• 암호화: 데이터를 보호하기 위해 원래의 내용을 특정 알고리즘을 사용해 변환하는 과정이다. 이를 통해 데이터는 외부에서 읽을 수 없는 형태로 변환된다. 암호화의 목적은 데이터를 안전하게 전송하거나 저장하는 것이다.
  • 대칭키 암호화: 암호화와 복호화에 같은 키를 사용한다. 예: DES, AES
    • 대칭키는 만들기 쉽고 빠르다는 장점이 있다. 하지만 키를 안전하게 전달하기 힘들다는 단점이 있다.
  • 비대칭키 암호화: 공개키(public key)와 개인키(private key) 두 개의 키를 사용한다. 공개키로 암호화한 데이터는 개인키로만 복호화할 수 있고, 개인키로 암호화한 데이터는 개인키로만 복호화할 수 있다. 예: RSA
    • 대개 자신만 비밀스럽게 알고있는 개인키(private key)를 만들고, 그 개인키를 바탕으로 특정한 알고리즘을 이용하여 공개키(public key)를 만들고 나서 각각 암호화나 복호화에 사용한다
    • A가 자신의 개인키로 암호화한 것을 B가 복호화함으로서 B는 A의 신원을 확인할 수 있다. -> '디지털 서명' 개념
• 복호화: 암호화된 데이터를 원래의 형태로 되돌리는 과정이다. 암호화된 데이터를 읽으려면 암호화에 사용된 키와 알고리즘을 알아야 한다. 암호화와 복호화는 보안의 핵심이며, 서로 반대되는 과정이다.

디지털 서명 & CA & 인증서

• 디지털 서명(digital signature): 네트워크에서 송신자의 신원을 증명하는 방법으로, 송신자가 자신의 개인키로 암호화한 메시지를 수신자가 송신자의 공개키로 해독하는 과정이다.
• CA(Certificate Authority) & 인증서(Certificate): 쉽게 서버들의 신원을 관리하는 인증 기관. 클라이언트의 입장에서 내가 통신하려는 서버가 신뢰할 만한 대상인지 알 수 있는 방법을 CA가 제공한다.
  • 서버 측에서 CA에 자신의 신원을 제출하면, CA가 이를 검증한 뒤에 자신의 전자서명이 들어간(즉 CA의 개인키로 암호화한 내용이 들어간) '인증서'를 서버 측에 건네준다. 일종의 신분증인셈이다.
  • 인증서에 들어가는 내용
    • 인증서 소유자의 정보(도메인 이름, 소유자 이름 등)
    • 인증서를 발급한 CA의 정보
    • 유효기간
    • 서버의 공개키(public key) (중요)
    • 서버의 랜덤생성 데이터 (중요)
    • CA의 디지털 서명(CA의 개인키로 암호화된 내용) (중요)
  • 그리고 서버는 이 인증서를 클라이언트에게 전달(신원 보장을 위해 신분증을 보여줌)해준다. 클라이언트의 웹브라우저에는 유명한 CA의 목록과 그 공개키를 가지고 있는데, 이것을 이용하여 인증서를 복호화해본다. 그리고 복호화가 정말로 완료되면 서버가 신뢰할 수 있는 대상임을 알 수 있게 된다.

---

SSL/TLS 동작 과정 (TLS 1.2 Handshake)

TLS 동작 과정은 버전에 따라 다르다. 최신 버전인 TLS 1.3에서는 보안성과 성능을 강화하기 위해 핸드셰이크 과정이 단순화되었다. 많은 메시지가 제거되거나 병합되었으며, 초기부터 모든 메시지가 암호화된다. 여기서는 기반이 되는 TLS 1.2 버전에서의 핸드셰이크 과정을 살펴보겠다!

 

1. ClientHello: 클라이언트(예: 웹 브라우저)가 서버에 연결 요청을 보내며, 다음 정보를 전달한다.
   • TLS 버전: 사용할 수 있는 TLS 프로토콜 버전(예: TLS 1.2, TLS 1.3).
   • 암호화 스위트(Cipher Suites): 클라이언트가 지원하는 암호화 알고리즘 목록(예: AES, RSA) -> (중요)
   • 난수(Random Number): 클라이언트가 자신이 생성한 랜덤데이터 -> (중요)
   • 확장 필드: 추가 정보(예: 서버 이름 표시(Server Name Indication, SNI))
2. ServerHello: 서버가 클라이언트에게 보내는 메시지로, 서버는 클라이언트의 "ClientHello" 메시지에서 자신이 사용할 암호화 & 압축 방식 목록 등을 확인한다. 이 후 다음과 같은 데이터를 보낸다.
   • TLS 버전 선택: 서버가 사용할 TLS 프로토콜 버전을 선택
   • 암호화 스위트 선택: 클라이언트가 제공한 목록 중 하나를 선택
   • 난수(Random Number): 보안 세션을 위해 생성한 서버 측 난수
   • 세션 ID
   • 확장 필드: 추가 정보
3. Certificate
   • 서버는 자신의 디지털 인증서를 클라이언트에 전달한다. 이 인증서는 서버의 공개키(Public Key)와 서버의 신원을 증명하는 정보(도메인 이름, CA의 서명 등)를 포함한다.
   • 클라이언트는 이 인증서를 검증하여 서버의 신뢰성을 확인한다.
4. ServerKeyExchange (필요한 경우)
   • 일부 암호화 스위트(특히 Diffie-Hellman 또는 ECDHE 기반 암호화)에서는 서버 측 키 교환 정보를 추가로 제공해야 한다
     • 예: 서버가 공개키를 클라이언트와 공유하거나, Diffie-Hellman 파라미터를 전송.
   • RSA 기반 키 교환에서는 이 단계가 필요하지 않다(인증서에 공개키가 포함되기 때문)
5. ServerHelloDone: 서버가 ServerHello, Certificate, ServerKeyExchange 메시지를 전송한 뒤, 클라이언트에게 작업이 완료되었음을 알리는 메시지를 보낸다. 여기까지 완료하면 클라이언트와 서버는 서로의 신원을 확인할 수 있다. 이제 남은 것은 클라이언트와 서버간의 암호화된 통신을 할 준비를 하는 것이다.
6. Client Key Exchange: 클라이언트가 서버와 세션 키를 공유하기 위한 메시지로, 선택된 키 교환 방식에 따라 동작이 달라진다.
   • RSA 키 교환
     • 클라이언트는 앞서 주고받은 '난수'값을 조합해 Premaster Secret를 생성하고 이를 서버의 공개키를 통해 암호화한다. 이후 이를 ClientKeyExchange 메시지에 포함해 서버에 전송한다.
     • 서버는 자신의 개인키를 사용해 Premaster Secret을 복호화한다.
     • 클라이언트와 서버는 Premaster Secret을 기반으로 세션 키를 생성한다.
   • Diffie-Hellman 또는 ECDHE
     • 클라이언트는 자신이 생성한 Diffie-Hellman(ECDHE) 공개키를 ClientKeyExchange 메시지에 포함해 서버로 전송한다.
     • 서버는 자신의 개인키와 클라이언트의 공개키를 사용해 동일한 세션 키를 생성한다.
7. Change Cipher Spec: 핸드셰이크 중 클라이언트와 서버가 이제부터 암호화된 데이터 전송을 시작한다고 알리는 신호 메시지로, 이전까지는 핸드셰이크 메시지가 평문으로 전송되었으나, 이 메시지를 보낸 뒤부터는 세션 키를 사용한 암호화 통신이 시작된다.
8. Encrypted Handshake Message (Finished Message): 핸드셰이크 과정의 마지막 단계에서 완전성을 확인하기 위한 메시지로, 클라이언트와 서버는 Finished 메시지를 서로 주고받으며, 핸드셰이크 과정이 성공적으로 완료되었음을 확인한다. 세부 동작은 다음과 같다.
   • 클라이언트는 Finished 메시지를 생성하고, 이를 세션 키로 암호화하여 서버로 전송한다.
   • 서버는 이 메시지를 복호화한 뒤, 자체적으로 동일한 값인지 확인한다.
   • 서버 역시 자신의 Finished 메시지를 생성하여 클라이언트에 암호화된 형태로 전송한다.
   • 클라이언트는 서버의 메시지를 복호화하여 확인한다.

TLS에서 세션키를 만들어 사용하는 이유

'Clienet Key Exchange' 과정에서 비대칭키만을 사용하지 않고, Premaster Secret를 굳이 만들고 세션키를 만드는 이유가 뭘까?

 

간단하게는 '대칭키 암호화와 공개키 암호화의 특성을 조화롭게 활용해 성능과 보안을 동시에 충족시키기 위해서'이다. 세션키는 대칭키 암호화의 키이며, TLS에서 클라이언트와 서버 간 안전한 통신을 위해 생성된다. 이를 사용하는 이유는 다음과 같다.

• 성능 최적화
  • 공개키 암호화는 계산 복잡도가 높아 대량의 데이터를 처리하기에 비효율적이다.
  • 대칭키 암호화는 훨씬 빠르기 때문에, 세션이 설정된 후에는 이를 사용해 데이터를 효율적으로 암호화/복호화한다.
• 초기 키 교환의 안전성
  • 세션키를 공유하기 위해 TLS에서는 공개키 암호화를 사용한다. 즉, 세션키를 공개키로 암호화해 교환하므로, 키 교환 과정이 도청이나 탈취로부터 안전하다.
  • 이후에는 세션키를 사용해 대칭키 암호화 방식으로 통신한다.
• 키 관리의 간소화
  • 세션키는 임시적으로 사용되는 키다.
    • 새로운 세션마다 새로 생성되므로, 키가 오래 사용될수록 발생할 수 있는 보안 문제를 방지한다.
    • 한 세션에서 사용된 키가 탈취되더라도, 다른 세션에는 영향을 미치지 않는다.

핸드셰이크가 완료되면, 클라이언트와 서버는 세션 키를 사용해 대칭키 암호화를 통해 안전하게 데이터를 주고받는다. 이후 통신은 빠르고 안전하게 진행된다.