Backend/Network

TLS 프로토콜 정리.

petitCoding 2012. 4. 12. 11:23

•SSL (Socket Secure Layer)
–배경 : 1993년 웹에서 안전한 통신을 위해 Netscape社에 의해 개발
–특징 : 세션계층에서 적용되며, 응용계층의 FTP, TELNET, HTTP등의 프로토콜의 안전성 보장
–기능: 서버 인증, 클라이언트 인증, 기밀성 보장
–현황 및 전망 : 현재 많은 전자 쇼핑몰 업체에서 채택, 운영
•TLS (Transport Layer Security)
–배경 : SSL 3.0 이 표준화된 이후 IETF는 1996년 6월부터 TLS 프로토콜에 대한 표준화 (SSLv3.1)
–Backward compatible with SSLv3
–특징 : SSL 3.0을 기반으로 한 업그레이드 프로토콜
–현황 및 전망 : 현재 TLS 1.0이 발표, 지속적 개발 예상

 

TLS 사용 목적

- 암호 보안
두 통신단 사이에 안전한 연결을 설정하기 위해 사용한다
- 상호호환성
개발자들은 상대방의 암호 코드를 모르는 상태에서 응용 프로그램을 개발할 수 있다.
암호화를 위한 인수들의 교환은 TLS가 담당
- 확장성
새로운 공개키 암호화 방식과 블록 암호화 방식을 위한 프레임 워크를 제공한다.
- 효율성
TLS 프로토콜은 생성되는 연결의 수를 줄이기 위해 세션 캐쉬 스킴을 채용했다.

 

TLS Record Protocol

 

- TLS Record Protocol은 계층적 프로토콜이며 각각의 계층에서 메시지는 길이, 설명, 내용을 위한 필드를 가질 수 있다.

- Record Protocol은 메시지를 전송하고, 데이터를 블록으로 나눈다. 

- 경우에 따라서는 데이터를 압축하며, MAC을 제공해서 암호화 하고 그 결과를 전송할 수 있다.

- 전송 받은 데이터는 복호화, 검증, 압축 해제, 재결합 하여 상위 계층의 클라이언트에게 보내준다.

Connection States : 압축 알고리즘, 암호화 알고리즘, MAC 알고리즘 등을 지정.
Record layer  : Fragmentation, Record compression, Record payload protection

 

Change Cipher Spec Protocol
- 암호규격프로토콜(change cipher spec protocol)은  TLS 프로토콜을 사용하는 3개의 TLS 관련 프로토콜 중 하나이며 가장 간단하다.
- 하나의 메시지로 되어 있으며 값 1을 갖는 한 바이트로  구성된다.
- Handshake 프로토콜에 의해 협상된 압축, MAC, 암호화 방식 등이 이후부터 적용됨을 상대방에게 알려준다.

 

Alert Protocol

- 경고 프로토콜(Alert Protocol)은 대등한 개체에게 TLS관련 경고를 전달하기 위해 사용된다.
- 경고 메시지는 압축되고, 암호화된다.
- 프로토콜에 있는 각 메시지는 2 바이트로 되어 있다.
- 첫 바이트는 메시지의 심각성을 전달하기 위해 warning(1) 또는 fatal(2)의 값을 가진다. 만일 레벨이 fatal이면,  TLS는 즉시 연결을 종료한다.
- 두 번째 바이트는 특정 경고를 지시하는 코드가 들어 있다.

 

 

Handshake Protocol

서버와 클라이언트간의 상호인증을 수행하고, 사용할 키 교환 방식, 대칭키 암호 방식, HMAC 방식, 압축방식 등의 보안속성을 협상한다.

 

1. Client Hello (Client->Server) : Client는 서버에게 Hello 를 보냄으로 연결을 시도한다. 이때 재연결일 경우에는 Session ID가 존재하여 이를 사용하게 되며, 처음 연결일 경우에는 아직 session ID가 없는 상태이다.

이와 함께 Client는 자신이 사용 가능한 Cipher Suites 를 서버에게 전송한다.

 

 

2. Server Hello : 서버는 Client에게 Server Hello로 답변한다. 이때 Session ID가 생성되어 전송되며, 서버가 사용가능한 Cipher Suite 값을 클라이언트에게 알려주게 된다. 이제부터는 이 Cipher Suite에 해당하는 암호화 알고리즘으로 세션키 및 데이터가 암호화 된다.

 

3. Certificate (Server Key Exchange)

4. Server Hello Done (Server->Client)

 

 

5. Client key exchange : Client는 세션키를 생성하여 이를 서버에게 전송한다. 이때 세션키는 암호화가 되는데, 이를 Pre-master Secret이라고 하며, 이 값은 서버 측에서 복호화 되어 데이터는 이 복호화된 세션키 (Master Secret) 를 사용하여 복호화 하게 된다.
6. Change cipher spec : 모든 협상이 이상 없이 진행되면 마지막으로 이 Change Cipher Spec 값을 1로 하여 전송한다. 이는 협상된 알고리즘 및 세션 ID를 사용하겠다는 의미이다.
7. Finished (Client->Server): 협상이 끝났음을 알리는 프로토콜이다.

 

8. Change cipher spec : 서버 역시 이에 동의한다는 뜻으로 Change Cipher Spec 을 1로 셋팅하여 전송한다.
9. Finished (Server->Client) : 이로써 모든 협상이 종료되고, 이 이후의 Client-Server 데이터는 모두 암호화 되어 송수신 하게 된다.

 

* TLS 연결을 재사용 하는 경우 (Session ID가 존재하는 경우)

1. Client hello (Client->Server) : Server 에게 Hello를 전송한다. 이때 Session ID가 존재하는 것을 확인할 수 있다.


 

2. Server hello, Change cipher spec, Finished (Server->Client) : Client로부터 세션 정보를 받은 Server는 그 세션에 있는 Master Secret (초기 연결에서 사용했던 세션키를 저장해 놓음)을 사용해 데이터를 복호화 하면 된다. 따라서 위의 Key Exchange 과정이 생략되고, Client에게 OK 사인(Change Cipher Spec) 및 Finish 메시지를 전송하여 협상을 종료한다.

 

 

3. Change cipher spec, Finished (Client->Server) : Client 역시 세션 키를 보유하고 있기 때문에 OK 한뒤 협상을 종료한다. 이 뒤로 주고받는 메시지는 모두 암호화 되어 있다.

 

 

반응형

'Backend > Network' 카테고리의 다른 글

IPv6 헤더 구조  (0) 2012.04.12
ICMP  (0) 2012.04.12
OSI MODEL  (0) 2012.04.12
NAT  (0) 2012.04.12
서브넷  (0) 2012.04.12