본문 바로가기
3학년 학사/네트워크 보안

[네트워크 보안] #9. TLS, HTTPS, SSH

by whiteTommy 2024. 12. 4.
반응형
더보기

목차

  • TLS
  • HTTP
  • SSH

 

예상 문제

  • TLS 레코드 프로토콜 동작과정
  • HandShake 프로토콜 4단계
    • 필수 사항이 아닌것? (5개)
      • 2단계에서 certificate, server_key_exchange, certificate_request
      • 3단계에서 cerfificate, certificate_verify
  • 호스트키 신뢰 방식 (신뢰모델 2가지) 과 장단점
    • 신뢰모델 1 : 클라이언트가 관리하는 호스트 공개키 로컬 데이터 베이스
    • 신뢰모델 2 : PKI

 

 

TCP / IP 에서 보안 기능의 위치

  • 네트워크 계층: 기본적인 데이터 전송(HTTP, FTP 등).
  • 전송 계층: TLS와 같은 보안 프로토콜이 동작.
  • 응용 계층: SMTP 같은 애플리케이션에서 보안 통합 가능.

 

TLS (Transport Layer Security)

  • 특징
    • 가장 널리 사용하는 보안 서비스 중 하나
    • 현재 버전 1.3 (RFC 8446) 에 정의
    • 인터넷 표준
    • 상업용 프로토콜인 SSL(Secure Sockets Layer) 로부터 진화
      • SSL 을 아직도 사용하고 있음
      • 그러나, IETF 에서 사용 중지 선언
      • 대부분의 기업에서는 TLS 로 대체
  • 주요 기능
    • 데이터 암호화 
    • 무결성 보장

 

TLS 구조

  • 프로토콜 계층 구성 (두 계층)
    • 상위 프로토콜 : 상호인증, 키 교환
    • 레코드 프로토콜 : MAC, 암호화
  • TLS 프로토콜 스택
    • 데이터 흐름은 IP 와 TCP 위에서 동작, HTTP, SMTP 등 응용 계층 프로토콜과 결합됨

 

 

TLS 개념

  • 세션 (Session)
    • 한 클라이언트와 한 서버 사이의 association
    • 세션 시작은 Handshake 프로토콜 이용
    • 세션 시 암호적 보안 매개변수 정의
    • 세션으로 인해 매 연결 시 보안매개변수 협상 새로 하지 않음
      • 종료되어도 동일 세션 매개변수 사용할 수 있음
    • 여러 개의 연결에 걸쳐 사용될 수 있음
      • 동일한 세션을 재사용할 수 있음. 즉, Handshake 없이도 빠르게 연결 재설정 가능
  • 연결 (Connection) : 암호화 단위
    • 암호키 사용단위
    • Peer-peer 관계
    • 일시적
    • 한 개의 세션 매개변수를 이용

 

세션 상태 (Session State) 매개변수

  • 세션 식별자 (Session Identifier)
    • 활동 상태나 재시작할 수 있는 세션 상태를 나타내기 위해 서버가 선택하는 임의의 바이트 열
  • 대등 인증서 (Peer Certificate)
    • 대등의 x509.v3 인증서. 
    • 이 요소의 상태는 비어 (null) 있을 수 있음
  • 압축 방법 (Compression method)
  • 암호 명세 (Cipher spec)
  • 마스터 비밀 (master secret)
  • 재시작 여부 (is resumable)

 

연결 상태 (Connection State) 매개변수

  • 서버와 클라이언트 랜덤 (Server and client Random)
    • 핸드셰이크 과정에서 사용되며, 최종 암호화 키(Master Secret) 생성에 기여.
    • 클라이언트는 핸드셰이크 시작 시 Client Hello 메시지에 난수를 포함.
    • 서버는 Server Hello 메시지에 자신의 난수를 포함.
  • 서버 기록 MAC 비밀 (Server write MAC secret)
  • 클라이언트 기록 MAC 비밀 (Client write MAC secret)
  • 서버 기록 키 (Server write key)
  • 클라이언트 기록 키 (Client write key)
  • 초기화 벡터 (Initialization vectors)
  • 순서 번호 (Sequence numbers)

 

