SSL 과 SSL Handshake

원래는 Node js 소켓 관련하여 포스팅을 하려 했는데 SSL 관련하여 정리를 해야 되는 일이 생겨 SSL 관련하여 포스팅 작성하였습니다(소켓 관련한 내용을 빠른 시일 내에 포스팅하도록 하겠습니다)

 

 

HTTPS

HTTP와 Secure가 합쳐진 프로토콜이며 HTTP와는 크게 다르지 않으나 보안이 추가된 프로토콜입니다

주로 443 포트를 사용합니다

 

SSL

SSL은 Seruce Socket Layer의 약자이며, 인터넷상에서 주고받는 데이터를 보호하기 위해 등장하였습니다

SSL프로토콜은 OSI 7 계층 모델의 어느 한계층에 속해서 동작하는 것이 아니라, 응용 계층, 전송 계층 사이에 독립적인 프로토콜 계층을 만들어서 동작합니다

 

대칭키 암호화

암호화, 복호화에 사용하는 키가 동일하며 암호화 방식의 속도가 빠르고 대용량 데이터를 암호화하는데 적절하나 키가 탈취될 수 있고 사람이 증가할수록 키 관리가 어려워지는 단점이 있습니다

 

공개키 암호화

대칭키의 키 교환 문제를 해결하기 위해 등장하였으며 공개키/개인키 쌍으로 구성되어있습니다 공개키는 모든 사람이 접근 가능한 키이고, 개인키는 각 사용자만이 가지고 있는 키입니다

즉 A->B로 데이터를 전달할 때 A는 B의 공개키로 암호화한 데이터를 보내고, B는 본인의 개인키로 해당 함호화된 데이터를 복호화합니다, 대칭키 암호화 방식에 비해 속도가 느립니다

 

CA

인증서의 역할은 클라이언트가 접속한 서버가 의도한 서버가 맞는지 보장하는 것입니다, 이러한 역할을 하는 기업들이 있는데 이를 CA 혹은 Root Certificate라고 부릅니다, 개발자는 신뢰할 수 있는 CA기업의 인증서를 구입해야 하며 인증서를 구입하면 CA기업의 개인키를 이용하여 암호화한 인증서를 발급해줍니다

 

SSL 인증서

SSL 인증서에는 서비스의 정보(인증서를 발급한 CA정보, 서비스의 도메인 등)와 서버 측 공개키가 들어있습니다

 

CA리스트

브라우저는 내부적으로 CA의 리스트를 미리 가지고 있습니다, 즉 브라우저 소스 코드 내에 CA리스트가 들어있으며 브라우저 내에 들어있는 CA 리스트의 포함되어야만 공인된 CA가 될 수 있습니다, 브라우저는 CA 리스트와 함께 각 CA의 공개키를 가지고 있습니다

 

SSL 동작 과정

SSL은 암호화된 데이터를 전송하기 위해서 공개키와 대칭키를 혼합해서 사용합니다, 클라이언트와 서버가 주고받는 실제 정보는 대칭키 방식으로 암호화하고, 대칭키 방식으로 암호화된 실제 정보를 복호화할 때 사용할 대칭키는 공개키 방식으로 암호화해서 클라이언트와 서버가 주고받습니다

 

HandShanke

 

노란색 부분과 파란색 부분으로 나뉘어있는데 파란색 부분은 TCP레이어에 3-way hadshake 부분이며 HTTPS 프로토콜이 TCP 기반의 프로토콜이기에 SSL Handshake 과정 전에 실시하는 과정입니다 노란색 부분이 실제 SSL Handshanke 과정입니다

 

 

ClientHello

클라이언트가 서버에 접속을 하며 이때 서버에 Client Hello라는 패킷을 전송합니다 이 단계에서 주고받는 데이터는 아래와 같습니다

1. 클라이언트 측에서 생성한 랜덤 데이터
2. 세션 아이디
3. 클라이언트가 지원하는 암호화 방식들 : 클라이언트와 서버가 지원하는 암호화 방식이 서로 다를 수 있기 때문에 어떤 상호 간 통신에서 어떠한 암호화 방식을 사용할 것인지에 대해서 정해야 합니다. 이를 정하기 위해 클라이언트는 자신이 사용할 수 있는 암호화 방식 리스트를 전달합니다

 

