SSL/TLS 원리 , 웹 송수신 시 데이터 보호 방법

[주제] 웹 송수신 시 데이터를 보호하는 방법 (SSL/TLS)

 

웹 기술이 고도화되며 다양한 해킹 방법이 등장했고, 

이에 따라 더욱 안전하게 데이터를 전달할 수 있는 보안 체계가 필요해졌습니다.

따라서, 지난 칼럼을 통해 정리해본 웹에서의 데이터 전달 과정에 이어,

이번 기술칼럼에서는 데이터가 전달될 때 보안을 책임지는 SSL/TLS에 대해 알아보겠습니다.

 

1.     SSL(Secure Sockets Layer)과 TLS(Transport Layer Security)

SSL과 TLS는 같은 개념을 뜻합니다. 

넷스케이프(Netscape)사에 의해 SSL이 발명되었고, 이것이 점차 폭넓게 사용되다가 표준화 기구인 IETF(Internet Engineering Task Force)의 관리로 변경되면서 

TLS라는 이름으로 바뀌었습니다. (TLS 1.0은 SSL 3.0을 계승하여 만들어졌습니다.)

현재 대다수의 보안 프로토콜이 TLS로 교체되었지만, 우리에게 익숙한 SSL이라는 이름으로 많이 사용되고 있습니다.

 

2.     SSL/TLS 과 HTTPS 란?

SSL/TLS는 클라이언트와 서버가 서로 데이터를 암호화하여 통신할 수 있도록 하는 보안 계층입니다. 

대표적으로 HTTPS 프로토콜의 경우, HTTP 메시지에 포함되는 콘텐츠 정보에 보안 요소를 추가하여 데이터를 안전하게 주고받을 수 있도록 합니다. 

OSI 계층 구조로 보자면, HTTPS는 아래 그림과 같이 HTTP 계층 아래에 SSL이라는 보안 계층이 추가된 모습입니다.

 

3.     대칭키, 공개키로 암호화하는 방법

SSL 동작 과정을 알아보기 전에, 먼저 대칭키 암호화 방식과 공개키 암호화 방식에 대해 이해해보도록 하겠습니다.

※ 전달하고자 하는 데이터에 암호를 만드는 행위를 암호화라고 하고, 반대로 암호를 푸는 행위를 복호화라고 합니다. 

   일종의 암호를 키(Key)라고 합니다.

 

- 대칭키

대칭키 방식은 동일한 키로 암호화와 복호화를 같이 할 수 있는 방식의 암호화 기법을 의미하며, 

만약 암호화할 때 1234라는 값을 사용했다면 복호화 할 때 1234라는 값을 입력해야 하는 것입니다.

공개키 방식에 비해 암호화, 복호화 속도가 빠르다는 장점이 있습니다.

그러나 클라이언트와 서버가 같은 키를 가지고 있어야 하므로 서로 키를 통신해야 하는데, 그럼 누가 중간에서 키를 가로챌 위험이 있습니다.

 

- 공개키

위와 같이 대칭키 기법의 안전 문제를 해결하기 위한 방식이 공개키 기법입니다.

공개키 기법은 서로 다른 키 2개로 암호화, 복호화 한다는 특징이 있으며, 이 때 사용하는 키 두개를 각각 공개키, 개인키(비공개키)라고 합니다.

공개키 기법의 개념은 공개키로 암호화한 데이터는 개인키로만 복호화 할 수 있고, 개인키로 암호화한 데이터는 공개키로만 복호화 할 수 있습니다. 

그래서 만약 서버가 개인키를 갖고 클라이언트에게 공개키를 전달해 서로 암호화된 데이터를 주고받을 때, 

중간에서 누군가가 공개키를 가로챘다고 하더라도 개인키를 모르기 때문에 데이터를 복호화 할 수 없습니다.

 

4.     SSL/TLS 동작 과정

동작 과정을 큰 단계로 나눠보면 악수(Handshake) → 데이터 전송 → 세션종료 순으로 볼 수 있습니다.

※     악수(Handshake)

사람과 사람이 서로 소통할 때 인사를 주고받는 것처럼, 클라이언트와 서버도 실제로 데이터를 주고받기 전에 일종의 인사인 핸드쉐이크를 합니다. 

이 과정을 통해 상대방이 존재하는지, 데이터를 주고받기 위해서 어떤 방법을 사용해야 하는지 파악합니다.

 