TLS 레코드 프로토콜 동작

  1. 단편화 (Fragmentation)
    • 데이터를 $2^{14}$ 바이트 이하의 크기 블록으로 단편화
    • 블록 암호화 알고리즘의 크기에 맞는 작은 단위로 나누어 전송 효율성을 높임
  2. 압축 (Compression)
    • 데이터를 $2^{10}$ 바이트 이하로 압축하여 전송량을 줄일 수 있다
    • 압축 알고리즘을 자유롭게 선택 가능.
  3. MAC 계산
    • 무결성 보장을 위해 메시지 인증 코드(Message Authentication Code)를 생성.
    • HMAC 알고리즘을 사용하여 데이터를 변조 여부를 확인
      • HMAC_hash(MAC_write_secret, seq_num || TLSCompressed.type || TLSCompressed.version || TLSCompressed.length || TLSCompressed.fragment)
  4. 암호화 (대칭 암호)
    • 암호화된 메시지와 MAC을 다시 암호화하여 보안성을 극대화
    • 암호화 규칙
      • 암호화된 데이터 길이가 1024바이트를 초과하면 안 됨
      • 총 길이는 $2^{14}$ + 2048 바이트를 넘지 않도록 설계.
        블록 암호 스트림 암호
        알고리즘 키 길이 알고리즘 키 길이
        AES
        3DES        		 128, 256
        168        		 RC4-128 128
  5. SSL 레코드 헤더 붙이기
    1. 콘텐츠 유형
    2. 주 버전
    3. 부 버전
    4. 압축된 길이

 

 

TLS 레코드 프로토콜 페이로드 - 상위 프로토콜

  • 암호명세 변경 프로토콜
    • 구조: 단순히 1 바이트로 구성.
    • 역할:
      • 핸드셰이크 후, 클라이언트와 서버가 새 암호 도구(Cipher Suites)를 적용하기 위해 사용.
      • 암호화 전환을 알리는 신호로 작동.
  • 경고 프로토콜
    • 대등 객체에게 SSL-관련 경고
    • 구조: 2바이트로 구성.
      • 첫 번째 바이트: 경고의 심각도(Level)를 나타냄.
        • 1: 경고(Warning) : 연결을 끊지 않고, 경고 메시지만 전달
        • 2: 심각(Fatal) : SSL 은 즉시 연결을 단절 
      • 두 번째 바이트: 경고 코드(Alert Code)를 나타냄. (예: unexpected_message, bad_record_mac.)
  • 핸드셰이크 프로토콜
    • 구조:
      • Type (1 바이트): 메시지 유형.
      • Length (3 바이트): 메시지 길이.
      • Content (0 바이트 이상): 실제 데이터.
    • 역할: TLS 세션 설정 시, 인증서 교환, 암호화 알고리즘 협상, 키 교환 등을 수행.
  • 그 밖의 상위-계층 프로토콜 (예: HTTP)
    •  

 

1. 경고 프로토콜

항상 심각(Always Fatal) 경고

  • unexpected_message: 적절하지 않은 메시지를 수신했을 때 발생.
  • bad_record_mac: MAC 계산이 실패하여 데이터 무결성이 손상된 경우.
  • decompression_failure: 압축풀기 함수에 적합하지 않은 입력
  • handshake_failure:
    • 핸드셰이크 과정이 실패했을 때 발생
    • 보안 매개변수 집합을 송신자가 협상할 수 없음.
  • illegal_parameter: 핸드셰이크 메시지 안의 한 필드가 범위 밖에 있거나 다른 필드와 모순
  • decryption_failed: 부정확하게 복호화된 암호문
  • record_overflow:
    • TLS 레코드의 총 길이가 $2^{14} + 2048$ 를 초과했을 때 발생.
    • 복호화된 암호문의 길이가 $2^{14} + 2048$ 보다 길다
  • unknown_ca: 인증서를 발급한 인증 기관(CA)을 알 수 없거나 신뢰할 수 없는 경우.
  • access_denied: 인증서는 올바르지만, 접근통제로 인해 협상이 결렬된 경우
  • decode_error : 필드가 해당 영역을 벗어났거나 메시지의 길이가 달라서 복호화할 수 없는 경우
  • export_restriction : 키 길이 규제를 따르지 않는 협상인 경우
  • protocol_version: 프로토콜 버전이 지원되지 않는 경우
  • insufficient_security : 서버가 클라이언트에서 지원하는 암호보다 더 안전한 암호를 요구하는 경우
  • internal_error: 대등과 무관한 내부 오류나 올바른 프로토콜과는 무관한 오류

 

