보안/study

SSL/TLS 통신과정 정리

iiliiiili 2019. 12. 11. 14:08

SSL/TLS 란 ?

  • 클라이언트/서버 환경에서 TCP 기반의 Application에 대한 종단간(End-TO-End) 보안서비스를 제공하기 위해 만들어진 전송계층 보안 프로토콜이다.
  • SSL 통신은 http가 아닌 https라는 통신채널을 사용하며, 모든 웹서버와 웹브라우저가 SSL을 지원한다.
  • SSL은 서버인증(Server Authentication), 클라이언트 인증(Client Authentication) 그리고 데이터 암호화(Data Encryption) 기능을 제공한다.
  • 네스케이프에 의해서 SSL(Secure Socket Layer)이 발명되었고, 이것이 점차 폭넓게 사용되다가 표준화 기구인 IETF의 관리로 변경되면서 TLS(Transfer Layer Security)라는 이름으로 바뀌었다.

SSL/TLS 주요기능

신원확인

  • SSL 서버 인증서는 회사에 대한 방문조사 후 발급되기 때문에 고객들은 서버 인증서를 확인하여 회사의 웹 사이트가 실제로 존재하고, 회사의 소유임을 확인할 수 있다. 이것을 통해 고객은 안심하고 자신의 개인정보를 입력할 수 있다.

메시지의 비밀보장

  • SSL로 회상의 웹 서버와 고객과 교환된 정보(신용카드 번호 등)를 하나의 Session 키로 암호화한다.
  • 이 Session 키를 안전하게 고객에게 전달하기 위해서는 회사의 공개키로 암호화하여 보낸다. 하나의 Session 키는 한번만 사용된다.
  • 그리고 각 Session에 한 고객에게 하나의 키가 사용된다. 따라서 권한이 없는 제3자는 전송되는 과정에서 정보를 가로채어 볼 수 없다.

메시지의 무결성

  • 메시지가 전송될 때, 메시지의 내용에 따라 수신자와 발신자의 컴퓨터에서 암호 방식을 생성한다.
  • 한 글자라도 전송 중에 수정되어지면 수신받은 컴퓨터에서 다른 암호방식을 생성하여 수신자에게 경고 메시지가 보내집니다.
  • 메시지의 무결성으로 두 당사자가 서로에게 보내주는 메시지가 그대로 전달되었음을 알 수 있다.

SSL 대칭키와 공개키 (PKI)

  • 대칭키로 문서(데이터) 암호화, 복호화를 하려면 키 배송 문제가 있고(MITM 공격), 공개키로 문서 암호화, 복호화를 하려니 성능 문제가 있다.
  • SSL은 대칭키로 전송되는 문서(데이터) 암호화를 하고, 대칭키를 공개키기법으로 암호화하여 전송하는 방법을 사용한다.
  • 공개키(비대칭키) : 신뢰할 수 있는 인증서인지 확인(서버는 인증서 비밀키로 암호화, 클라이언트는 인증서의 공개키로 복호화), 대칭키를 공개키로 암호화 하여 전송한다. 
  • 대칭키(세션키) :  실제 클라이언트와 서버가 주고받는 내용을 암호화. 세션이 종료되면 대칭키도 폐기한다.
  • 인증서의 공개키로 상호 인증하고, 대칭키를 공개키로 암호화하여 주고 받고 이후 연결에는 주고받은 대칭키로 데이터를 암호화하여 전송한다.

SSL/TLS 통신과정

HTTPS 통신시 TCP 핸드세이크 후 아래처럼 SSL/TLS 핸드세이크를 진행한다.

출처 https://www.researchgate.net/figure/TLS-handshake-protocol_fig1_298065605

 

 

TLS 통신과정을 브라우저로 https://naver.com 을 접속했을 때의 패킷 내용을 보며 분석해보겠습니다.

pc에서 브라우저로 https://naver.com 을 접속했을 때의 통신과정

 

(1) client hello 

client hello 메시지는 세션 식별자, CipherSuite 리스트, 클라이언트가 지원하는 압축 알고리즘 리스트, 클라이언트 SSL 버전, 클라이언트가 생성한 난수를 서버에 전달한다.

  • Random : replay 공격을 막기 위한것, key_block 만들 때 사용 - 32 bit 난수 값(임의 난수 + timestamp) - 솔트값
  • session_id : 처음 세션 생성할 떄(full handshake, 완전 협상) - empty, 이미 세션 생성된 상태 재사용(abbreviate handshake, 단축 협상) - 재사용하고자 하는 세션의ID

Cipher Suites

  • 클라이언트가 본인이 사용할 수 있는 암호화 알고리즘 리스트를 보냄

Cipher suite 의 구조 

  • 프로토콜_키교환 알고리즘_인증서검증(인증)알고리즘_WITH_Cipher spec (ex TLS_RSA_WITH_AES_256_CBC_SHA256)
  • Cipher spec(암호명세) : 대칭 암호 알고리즘_암호키 길이_블럭 암호 모드_HMAC용 해시 알고리즘 등으로 구성--

Compression Method 

  • 압축 방법

