[ETC] SSL vs TLS 차이점 및 확인방안

본 포스팅은 SSL(Secure Socket Layer)과 TLS(Transport Layer Security)에 대해 알아보겠습니다.

---

SSL과 TLS는 모두 웹 서버와 사용자의 웹 브라우저 간 통신을 암호화 하는데 사용되는 프로토콜입니다.

공개 키와 개인 키를 교환하여 보안 세션을 생성하여 통신을 암호화하는 방식을 사용합니다.
TLS는 MAC 함수 생성을 위해 다른 암호화 알고리즘을 사용하며, 이는 이전 버전의 SSL보다 많은 경고 코드를 포함하고 있습니다.

전자 상거래가 활발해지면서 웹 보안이 매우 중요해지고 있으며, 최근 정보통신망법의 개정으로 아무리 소상공인이라도 홈페이지 운영 시 개인정보를 취급하고 있다면 아래와 같은 내용을 조치하도록 되어있습니다.
이러한 "보안서버"의 기반이 되는 SSL/TLS 프로토콜에 대하여 소개합니다.

웹사이트 개인정보보호 의무조치 안내는 다음과 같습니다.

'개인정보취급방침'을 마련하고 이용자에게 공개해야 합니다.

개인정보 수집 이용에 대한 이용자 동의를 받아야 합니다.
개인정보를 제 3자에게 제공하거나 업무 위탁할 경우 이에 대한 동의를 받아야 합니다.
이용자의 회원탈퇴 권리 및 방법을 안내하고 이를 이행해야 합니다.
개인정보를 전송하는 구간에 보안서버를 적용해야 합니다.

그럼 SSL과 TLS는 무엇이고 왜 사용해야 하는지 알아보겠습니다.
SSL(Secure Sockets Layer)은 보안 소켓 계층 이라는 뜻으로 인터넷을 통해 전달되는 정보 보안의 안전한 거래를 허용하기 위해 Netscape 사에서 개발한 인터넷 통신 규약 프로토콜이며, TLS(Transport Layer Security)는 SSL 3.0을 기초로 해서 IETF가 만든 프로토콜로 이는 SSL3.0을 보다 안전하게 하고 프로토콜의 스펙을 더 정확하고 안정성을 높이는 목적으로 고안되었습니다.
1.0 버전은 공개 된 적이 없고, 2.0 버전이 1995년 2월에 이르러 릴리스가 되지만 이 버전은 많은 보안 결함때문에 3.0 버전으로 곧바로 이어집니다.
3.0은 1996년 릴리스 되었고, 3.0 버전은 TLS 버전 1.0의 기초가 된 후, IETF에서 1999년 1월에 RFC 2246 표준 규약으로 정의하게 되었습니다.
SSL과 TLS 두 가지 프로토콜은 TCP/IP 네트워크를 사용하는 통신에 적용되며, 통신 과정 에서 전송계층 종단간 보안과 데이터 무결성을 확보 할 수 있게 합니다.

SSL/TLS통신 과정은 다음과 같은 과정으로 handshaking이 이루어 집니다.

먼저 Client가 Request를 하면 TCP Level에서 연결이 맺어진 이후 SSL/TLS Handshacke을 수행합니다. ClientHello 메시지를 보내면서 이 메시지에는 클라이언트에서 가능한 TLS 버전, 세션 식별자, 암호 설정 등의 정보가 포함됩니다.
다음으로 Server에서 암호화를 위한 인증서의 공개키를 내려주게 되면 client는 이 공개키가 신뢰할 수 있는 인증서의 키 인지 확인합니다.
다음 단계로 서버는 ServerHello 메시지를 클라이언트에게 보냅니다. 여기에는 ClientHello 메시지의 정보 중 서버에서 사용하기로 선택한 TLS 버전, 세션 식별자, 암호 설정 등의 정보가 포함됩니다.
또한 Certificate 메시지를 보낸다. 여기에는 서버의 인증서가 들어있습니다. 이 인증서는 인증 기관에서 발급받은 것이며, 서버가 신뢰할 수 있는 자임을 인증합니다. 전송이 끝나면 ServerHelloDone 메시지를 보내 끝났음을 알립니다.
clinet 단에서는 해당 공개키를 신뢰한다면 이 client의 session key를 생성하여, 서버로부터 받은 공개키로 암호화하여 server로 전달합니다.
클라이언트는 서버에서 받은 인증서를 검증합니다. 유효 기간이 만료되지 않았는지, 신뢰할 수 있는 인증 기관에서 발급되었는지, 그 인증서가 해당 서버에게 발급된 인증서가 맞는지 등을 확인합니다. 서버를 신뢰할 수 있다고 판단하였다면 다음 단계로 넘어갑니다.