그럼 이제 SSL 인증서를 기반으로 클라이언트와 서버가 통신하는 과정을 순서대로 정리해보겠습니다.

 

1)    클라이언트가 서버에 접속합니다. (Client Hello)

이 단계에서 주고받는 정보는 아래와 같습니다.

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

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

: 클라이언트와 서버가 지원하는 암호화 방식이 서로 다를 수 있기 때문에 상호간에 어떤 암호화 방식을 사용할 것인지에 대한 협상을 해야 합니다. 

  이 협상을 위해서 클라이언트 측에서는 자신이 사용할 수 있는 암호화 방식을 전송합니다.

-  세션 아이디

: 사용할 연결에 대한 식별자를 서버 측으로 전송합니다.

 

2)    서버는 응답을 합니다. (Server Hello)

이 단계에서 주고받는 정보는 아래와 같습니다.

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

-  서버가 선택한 암호화 방식

: 클라이언트가 전달한 암호화 방식 중에서 서버 쪽에서도 사용할 수 있는 암호화 방식을 선택해서 클라이언트로 전달합니다. 

  이로써 암호화 방식에 대한 협상이 종료되고, 서버와 클라이언트는 이 암호화 방식을 이용해서 정보를 교환하게 됩니다.

-  SSL 인증서

 

3)    인증서를 확인합니다.

클라이언트는 서버의 인증서가 CA(공인인증을 보장하는 기업)에서 발급된 것인지 확인하기 위해, .

클라이언트(브라우저)에 내장된 CA 리스트와 공개키를 이용해서 인증서를 복호화 합니다. 

복호화에 성공한다면 인증서는 CA의 개인키로 암호화된 문서임이 보증된 것이므로, 인증서를 전송한 서버를 믿을 수 있게 되는 것입니다.

 

4)    임시 대칭키를 생성합니다.

클라이언트는 상기 ①, ②번 과정을 통해 받은 랜덤 데이터들을 조합하여 실제 데이터 통신에 사용할 임시 대칭키(pre master secret)를 생성합니다.

 

5)    임시 대칭키를 공개키 기법으로 암호화합니다.

임시 대칭키는 대칭키 기법으로 생성되었으므로 제3자에 절대 노출되어서는 안되기 때문에, 클라이언트는 이 임시키를 암호화하여 서버에 전달하는데 

이 때, 서버로부터 전달받았었던 인증서 내의 공개키를 이용해서 공개키 기법으로 암호화합니다.

 

※    대칭키와 공개키를 조합해서 사용하는 이유

공개키 방식은 매우 많은 컴퓨터 자원을 사용하는 단점이 있고, 

대칭키 방식은 암호화와 복호화에 사용되는 키가 동일하기 때문에 보안에 취약합니다. 

따라서, SSL은 공개키와 대칭키의 장점을 혼합한 방법을 사용합니다.

 

6)    서버는 임시 대칭키를 복호화하고, 클라이언트와 서버는 세션 키를 생성합니다.

서버는 전달받은 임시 대칭키(pre master secret)값을 자신의 개인키로 복호화 하면, 이로써 서버와 클라이언트 모두가 임시 대칭키 값을 공유하게 됩니다.

그리고 서버와 클라이언트는 모두 일련의 과정을 거쳐서 임시 대칭키 값을 기반으로 세션키(Session Key)를 생성합니다.

이로써, 세션키를 이용하여 서버와 클라이언트가 본격적으로 데이터를 주고받을 수 있게 됩니다.

 

7)    세션키를 이용하여, 데이터를 주고받습니다.

세션키를 이용하여 데이터를 대칭키 방식으로 암호화하고, 

상대방에 전송된 암호화된 데이터는 상대방도 세션키 값을 알고 있기 때문에 복호화 하여 데이터를 열람할 수 있습니다.

 

8)    세션을 종료합니다.

데이터 전송이 끝나면, SSL 통신이 끝났음을 서로에게 알려줍니다. 이 때 통신에서 사용한 대칭키인 세션키를 폐기합니다.

 

이렇게 복잡한 과정을 통해 신뢰할 수 있는 데이터 통신 환경이 만들어지고, 

우리가 HTTPS 프로토콜로 안전하게 데이터를 주고받을 수 있게 되는 것입니다.