2. 핸드셰이크 프로토콜

  • 역할
    • 상호 인증: 클라이언트와 서버가 서로의 신뢰성을 검증.
    • 보안 설정:
      • 암호화 알고리즘(Cipher Suite) 협상.
      • TLS 버전 및 키 교환 방식 설정.
    • 암호화 키 생성:
      • 핸드셰이크를 통해 공유 암호화 키를 생성하여 데이터를 안전하게 전송.
        메시지 유형 매개 변수
        hello_request 없음(null)
        client_hello 버전(version), 랜덤(random), 세션id(session id), 암호 도구(cipher suite), 압축 방법(compression method)
        server_hello 버전(version), 랜덤(random), 세션id(session id), 암호 도구(cipher suite), 압축 방법(compression method)
        certificate 연속된 X.509v3 인증서 (chain of X.509v3 certificates)
        server_key_exchange 매개 변수(parameters), 서명(signature)
        certificate_request  유형(type), 기관(authorities)
        server_done 없음(null)
        certificate_verify 서명(signature)
        client_key_exchange 매개 변수(parameters), 서명(signature)
        finished 해시값(hash value)
  • 4단계
    1. 보안 기능 설정 : ClientHello와 ServerHello 메시지를 교환하여 암호화 알고리즘 및 TLS 버전을 협상.
    2. 서버 인증과 키 교환 : 서버는 자신의 인증서를 제공하고, 키 교환 방식을 협상.
    3. 클라이언트 인증과 키교환 : 클라이언트가 필요 시 자신의 인증서를 제공하고, Pre-Master Secret을 공유.
    4. 종료 : Finished 메시지를 교환하며 세션 키를 설정.

 

핸드셰이크 프로토콜 동작

  • 1단계 : 보안 기능 수집
    • 클라이언트 → 서버 (ClientHello)
      • 클라이언트는 ClientHello 메시지를 전송하며, 다음 정보를 포함:
        • 지원하는 프로토콜 버전 (예: TLS 1.2, 1.3).
        • 암호화 알고리즘 목록 (Cipher Suites): 클라이언트가 지원하는 암호화 알고리즘과 키 교환 방식.
        • 압축 방식 (현재는 사용되지 않음).
        • 클라이언트 랜덤 값 (Client Random): 세션 키 생성을 위한 난수 값.
    • 서버 → 클라이언트 (ServerHello)
      • 서버는 ServerHello 메시지를 전송하며, 다음 정보를 포함:
        • 선택된 암호화 알고리즘: 서버는 클라이언트가 제안한 목록 중 하나를 선택.
        • 서버 랜덤 값 (Server Random): 세션 키 생성을 위한 또 다른 난수 값.
  • 2단계 : 서버 인증 및 키 교환
    • 서버 → 클라이언트:
      1. Certificate:
        • 서버는 자신의 인증서를 전송하여 신뢰성을 증명.
        • 인증서에는 서버의 공개 키(Public Key)와 인증 기관(CA)의 서명이 포함.
      2. ServerKeyExchange: 키 교환을 위한 데이터를 전송 (예: Diffie-Hellman 파라미터).
      3. CertificateRequest : 서버는 클라이언트 인증을 요구할 수 있음.
      4. ServerHelloDone: 서버가 핸드셰이크의 이 단계를 완료했음을 알림.
  • 3단계 : 클라이언트 인증 및 키 교환
    • 클라이언트 → 서버:
      1. Certificate:
        • 클라이언트는 자신의 인증서를 서버에 전송 (서버가 요구한 경우).
      2. ClientKeyExchange: 클라이언트는 키 교환을 수행.
        (예: Pre-Master Secret을 서버의 공개 키로 암호화하여 전송.)
      3. CertificateVerify: 클라이언트는 서버에 자신의 인증서를 검증하는 메시지를 보냄.
  • 4단계 : 핸드셰이크 종료
    • 암호명세 교환 (Change Cipher Spec):
      • 클라이언트와 서버는 새로 협상된 암호화 알고리즘과 키를 활성화.
      • 이 메시지는 암호화가 시작될 준비가 되었음을 알림.
    • Finished:
      • 클라이언트와 서버는 Finished 메시지를 교환.
      • 암호화된 첫 번째 메시지로, 핸드셰이크가 성공적으로 완료되었음을 의미.
      • 핸드셰이크 동안 전송된 모든 메시지가 무결성을 유지했음을 보장.

 