클라이언트는 임의의 pre-master secret을 생성한 뒤, 서버가 보낸 인증서에 포함된 공개키를 사용해 암호화합니다. 이렇게 암호화된 pre-master secret을 ClientKeyExchange 메시지에 포함시켜 서버에 전송합니다.
해당 서버는 서버에 있는 개인키를 통해 복호화를 하여 client의 session key를 확보하고, client가 준 cipherspec에서 서버가 허용하는 chipherspec을 client에 전달합니다.
서버는 전송받은 정보를 복호화하여 pre-master secret을 알아낸 뒤, 이 정보를 사용해 master secret을 생성합니다. 그 뒤 master secret에서 세션 키를 생성해내며, 이 세션 키는 앞으로 서버와 클라이언트 간의 통신을 암호화하는데 사용할 것입니다. 물론 클라이언트 역시 자신이 만들어낸 pre-master secret을 알고 있으므로, 같은 과정을 거쳐 세션 키를 스스로 만들 수 있습니다.
위 과정을 통해 server와 client는 동일한 session key를 가지게 되어 이후부터는 이 session key를 가지고 상호 암, 복호화를 수행합니다.
이제 서버와 클라이언트는 각자 동일한 세션 키를 가지고 있으며, 이를 사용해 대칭 키 암호를 사용하는 통신을 할 수 있습니다. 따라서 우선 서로에게 ChangeCipherSpec 메시지를 보내 앞으로의 모든 통신 내용은 세션 키를 사용해 암호화해 보낼 것을 알려준 뒤, Finished 메시지를 보내 각자의 Handshacke 과정이 끝났음을 알립니다.

다음으로 SSL/TLS와 OpenSSL 그리고 WebtoB의 wbssl이 무엇인지 알아보겠습니다.
먼저 OpenSSL입니다.
OpenSSL은 네트워크를 통한 데이터 통신에 쓰이는 프로토콜인 TLS와 SSL의 오픈 소스 구현 판으로,C 언어로 작성되어 있는 중심 라이브러리 안에는, 기본적인 암호화 기능 및 여러 유틸리티 함수들이 구현 되어있으며 거의 모든 OS 상에서 사용이 가능합니다.

다음으로 WebtoB의 Wbssl입니다.
Wbssl은 openssl 라이브러리를 WebtoB가 가져와 사용한 WebtoB의 openssl 라이브러리로 버전표기 및 라이브러리를 사용하는 측면에서 같은 것이라고 보아도 무방합니다.

그럼 Wbssl를 통한 SSL/TLS 통신은 어떻게 이루어 지는지 살펴보겠습니다.
WebtoB는 SSL/TLS 인증서를 적용시켜 해당 웹 서버 도메인으로 연결 시 TCP레벨 연결 이후 한번 더 SSL/TLS Handshacke를 수행하게 됩니다.
인증서의 경우 어떤 프로토콜의 알고리즘을 사용할지는 client의 chipherspec과 host 쪽의 프로토콜, 알고리즘 설정을 mapping 하여 동일하게 충족되는 것 중 높은 버전의 프로토콜의 알고리즘을 선택하여 통신합니다.
임의의 인증서를 설정상으로 지정해 주게 되면 그 인증서에서 제공하는 프로토콜과 알고리즘을 Protocol 및 RequiredCiphers 설정을 통해 제한할 수 있고, 원하는 프로토콜 및 알고리즘을 선택하여 SSL/TLS handshacke 를 수행할 수 있습니다.

