Post

[네트워크] 응용 계층(Application) - HTTP와 HTTPS (SSL/TLS)

Posted
By Ennik 19 min read

HTTP의 기본 개념

  • HTTP(HyperText Transfer Protocol)는 웹에서 정보를 교환하는 데 사용되는 애플리케이션 계층 프로토콜이다.
  • 이 프로토콜은 웹 브라우저(클라이언트)와 웹 서버 간의 통신을 가능하게 하며, HTML 문서나 이미지와 같은 리소스를 요청하고 전송받는 데 사용된다.
  • 하이퍼텍스트(Hypertext): 노드(node)와 링크(link)를 통해 웹 상의 다른 문서나 멀티미디어 등으로 이동할 수 있도록 구조화 되어 있는 텍스트
  • 데이터를 암호화하지 않고, 통신 상대방을 확인하지 않기 때문에 보안에 취약하다.
  • 상태 비저장성(Statelessness)
    • HTTP는 상태를 유지하지 않는 프로토콜이다. 즉, 이전 통신과의 연속성을 유지하지 않는다.
    • 서버는 클라이언트의 이전 요청을 기억하지 않고, 각 요청을 독립적인 트랜잭션으로 처리한다.
    • 이를 해결하기 위해 쿠키, 세션과 같은 기술을 사용한다.
  • 클라이언트-서버 모델
    • 클라이언트는 서버에 리소스 요청을 보내고, 서버는 그 요청에 응답한다.
    • 클라이언트는 주로 웹 브라우저이며, 서버는 웹 사이트를 호스팅하는 컴퓨터이다.

HTTP의 메소드

HTTP 프로토콜은 다음과 같은 다양한 메소드를 지원한다.

  1. GET: 서버에서 특정 리소스를 요청한다. 데이터를 검색하는 데 사용되며, 데이터를 수정하지 않는다.
  2. POST: 서버로 데이터를 전송하여 리소스를 생성한다. 폼 데이터 제출이나 파일 업로드 시 사용된다.
  3. PUT: 지정된 URI에 리소스를 생성하거나, 이미 존재하는 경우 그 리소스를 대체한다.
  4. DELETE: 지정된 URI의 리소스를 삭제한다.
  5. HEAD: GET과 유사하지만, 응답 본문 없이 HTTP 헤더 정보만을 반환한다. 리소스의 메타데이터를 검사하는 데 유용하다.
  6. OPTIONS: 대상 리소스에 대해 통신 옵션을 설명하는 데 사용된다.

HTTPS (HTTP Secure)

  • HTTPS는 SSL 또는 TLS 프로토콜을 사용하여 HTTP 통신을 암호화하는 확장된 프로토콜이다.
  • 데이터를 암호화하여 전송하기 때문에, 데이터의 기밀성과 무결성을 보장한다.
    • 무결성: 데이터가 정확하고 완전한 상태로 유지되며, 의도치 않은 방식으로 변경되거나 손상되지 않음
  • 또한, HTTPS는 서버의 신원을 인증하고, 사용자가 접속하려는 서버가 실제 의도한 서버임을 보증한다.

SSL(Secure Sockets Layer)과 TLS(Transport Layer Security)

  • SSL과 TLS는 데이터를 안전하게 전송하기 위해 네트워크 통신에 암호화를 추가하는 프로토콜이다.
  • 데이터 암호화, 데이터 무결성 검증, 그리고 서버 인증을 제공한다.
  • TLS는 SSL의 개선된 버전으로, 현재 인터넷 보안 통신의 표준으로 널리 사용된다.

SSL → TLS 개선점

  1. 암호화 알고리즘 강화

    • 더 강력한 암호화 알고리즘 지원: TLS는 더 안전한 암호화 알고리즘과 키 교환 메커니즘을 지원한다. 예를 들어, TLS 1.2는 AES (Advanced Encryption Standard)와 같은 현대적 암호화 기술을 사용한다.
    • SHA-256 지원: TLS 1.2부터는 SHA-256과 같은 강력한 해시 함수를 사용하여 데이터의 무결성을 보장한다. 이는 SSL에서 사용되던 MD5와 SHA-1에 비해 훨씬 더 강력하고 안전하다.

  2. 보안 취약점 해결

    • POODLE과 같은 공격 방지: SSL 3.0은 POODLE(Padding Oracle On Downgraded Legacy Encryption) 공격에 취약했다. TLS는 이러한 취약점을 해결하여 보안을 강화했다.
    • 암호화된 알림 메시지: TLS에서는 모든 알림 메시지가 암호화되어 전송되므로, 중간자 공격으로부터 보호받을 수 있다.

  3. 프로토콜 유연성

    • 확장성: TLS 프로토콜은 확장 가능하도록 설계되어 향후 보안 요구사항 변화에 더 잘 대응할 수 있게 한다. 예를 들어, TLS 1.3은 이전 버전들보다 더 단순화되고 효율적인 핸드셰이크 과정을 제공한다.
    • 세션 재개 기능: TLS는 세션 티켓을 사용하여 이전에 협상된 세션을 빠르게 재개할 수 있는 기능을 제공함으로써 연결 설정 시간을 단축시키고 성능을 향상시킨다.

  4. 성능 향상

    • 핸드셰이크 최적화: TLS 1.3은 핸드셰이크 과정에서 라운드 트립을 줄여 네트워크 지연 시간을 최소화한다.

  5. 호환성과 표준화

    • 표준화된 프로토콜: TLS는 IETF(Internet Engineering Task Force)에 의해 공식적으로 표준화된 프로토콜로, 넓은 범위의 애플리케이션과 시스템에서 널리 지원되고 호환될 수 있다.