마스터 시크릿 생성

  • 일회용 48 byte
    • TLS 프로토콜에서 보안을 위해 생성되는 일회용 값으로, master_secret 은 연결의 보안을 책임지는 중요한 요소
    • 이로 인해 session 키가 생성됨
    • 두 단계 생성
      • pre-master_secret 교환 (2가지 방법 가능)
        • RSA : 상대방 공개키로 암호화
        • Diffie-Hellman : 키 교환 프로토콜 사용
        • 이 과정에서 클라이언트와 서버는 난수를 활용하여 공동의 pre-master_secret 을 생성
      • master_secret 계산
        • master_secret = PRF(pre_master_secret, "master secret", ClientHello.random || ServerHello.random)

 

PRF (PseudoRandom Function)

  • 키를 확장하여 긴 데이터 블록을 생성
    • PRF(secret, label, seed) = P_<hash> (secret, label || seed)
    • P_<hash>는 특정 해시 함수 (예: SHA-256, MD5) 를 사용하여 데이터 스트림을 생성
    • PRF 는 입력값을 받아 여러 해시 계산을 반복적으로 수행하여 출력값을 생성.

 

연결계층 매개변수 

  • master secret 으로 부터 암호 매개변수 생성
    • Client write MAC secret: 클라이언트 데이터 무결성 확인에 사용.
    • Server write MAC secret: 서버 데이터 무결성 확인에 사용.
    • Client write key: 클라이언트 암호화 키.
    • Server write key: 서버 암호화 키.
    • Client write IV: 클라이언트 초기화 벡터.
    • Server write IV: 서버 초기화 벡터.

 

3. 하트비트 프로토콜

  • 하트비트 (heartbeat)
    • 시스템이 정상적으로 동작하고 있음을 나타내기 위해 주기적으로 생성하는 추가적 신호
    • HW 나 SW 에서 동기화를 유지하거나 작동 상태를 확인하는 데 사용
  • 하트비트 프로토콜 (heartbeat protocol)
    • 프로토콜 개체의 가용성을 모니터링할 때 사용

 

HTTPS

  • 정의
    • HTTP over SSL
      • 웹브라우저와 웹서버 간의 안정된 보안 통신 구현
      • 모든 웹브라우저에 내장
      • 모든 데이터가 암호화되어 안전하게 전송됨
  • 특징
    • URL 주소가 https:// 로 시작
    • 포트 번호
      • HTTP : 80 번 포트
      • HTTPS : 443 번 포트로 SSL 호출
  • 암호화 요소
    • 요청 문서 URL : 사용자가 요청한 특정 자원의 URL 자체.
    • 문서 내용 : 웹 페이지 내용.
    • 브라우저 사용자 입력 데이터 : 사용자 폼(form) 입력 값 및 브라우저가 생성한 데이터.
    • 쿠키 정보 : 브라우저에서 서버로 전송된 쿠키 또는 서버가 브라우저로 보낸 쿠키.
    • HTTP 헤더 내용 : 요청 및 응답 메시지의 메타정보.
  • 연결 개시
    • HTTP 클라이언트
      1. HTTP 클라이언트의 요청
        • 적절한 포트를 통해 서버에 연결을 시도.
      2. TLS 핸드셰이크 시작
        • 클라이언트는 TLS ClientHello를 전송하여 TLS 세션을 시작.
        • TLS 핸드셰이크가 완료되면 보안 연결이 설정됨.
      3. 첫 번째 HTTP 요청
        • TLS 연결 이후 클라이언트는 첫 HTTP 요청을 암호화된 데이터로 전송.
        • 모든 HTTP 데이터는 TLS를 통해 안전하게 암호화되어 전송
  • 연결 종료
    • HTTP 클라이언트 또는 서버에 의해 종료
      • HTTP 레코드 안에 Connection: close 를 추가하여 명시적으로 연결 종료 요청.
      • 이후 HTTP 통신이 종료됨.
    • TLS 가 원격 TLS와 연결 종료
      • TLS는 close_notify라는 프로토콜 메시지를 통해 세션 종료를 알림.
      • 하위 TCP 연결을 먼저 종료
  • 불완전 종료
    • 응답 없이 종료되는 경우
      • TLS 종료 메시지(close_notify)를 보내고 상대방이 종료 경보를 보낼때까지 기다리지 않고 연결 종료
    • 요청 없이 종료되는 경우
      • 하위 TCP 연결이 사전 close_notify 경보와 Connection: close 지시자 없이 종료되는 경우
        • 서버 측의 프로그래밍 오류.
        • TCP 연결 손실이나 네트워크 문제.
          • 모종의 공격, 보안 경고 발령 필요

 