(2) Server Hello

  • 실패할 경우 Alert protocol 사용 - Handshake failure alert 메시지를 보낸다.
  • server_version : 서버가 지원하는 SSL/TLS의 버전과 Client Hello 에서 전송받은 client_version(client가 사용할 수 있는 최상위 버전) 중에 같거나 낮은 버전으로 정한다.
  • random: Replay 공격 방지, key_block 만들 때 사용
  • session_id: 현재 접속중인 세션의 ID이다.(empty 또는 재사용 세션 ID 값)
  • cipher_suites: 클라이언트에서 받은 목록 중 하나를 정한다.
  • 그 외 선택한 압축 방법(compression method) , 서버 SSL 버전(version) 등을 전달한다.

 

(1단계) 보안 기능 설정 후에 클라이언트와 서버가 알게 되는 내용

  • SSL/TLS 버전
  • 키 교환, 메시지 인증과 암호화를 위한 알고리즘
  • 압축 방법
  • 키 생성을 위한 2개의 난수(클라이언트 랜덤, 서버 랜덤)

(3)  Server  Certificate

  • 서버에 있는 인증서를 보냄
  • 이 때 서버의 인증서는 선택된 cipher suite의 키 교환 알고리즘에 맞는 타입이어야 한다.

Certificate

  • 인증서가 가지고 있는 정보 : 공개키, 인증서 발급자(CA), 도메인 등

Certificate status

  • OCSP(Online Certificate Status Protocol) 온라인 인증서 상태 프로토콜로 인증서 유효성 검증을 제공한다. 인증서가 폐기된 것인지 정상인지 빠르게 확인을 할 수 있다.
  • cf) CRL (Certificate Revocation List) 에서 OSCP 로 발전됨

(4) Server Key Exchange

서버의 인증서를 보내지 않았거나, 보낸 인증서에 키 교환에 필요한 정보가 부족하면 전송되는 메시지이다.

(5) Certificate Request (선택)

서버가 클라이언트에게 인증서를 통한 인증을 요구할 때 사용하는 메시지이다. 서버는 자신을 클라이언트에게 인증함과 동시에 클라이언트에게 클라이언트의 인증서를 통한 인증을 요구할 수 있다. 서버와 클라이언트 인증서 상호인증이 필요할 때 선택적으로 사용한다.

 

(6) Server hello done

서버가 보낼 메시지가 끝났음 

(2단계) 서버 인증과 키 교환 후에

  • 서버는 클라이언트에 대해 인증 된다.
  • 클라이언트는 서버의 공개키를 알 수 있다.

(7)  ClientCertificate(선택)

서버로 부터 Certificate Request 요청을 받았다면 클라이언트가 보내는 메시지 이다.

 

(8) Client Key Exchange

  • 서버의 랜덤 데이터와 클라이언트가 생성한 랜덤데이터를 조합하여 pre-master-secret (48바이트)키를 생성한다.
  • 그 후 서버의(인증서) 공개키와 선택된 알고리즘(RSA, Fortezza, Diffi-Hellman 중 하나)을 이용하여 pre-master-secret을 서버에 전달한다.

(9) Certificate Verify (선택)

  • 클라이언트 인증서의 명백한 확인을 위해서 클라이언트는 핸드세이크 메시지를 전자 서명하여 전송한다.

(3단계) 클라이언트 인증과 키 교환 후에

  • 클라이언트는 서버에 대해 인증된다.
  • 클라이언트와 서버 양측은 pre master secret 을 알게 된다.

Client Change Cipher Spec

  • 종단간에 협상된 보안 파라미터를 이후부터 적용/변경함을 알리기 위해 사용하는 프로토콜

- Client Encrypted Handshake Message

 

Server Cipher Spec Exchage

- Server Encrypted handshake message

Finished

  • changecipherspecs 메시지 이후에 전송되며, 협상된 알고리즘과 키가 처음으로 적용된다.

 

서버는 changecipherspec 메시지와 finished 메시지를 클라이언트에게 보내고, TLS 핸드세이크 프로토콜을 마치게 된다.

그러면 연결을 통해 애플리케이션 데이터가 전송되기 시작한다.

(4단계) 종료 단계 후에 클라이언트와 서버는 데이터를 교환할 준비가 된다.

Record 프로토콜(TCP)

  • 상위계층(SSL) 데이터 캡슐화를 위해 암호화 및 복호화, 검증, 압축 및 해제, 패킷의 분할 및 재결합을 담당한다.
  • 핸드세이크 과정 중 블록 암호 알고리즘이 결정되고 비밀키를 이용해 송수신되는 자료의 암호화 및 복호화를 수행한다.
  • TCP에 위치하며 데이터에 대한 기밀성과 무결성 인증의 보안 서비스를 제공한다.
  • 기밀성(Confidentiality): 핸드세이크 프로토콜은 TLS 페이로드를 관용 암호화 아는데 쓸 공유 비밀키를 정의한다.
  • 메시지 무결성(Message Integrity): 핸드세이크 프로토콜은 또한 메시지 인증 코드(MAC)를 생성하는데 사용할 공유 비밀키를 정의한다.

 

Record 프로토콜 동작 순서

  • 단편화 → 압축 → MAC추가 → 암호화