HTTPS 연결에서의 CA와 SSL/TLS의 역할

  1. 인증서 발급: 웹 서버 운영자는 CA에 인증서 발급을 요청한다. CA는 요청을 검증한 후, 유효한 요청으로 판단되면 디지털 인증서를 발급한다.
    • CA(Certificate Authority): 디지털 인증서를 발급하고 관리하는 기관이다. 개인 키와 공개 키가 포함된 인증서를 발급하여, 웹 서버나 다른 엔터티의 신원을 인증한다. 디지털 인증서는 서버의 신원 정보, 공개 키, 발급 기관, 유효 기간 등을 포함한다. 웹 브라우저와 같은 클라이언트는 이 인증서를 받아서 서버의 신원을 검증하고, 이후의 암호화된 통신에 서버의 공개 키를 사용한다.
  2. HTTPS 연결 설정: 클라이언트(웹 브라우저)가 HTTPS를 통해 웹 서버에 접속할 때, 서버는 자신의 디지털 인증서를 클라이언트에게 제공한다.
  3. 인증서 검증: 클라이언트는 받은 인증서를 검증하여 서버의 신원을 확인한다. 이 과정은 CA의 신뢰성에 기반하며, 클라이언트 시스템에 사전에 설치된 CA의 루트 인증서를 사용하여 이루어진다.
  4. 암호화 통신: 인증서가 유효하면, 클라이언트와 서버는 SSL/TLS 프로토콜을 사용하여 암호화된 통신 채널을 설정하고, 이 채널을 통해 데이터가 안전하게 교환된다.