SSH (Secure Shell)

  • 정의
    • 한 컴퓨터에서 다른 컴퓨터로 보안 원격 로그인을 위한 안전한 네트워크 통신용 프로토콜
    • 구현이 쉽고, 저비용으로 설계됨
    • 보다 일반적인 클라이언트 / 서버 기능 제공
    • 파일 전송, 전자메일 기능을 제공
    • SSH 클라이언트 / 서버 응용은 대부분의 OS 에서 광범위하게 수용
  • 스택 
    •  

1. SSH 전송 계층 프로토콜

 

  • Forward Secrecy
    • 서버 인증을 통해 데이터를 기밀성 있게 전송.
    • 데이터 기밀성과 무결성을 강화.
  • 전송 계층에서 옵션으로 압축이용 가능

  • 전송 계층 - 호스트 키
    • 정의
      • SSH 서버가 자신을 식별하기 위해 사용하는 고유한 암호화 키
      • 클라이언트가 SSH 서버에 연결할 때, 서버가 신뢰할 수 있는지 확인하는 중요한 인증 요소이다.
    • 서버 인증
      • 서버는 여러 개의 호스트 키를 가질 수 있음.
      • 동일한 호스트 키를 여러 호스트에서 공유할 수도 있음.
      • 모든 경우에 서버 호스트 키는 호스트 신원을 인증하기 위한 키 교환 시 사용
      • 클라이언트는 서버의 호스트 공개키를 사전에 알아야 함
    • 호스트 키 신뢰 방식
      • 신뢰 모델 1: 클라이언트가 관리하는 호스트 공개키 로컬 데이터베이스:
        • 장점 : 중앙집중식 기반구조나 제3의 조정기관 필요 없음
        • 단점 : 이름-키 쌍 데이터베이스 관리 부담
      • 신뢰 모델 2: PKI (Public Key Infrastructure):
        • 클라이언트는 오직 CA 공개키만 알고 있으며, CA 가 인증한 모든 호스트 키 검증 가능
        • 장점
          • 관리 문제를 완화 : 클라이언트는 오직 하나의 CA 키만 안전하게 저장하면 됨
        • 단점
          • 각 호스트 키는 인가 이전에 미리 CA 에서 인증서를 받아야 한다는 제약
  • 프로토콜 전송 과정

 

2. 사용자 인증 프로토콜

  • 목적 : 클라이언트의 신원을 확인하기 위한 단계
  • 메시지
    • C → S : 클라이언트가 인증 요청을 보냄 (SSH_MSG_USERAUTH_REQUEST)
    • S → C 
      • 인증 실패 시 (SSH_MSG_USERAUTH_FAILURE) // 재요청 필요
      • 인증 성공 시 (SSH_MSG_USERAUTH_SUCCESS)
  • 인증 방법
    • 공개키(publickey)
    • 패스워드(password)
    • 호스트 기반 인증(hostbased) 

 

3. 연결 프로토콜

  • 역할 : 논리적 다중 채널 (Logical Channels) 을 형성하여 데이터를 전송
  • 단계
    1. 채널 열기 : 클라이언트와 서버가 새로운 채널을 생성 (SSH_MSG_CHANNEL_OPEN)
    2. 데이터 전송 : 채널을 통해 데이터가 전송됨(SSH_MSG_CHANNEL_DATA)
    3. 채널 종료 : 사용이 끝난 채널은 종료됨 (SSH_MSG_CHANNEL_CLOSE)

반응형
저작자표시 비영리 변경금지

'3학년 2학기 학사 > 네트워크 보안' 카테고리의 다른 글

[네트워크 보안] #14. 웹 보안  (1) 2024.12.10
[네트워크 보안] # 13. 파이어월  (0) 2024.12.09
[네트워크 보안] # 12. 악성 코드  (1) 2024.12.09
b[네트워크 보안] # 11. 이메일, S/MIME  (0) 2024.12.06
[네트워크 보안] #10. VPN 실습  (0) 2024.12.05

관련글

티스토리툴바