ServerHello

서버는 클라이언트에서 전송한 ClientHello 패킷을 전달받아 클라이언트가 지원하는 암호화 방식들 중 하나를 선택하여 다시 클라이언트에게 전송합니다. 그리고 이때 자신의 SSL 프로토콜 버전과 같은 정보도 같이 보내게 됩니다

• 여러 개의 암호화 리스트 중 자신이 사용할 수 있는 암호화 방식과 그중 보안성이 가장 뛰어난 암호화 방식을 고르게 됩니다

 

Certificate

서버가 자신의 SSL 인증서를 클 아이언트에게 전달합니다 인증서를 전달받은 클라이언트는 전달받는 인증서가 CA에 의해서 발급된 인증서인지를 확인하기 위해 브라우저에 내장된 CA리스트를 확인합니다. 만약 CA리스트가 없다면 사용자에게 경고 메시지를 출력하고 CA에 의해서 발급된 것인지를 확인하기 위해서 클라이언트에 내장된 CA의 공개키를 이용해서 인증서를 복호화합니다

복호화에 선공했다면 인증서는 CA의 개인키로 암호화된 인증서임이 보장된 것입니다

 

 

ServerKeyExchange / ServerHello Done

만약 서버의 공개키가 SSL 인증서 내부에 없을 경우 서버가 공개키를 직접 전달하는 패킷입니다, 만약 공개키가 SSL 인증서에 존재한다면 ServerKEyExchange는 생략됩니다, ServerHelloDone은 서버가 행동을 마쳤을 음 전달합니다

 

이과정을 통해 클라이언트는 서버 혹은 인증서에 들어있는 공개키를 획득합니다

 

 

Client Key Exchange

클라이언트는 서버와 주고받은 랜덤 데이터를 조합하여 Pre Master Secret이라는 키를 생성합니다

이때 위에서 획득한 공개키로 Pre Master Secret 키를 암호화해서 서버로 전송하면 서버는 자신의 비공개키로 Pre Master Secert 키를 복호화합니다

이러면 클라이언트와 서버 둘 다 Pre Master Secert키를 가지고 있게 됩니다

 

이후 서버와 클라이언트는 모두 일련의 과정을 거저 Pre Master Secret 값을 Master Scrert값을 만들고 Master Scrert는 Session Key 생성하게 됩니다 이 Session Key값을 이용해서 서버와 클라이언트는 데이터를 대칭키 방식으로 암호화한 후에 주고받습니다

 

ChangeCipherSpec / Finished

클라이언트와 서버가 서로에게 보내는 패킷이며 통신할 준비가 되어있음을 알리는 패킷입니다 이후 Finished 패킷을 전송하여 SSL Handshake가 종료되었음을 알립니다

 

세션

세션은 실제로 서버와 클라이언트가 데이터를 주고받는 단계입니다, 이 단계에서는 서버에 데이터를 전송하기 전에 Session Key값을 이용해서 대칭키 방식으로 암호화하여 전달합니다 암호화된 정보는 서버에 전송이 되며 서버도 세션 키 값을 알고 있기 때문에 복호화가 가능합니다

 

세션 종료

데이터 전송이 끝나면 SSL 통신이 끝났음을 서로에게 알려주고 사용한 세션 키는 폐기합니다

 

마치며

SSL 프로토콜은 개발 혹은 서비스를 사용하는 입장에서는 너무 당연하게 적용이되어있어서 간단하게 동작을 할것이라고 생각을하였는데 정리를 하다보니 SSL인증 과정이 생각보다 복잡하고 주고받는 패킷도 많은것이 보였습니다 이번에 정리를하면서 SSL 인증과정에 대해서 확실히 알수있어서 좋았습니다

 

참고문서

SSL 인증서에 대한 이해_ssung.k

TLS & SSL Handkshake_제이온

HTTPS 와 SSL 인증서_생활코딩

SSL이란 무엇인가_매일의공부기록