TLS HandShake

  • 데이터를 주고 받기 전, 서버의 무결성을 확인하고 대칭키를 전달하는 과정이 TLS Handshake이다.

  • 사용자가 TLS를 사용하는 웹사이트를 접속하면 클라이언트와 웹 서버간에 TLS Handshake가 시작된다.

    • TLS 핸드셰이크 과정은 세션을 처음 시작할 때 또는 기존 세션이 만료되었을 때 일어난다.
    • 한 번 세션이 설정되고 나면, 그 세션의 유효 기간 동안 추가적인 핸드셰이크 없이 데이터 통신이 계속 이루어진다.
  • TLS Handshake를 하는 동안 클라이언트와 웹 서버는 아래 일을 수행한다.
    • 사용할 TLS 버전 지정
    • 사용할 암호 제품군 결정 - 공유된 암호화 키 또는 세션 키와 같은 세부 정보를 명시하는 알고리즘 집합
    • 서버의 TLS 인증서를 사용하여 서버의 신원을 인증
    • Handshake가 완료된 후 메시지를 암호화하기 위한 세션 키 생성

  • 구체적인 핸드셰이크 과정은 다음과 같다.

    1. Client : Client Hello

      • 클라이언트가 서버에서 Client Hello 메시지 전송
      • Client Hello 메시지의 구성 요소:
        • TLS Version: 클라이언트가 지원하는 TLS 프로토콜의 버전
        • 암호화 방식: 클라이언트가 지원하는 암호화 스위트 목록
        • 암호화 스위트: 데이터 암호화, 키 교환, 메시지 인증 등을 위해 사용되는 암호화 알고리즘과 프로토콜
        • Client Random Data: 클라이언트에서 생성한 난수로, 마스터 세션 키를 도출하는 데 사용된다.
        • Session ID: 이전에 수립된 세션을 재활용하기 위한 식별자로, 세션 재개 기능을 통해 클라이언트와 서버는 이전 핸드셰이크에서 협상된 매개변수를 재사용할 수 있으며, 세션 ID를 통해 이를 식별한다.
        • 초기 연결: 첫 번째 핸드셰이크에서는 일반적으로 Session ID가 비어 있다(또는 0으로 설정).
        • 세션 재개: 핸드셰이크를 성공적으로 완료한 후 서버는 클라이언트에게 Session ID를 할당하는데, 클라이언트는 이 ID를 로컬에 저장하고 다음 연결 시 이 Session ID를 포함하여 서버에 전송한다.
        • 서버의 응답: 서버가 저장된 Session ID를 인식하고 해당 세션이 여전히 유효하다고 판단되면, 같은 Session ID를 사용하여 세션 재개를 승인하고 전체 핸드셰이크 과정을 생략할 수 있다.
        • SNI (Server Name Indication): 클라이언트가 연결하고자 하는 서버의 이름으로 하나의 서버 또는 IP 주소에 여러 도메인이 호스팅될 때 유용하며, 서버가 적절한 인증서를 클라이언트에게 제시할 수 있도록 한다.

    2. Server : Server Hello

      • 클라이언트가 보낸 Client Hello에 대한 서버의 응답이다.
      • TLS Version, 암호화 방식(Client가 보낸 암호화 방식 중에 서버가 사용 가능한 암호화 방식을 선택), Server Random Data(서버에서 생성한 난수, 대칭키를 만들 때 사용), SessionID(유효한 Session ID)

    3. Server : Server Certificate

      • 서버의 인증서를 클라이언트에게 보내는 단계로 필요에 따라 CA의 Certificate도 함께 전송한다.
      • 클라이언트는 이 패킷을 통해 서버의 인증서가 무결한지 검증한다.

    4. Server :  Server Hello Done

      • 서버가 클라이언트에게 보낼 메시지를 모두 보냈다는 뜻

    5. Client : Client Key Exchange

      • 클라이언트는 pre-master secret을 생성하고 서버의 공개키로 암호화하여 서버에 전송한다.
        • pre-master secret: 키 교환에 필요한 정보로 난수를 조합하여 만들어진다.

    6. Server : Pre-master Secret 복호화

      • 서버는 자신의 개인키로 클라언트가 보낸 pre-master secret을 복호화한다.

    7. Server & Client : Master Session Key 생성

      • 클라이언트와 서버는 클라이언트의 난수와 서버의 난수를 조합하여 마스터 세션 키를 생성한다.
        • 클라이언트와 서버의 난수(클라이언트 랜덤, 서버 랜덤)은 가장 초기의 Hello 단계에서 교환된다.
      • 이 마스터 세션 키는 대칭키로 통신의 모든 데이터를 암호화 및 복호화하는 데 사용된다.
        • 대칭키: 암호화와 복호화에 동일한 키를 사용하는 암호화 방식

    8. Server & Client : Change Cipher Spec

      • 클라이언트와 서버는 Change Cipher Spec 메시지를 보내 서로에게 새로운 세션 키가 적용될 준비가 되었음을 알린다.
      • Cipher Spec은 “암호화 규격”을 의미한다.

    9. Client : Finished

      • 클라이언트는 모든 핸드셰이크 메시지의 해시를 포함한 ‘Finished’ 메시지를 보내어 핸드셰이크 과정을 완료한다.

    10. Server : Finished

      • 서버는 클라이언트의 Finished 메시지를 검증하고, 성공적이라면 자신의 Finished 메시지를 클라이언트에게 전송한다.
      • 이 단계에서 양쪽 모두 핸드셰이크가 성공적으로 완료되었음을 확인한다.

HTTP와 HTTPS의 차이점

  • 보안: HTTPS는 HTTP에 비해 높은 보안을 제공합니다. HTTPS는 데이터를 암호화하고, 서버의 신원을 검증하여 보안 연결을 구축합니다.
  • 포트 번호: 일반적으로 HTTP는 포트 80을 사용하고, HTTPS는 포트 443을 사용합니다.
  • 성능: HTTPS는 암호화 및 복호화 과정으로 인해 HTTP보다 약간 느릴 수 있으나, 최근의 기술 발전으로 이 차이는 점점 줄어들고 있습니다.

HTTP & HTTPS 포트 번호

  • 포트 80: HTTP 통신을 위한 기본 포트로, 암호화되지 않은 표준 HTTP 요청이 이 포트를 사용하여 서버와 통신한다.
  • 포트 443: HTTPS(암호화된 HTTP) 통신에 사용된다. HTTPS는 SSL 또는 TLS를 사용하여 데이터를 암호화한다.

References

0.2 네트워크
Network Application Layer
This post is licensed under CC BY 4.0 by the author.