마지막으로 SSL/TLS 통신 확인과정을 살펴보겠습니다.
SSL 인증서가 설치된 WebtoB 서버에 연결을 시도하는 방법에는 여러가지가 있지만 wbssl/openssl 을 통한 연결과 웹 브라우저를 통한 연결을 확인해 보겠습니다.
Wbssl/openssl은 명령어의 차이 없이 동일하게 사용하면 됩니다
WebtoB의 경우 wbssl s_client –connect <domain>:<port> -state –debug –ssl2 이며, openssl의 경우 openssl s_client –connect <domain>:<port> -state –debug –ssl2 입니다.

연결 프로토콜을 SSL3로 지정하여 정상 handshacke가 되면 아래와 같이 위에서 설명한 과정에 따라 HandShacke 하는 부분을 모니터링 할 수 있습니다.

먼저 client, server Hello Message를 주고 받는 것을 볼 수 있습니다.
다음으로 Serverkey,ClinetKey Exchage, server Hello done, change cupherSpec 과정이 수행 되는 것을 볼 수 있습니다.
HandShake가 마무리가 되면, 실제 HTTP request를 보냅니다.
연결된 이후 telnet으로 request를 보내는 것과 같은 동작을 할 수 있게 됩니다.
해당 WebServer wbssl 라이브러리에서 지원하지 않는 tls1.2로 통신을 시도하자 “client hello A” 메시지 이후 “fatal:protocol version” 와 같은 로그가 나타났고, 이후 “server hello A” 메시지에도 “wrong version number” 라는 로그가 보이면서 handshacke에 실패함을 볼 수 있습니다.
위와 같이 TCP 연결은 성공을 했지만 실제 request를 보내기 위해서는 SSL/TLS handshacke가 성공해야 하나 이 단계에서 실패하게 되면, 맺어진 TCP연결도 바로 끊어져 버리게 됩니다.

웹 브라우저는 IE의 도구, 인터넷 옵션, 고급 탭의 설정 가능한 목록을 보면 어떤 SSL/TLS 프로토콜로 통신을 할 것인지를 설정할 수 있습니다.
중복으로 체크가 되어있을 경우 웹 브라우저와 WebServer에 존재하는 프로토콜의 교집합 중 높은 버전의 프로토콜로 통신을 하게 됩니다.
Wbssl 라이브러리를 통해 연결을 할 경우 -debug 옵션을 통해 자세한 handShacke 과정을 모니터링 할 수 있었으나 브라우저에서는 이러한 debugging을 할 수 없기 때문에 fiddler를 통해 request를 보낼 시에 어떤 정보를 가지고 보내는지 정도를 모니터링 하였습니다. 

major, minor 버전을 확인하면 어떤 프로토콜로 요청을 하는지 확인할 수 있습니다.

Major가 2, minor가 0이면, SSLv2 프로토콜로 통신을 요청합니다.
Major가 3, minor가 0이면, SSLv3 프로토콜로 통신을 요청합니다.
Major가 3, minor가 0이면, TLS1.0 프로토콜로 통신을 요청합니다.
Major가 3, minor가 1이면, TLS1.1 프로토콜로 통신을 요청합니다.
Major가 3, minor가 2이면, TLS1.2 프로토콜로 통신을 요청합니다.
또한 아래의 ciphers 목록을 보면 client단에서 사용 가능한 통신 알고리즘 목록을 프로토콜 버전정보와 함께 보내는 것으로 볼 수 있습니다.

SSL과 TLS 그리고 WebtoB의 wbssl에 대해 지금까지 알아보았습니다. 

최근 보안 권고사항으로 인한 한국정보통신협회에서 주기적으로 권고 알고리즘 허용, 해제에 대해 업데이트 하고 있습니다. 각 버전과 종류에 따른 차이점을 본 포스트를 통해 알아두고, 활용하시기를 부탁드립니다.

고맙습니다.