SSL(Secure Socket Layer), TLS(Transport Layer Security)

SSL/TLS 란?

웹 서버 간에 안전하게 데이터 전송을 하기 위해 고안된 프로토콜이다. 

1994년 넷스케이프사에서 개발되었고, 데이터를 전송할 때 평문이 아닌 암호화된 내용을 전송하게끔 만들어져 있다.

SSL(Secure Socket Layer)은 SSL 1.0 부터 2.0, 그리고 TLS(Transport Layer Security)라는 이름으로 

RFC 2246 표준화 된 SSL 3.0 까지 점진적으로 개발되면서 계속하여 보안에 박차를 가하고 있다.

개인정보보호가 대두되는 요즘 SSL 보안 표준은 필수라고 말할 수 있다.

 

SSL에서는 큰 두가지 개념이 존재한다.

Session(세션) 과 Connection(연결) 이다.

세션은 서버와 클라이언트 사이의 관계를 말한다. 두 종단점의 세션은 암호화된 안전한 파라미터로 구성된다.

이 보안세션은 Handshake 프로토콜에 의해 생성된다.

세션의 상태는 몇가지 파라미터에 의해 정의된다.

 

Session identifier : 활동 중인 세션 혹은 서스팬드된 세션을 다시 복구 시킬 때 확인하는 세션 식별자.
Peer certificate : 피어의 X509.v3 인증서이다.
Compression method : 데이터 압축시 사용한 알고리즘
CipherSpec : 무슨 암호화를 사용했는지.
Master secret : 서버와 클라이언트 사이에 주고받는 48바이트 짜리 비밀값
Is resumable : 서스팬션된 세션이 다시 복구 가능한지 여부를 나타내는 플래그.

연결은 세션이 맺어진 상태에서 이루어진다. 이 연결은 일시적이고, 한세션에 여러개의 연결을 가질 수 있다.
연결 또한 아래와 같은 파라미터들에 의해 정의된다.

Server and client random : 각 연결에 대한 식별문자
Server(Client) write MAC secret :  서버(클라이언트)로 부터 온 MAC코드를 생성하는 Key  
Server(Client) write key : 서버(클라이언트)로 부터 온 암호화 키
Initialization vectors : CBC, DES 암호화에 사용될 초기백터 
Sequence numbers :  각 연결마다 주고받는 메세지의 시퀀스 넘버

 

 

SSL 프로토콜 구조

자 그럼 SSL이 어떻게 생겼는지 한번 확인해보자. SSL은 TCP헤더에 붙어서 전송된다.

(요건 전송계층 프로토콜 보안에 사용되는 거다.)

SSL 프로토콜의 구조는 위와 같이 생겼다. 필드가 여러가지가 있는데, 딱 생긴거만 봐도

응용계층과 전송계층 사이에 위치하고 있는 것을 알 수 있다. (HTTP, TCP 사이에 존재함)

그럼 각각의 필드들에 대해 한번 알아보자.

 

 

* Hand Shaking protocol 

클라이언트와 서버간에 session을 생성하여 인증 과정을 거치고 사용할 알고리즘을 결정한다.

보면 연결하는 과정에 꽤나 복잡하다. 

SSL은 보안세션을 먼저 맺고 연결을 한다. 헬로헬로 거리는게 보안 세션을 맺는 과정이다. 

보안 세션은 두 end point 사이에 암호화된 보안 파라미터에 의해 결정된다. 먼저 연결 과정을 살펴보자.

 

SSL Handshake Protocol 연결 과정

1. Client Hello : 

처음 서버로 연결을 시도 할때 보내는 메시지, 사용 가능한 암호방식(Cipher suites), 서명방식 등을 서버에 전송

2. Server Hello : 

전송받은 메시지에 응답하고 Session ID할당, Client Hello에서 받은 Cipher suites중 하나를 골라 그 정보를 Client로 전송한다.     

3. Server측 Certificate or Server key exchange : 

서버 인증서를 클라이언트로 Certificate 메시지와 함께전송, Fortezza/DMS 키교환을 사용한다면 Key exchange 전송

4. Certificate Request : 클라이언트에게 서버를 인증할 수 있게끔 하는 과정

5. Server Hello Done :  서버에서 모든 메시지가 전송되었음을 의미

6. Client측 Certificate : 서버로 클라이언트 측의 인증서를 전송한다.

7. Client Key exchange : 클라이언트가 임의의 비밀정보인 48바이트 premaster key라는  세션키를 생성하여 전송함.

8. Certificate Verify : 

서버가 클라이언트의 인증서를 쉽게 확인할 수 있도록 hand shake message를 전자서명하여 전송하는 과정. 서버는 인증서의 포함된 공개키가 유효한지 확인한다.

9. Change Cipher spec, Finished : 

이 이후에 전송되는 메시지들은 모두 인증된 알고리즘과 키를 사용중이라는 것을 알리는 과정 그리고 그 직후 바로 Fisnished 메시지를 보낸다. 

 

SSL의 Handshake 과정은 위와 같이 여러가지 단계를 거쳐 엄격하고 단단하게 보안 세션을 맺게 되어 있다.

  

* Change Cipher Spec protocol

Handshake 프로토콜에 의해 결정이 된 암호화 방식, 알고리즘이 

이후 부터 적용된다는 걸 상대방에 알리는 프로토콜

가장 심플하다. 1byte가 끝이다.

 

* Alert protocol

세션 종료 또는오류 발생시 이를 알리는 프로토콜

 

* Record Protocol 

보안성이 유지되면서 메시지들이 전송되도록 메시지 분할, 압축, 메시지 인증,  암호화 등의 작업을 수행하는 프로토콜

아래 그림을 보면 Fragment를 압축시키고 MAC 코드를 붙여 암호화 한다. 그리고 거기에 다시

SSL record header를 덧붙이는 형식이다.

 

메세지 인증은 MAC코드를 덧붙이고 암호화 시키는 방식으로 한다.

MAC은 두번의 Hash 과정을 통해 생성 된다. 

 

MAC = hash(MAC_write_secret || pad2 || hash(MAC_write_secret || pad1 || seq_num ||

 

SSLCompressed.type || SSLCompressed.length || SSLCompressed.fragment))

 

SSLCompressed.fragment : 압축된 프레그먼트

SSLCompressed.type : 프레그먼트 압축 타입

SSLCompressed.length : 프레그먼트 길이

 

자 그럼 메세지 인증에 대해 알아봤으니 이번에는 암호화에 대해 알아보자.

여러가지 암호화 알고리즘을 사용한다. 블록 암호, 스트림 암호를 사용한다. 종류는 아래.

•Block cipher: IDEA(128), RC2-40, DES, 3DES, Fortezza

 

•Stream cipher: RC4-40, RC4-128

 

이렇게 암호화 시키고 나면 SSL Record header를  갖다 붙인다고 했다. 

헤더는 어떻게 생겼을까.

 

레코드 헤더의 모습이다. 여러가지 필드들이 존재하는 걸 볼 수 있다. (물론 위에 1행이 헤더다)

 

Content type (8bits) : 상위 계층 프로토콜 타입.

Version:  major(8) 과 minor(8) 버전이 나타나있다.

Compressed length (16): 평문 프레그먼트의 길이