SSL(Secure Socket Layer) 통신 과정

SSL이란 이름 그대로 인터넷상에서 정보를 송/수신할 때 데이터를 암호화 하여 전달하는 것을 의미한다.

Osi 7계층에서는 5계층인 세션계층에 해당되며 TCP/IP계층에서는 3계층(전송계층)과 4계층(응용계층)사이에 해당한다.

SSL의 원리를 조금더 깊이 설명하자면 SSL은 일단 공개키 방식을 사용하지 않는다.

그 이유는 공개키 방식은 매우 많은 컴퓨터자원을 소모하기 때문에 효율면에서 좋지가 않다.

그렇다고 대칭키 방식을 사용하지도 않는다. 대칭키 방식의 경우 효율은 좋으나 수신자와 송신자가 동일한 키를 공유하기 때문에

보안에 취약할 가능성이 있기 때문이다.

 

그래서 SSL은 공개키와 대칭키의 장점을 합친 방법을 사용한다.

 

SSL 3Way HandShaking으로 그 원리를 보게 되면 

1. 클라이언트가 서버에 접속을 한다 -> Client Hello라 함

(이 때 클라이언트가 전송하는 데이터는 다음과 같다)

-> 클라이언트에서 생성한 랜덤데이터

-> 클라이언트가 지원하는 암호화 방식

-> 세션ID (세션아이디는 이전에 SSL HandShaking을 했을 경우 기존의 세션을 이용한다. 즉, 시간과 비용을 절감하기 위해 존재한다)

 

2. 서버는 클라이언트에 대한 응답을 한다 -> Server Hello라고 함

(이 때 서버가 전송하는 데이터는 다음과 같다)

-> 서버에서 생성한 랜덤데이터

-> 서버가 선택한 클라이언트의 암호화 방식

-> 인증서(내부에 서버의 공개키가 들어있음)

* SSL 인증서에 포함된 내용 : 서비스 정보( 인증서를 발급한 CA, 서비스 도메인 등 ), 서버 측의 공개키( 공개키 내용, 공개키의 암호화 방식 )

 

3. 클라이언트는 서버의 인증서가 CA(Certificate Authority, 공개키들을 발급하고 관리하는 네트워크 상의 기관)에서 발급된 것인지를

   확인 하기 위해서 클라이언트(브라우저)에 내장되어있는 CA리스트에서 인증서 유무를 확인한다. 없으면 사용자에게 경고 메세지를 출력한다.

   

인증서가 CA리스트에 있다면 인증서가 CA에서 발급된 것인지 확인하기 위해서 클라이언트에 

내장된 CA의 공개키를 이용하여 인증서 내부의 해시값(인증서 내부의 내용을 종합하여 만든 해쉬값)을

복호화(인증서는 CA의 개인키로 암호화되었기 때문이다)를 진행한다.

 

복호하였다면 인증서는 CA의 개인키로 암호화된 문서임이 보장된 것이고 클라이언트는 인증서를 보낸 서버를 신뢰할 수 있게 된다.

=> 이는 두가지의 장점이 있다. 

1) 인증서를 발급한 기관의 개인키로 암호화된 해시값(인증서내용종합정보)이 복호화 되었으므로 신뢰할 수 있다. 

2) 클라이언트가 받은 인증서의 내용을 종합하여 다시 해쉬값을 만들고 위에서 복호화된 해시값과 비교해보면 인증서가 변조되었는지 확인이 가능하다.

 

-> CA로부터 인증서를 구입할 때 서비스의 도메인, 공개키 등의 정보를 CA에 제출한다.

-> CA는 자신의 개인키를 이용하여 서버가 제출한 인증서를 암호화한다. 그러므로 CA의 개인키는 유출되면 큰일난다.

 

1. 인증서(공개키)를 해쉬 한 뒤 CA의 개인키로 암호화함 -> 디지털 서명

 

2. CA에서 발행한 공개키로 이 디지털 서명값을 복호화하면 인증서에 대한 해쉬값을 얻을 수 있음

-> 디지털 서명값 : 인증서(공개키)를 해쉬된 값을 CA의 개인키로 암호화한 결과값을 의미함

 

3. 인증서에 등록되어 있는 해쉬값과 CA에서 발행한 공개키로 디지털서명값을 복호화해서 나온 해쉬값이 서로 동일하다면 인증서의

내용과 공개키가 위변조되지 않았음을 보증할 수 있게 되는 원리

 

4. 클라이언트는 클라이언트가 생성했던 랜덤 데이터와 서버의 랜덤 데이터를 조합하여 Pre Master Secret라는 키를 생성한다.

   이 키는 데이터를 주고 받을 때 대칭키 기반으로 암호화 되어 사용될 것임으로 절대로 제 3자에게 노출되어서는 안된다.

    (5 에서 보면 알게 되듯, Pre Master Secert 키는 일련과정을 거쳐 Session key가 되고 이 Session key는 대칭키로 사용되기 때문에)

5. 이 키를 서버에게 전송하는데 이 때 사용되는 방법은 공개키 방식이다. 여기서 사용되는 공개키는 서버로 받은 인증서 안에서 

   구할 수 있다. 이 서버에 있는 공개키를 이용하여 Pre Master Secret을 암호화하여 전송하면 서버는 자신의 개인키로 복호화가

   가능하다.

 

6. 서버는 클라이언트가 전송한 Pre Master Secret 값을 자신의 개인키로 복호화한다. 그렇게 되면 이제 클라이언트와 서버 모두

   Pre Master Secret를 가지게 된다. 서버와 클라이언트는 Pre Master Secret를 어떠한 과정을 거쳐 Master secret으로 만든다.

   Master secret은 Session key를 생성해 내는데 이 Session key를 이용하여 서버와 클라이언트는 데이터를 대칭키 방식으로 암호화하여

   주고 받는다.  그 뒤 클라이언트와 서버는 핸드쉐이크 단계의 종료를 서로에게 알려준다.

7. 클라이언트와 서버가 실제로 데이터를 주고받는 단계는 세션 단계이다. 이 때 앞서 말했듯이 데이터를 Session key 값을 이용하여

   대칭키 방식으로 암호화한다. 이렇게 암호화된 데이터가 상대방에게 전송되면 상대방도 Session key 값을 알고 있기 때문에 복호화를 

   할 수 있다. 세션이 종료되면 서로에게 SSL통신이 끝났음을 알려준다. 그 뒤 사용한 대칭키인 세션키를 폐기처분한다.  

공개키 방식으로 암호화를 하는 것 

-> 데이터 보안에 중점을 두고 진행할 때

 

 

공개키 방식으로 복호화하는 것(개인키로 암호화) 

-> 인증과정을 중점으로 진행할 때(제공자의 신원인증, 전자서명의 원리)