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

SSL(Secure Socket Layer): 보안 소켓 계층으로 웹사이트와 브라우저(혹은 두 서버)사이에 전송된 데이터를 암호화 하여 인터넷 연결시 보안을 유지하는 표준 기술로 HTTPS에서 사용되고 있으며 해커가 개인 정보 및 금융 정보를 포함한 전송되는 모든 정보를 열람하거나 훔치는 것을 방지한다.

SSL(Secure Socket Layer): 보안 소켓 계층

 

TLS(Transport Layer Security): 전송 계층 보안으로 더 강력한 버전의 SSL이라 볼 수 있다. 하지만 SSL이 더 일반적으로 사용되는 용어이기에 여전히 보안 인증서에서는 SSL이라 불리고 있다.  전송 계층 보안은 컴퓨터 네트워크에 통신 보안을 제공하기 위해 설계된 암호 규약이다. 그리고 TLs는 SSL이 표준화 되면서 바뀐 명칭으로 인터넷 같이 TCP/IP 네트워크를 사용하는 통신에 적용되며, 통신 과정에서 전송계층 종단간 보안과 데이터 무결성을 확보해준다. 이 규약은 웹 브라우징, 전자메일, 인스턴트 메신저, voice-over-ip(VoIP)같은 응용 부분에 적용되고 있다. 국제 인터넷 표준화 기구(IETF)에 의해 현재 구식(deperate)으로 간주되어 있다. 

 

정리: SSL과 TLS는 웹 브라우저간 통신을 암호화 하는데 사용하는 프로토콜이다. 공개키와 개인키를 교환하여 보안 세션을 생성한 후 통신을 암호화 한다. TLS는 SSL에서 개선된 신규 모델 프로토콜이며, 전자상거래 등이 활발해지며 웹 보안이 매우 중요해지고 있기에 개인정보보호 의무조치에 의해 개인 정보 전송구간에 보안 서버를 적용하도록 하고 있다.

 

 

기존 SSL 및 TLS 동작방식(메인)

1) TCP 3Way Handshake

2) 클라이언트는 서버에게 지원 가능한 방식(암호, 키교환, 서명, 압축)방식을 서버에게 알려준다(Client Hello)

3) 서버는 클라이언트에게 지원 가능한 방식(암호, 키교환, 서명, 압축)방식에 응답해 준다(Server Hello) → 서버는 공개키(RSA 암호용)가 포함된 서버 인증서를 클라이언트에게 발송한다(Certificate Message) → 만약 서버가 클라이언트의 인증서를 요구할 때 이에 대한 요청도 함께 발송한다(선택사항) → 2와 3 중간의 옵션으로 클라이언트가 서버에게 인증하기 위한 Client Certificate 전송 과정이 포함될 수 있다 → ID와 패스워드를 이용한 로그인이 아닌 SSL 인증서를 통한 로그인을 지원하는 웹 사이트에 로그인 하기 위해서는 브라우저에 인증서를 등록해둬야 하는데 이때 등록해둔 SSL 인증서가 서버로 전송된다.

4) 서버의 3 전송이 마치면 Server Hello Done 메시지를 전달

5) (서버가 인증서를 요구할 경우) 인증서를 서버로 전송한다(3번 옵션 선택 사항에 해당하는 경우)

6) 클라이언트는 전송받은 서버 인증서에 대해 브라우저에 내장된 신뢰기간으로부터 발급 여부를 확인한 후(이 과정은 기간이 유효한지, 해당 서버에서 발급된 인증서인지 유무 확인 등을 포함한다) 세션키로 사용될 Pre-Master Key(후: 세션키(대칭키))를 랜덤으로 생성하여 공개키로 암호화 한 뒤 서버로 전송한다. 이때 Client Key Exchange메시지에 암호화된 Pre-Master Key(후: 세션키(대칭키))가 포함된다.

7) 서버는 자신의 개인키로 클라이언트에게 전송받은 암호화된 Pre-Master Key(후: 세션키(대칭키))를 복호화 한다.

8) 서버와 협상 과정에서 전송된 모든 메시지에 대해 방식(암호, 키교환, 서명, 압축)을 다음부터 적용할 것을 알리는 종결 메시지를 발송한 후 데이터 전송 단계로 이동한다.

9) 서버는 협상 과정에서 전송된 모든 메시지에 대하여 방식(암호, 키교환, 서명, 압축) 다음부터 적용하라 것을 알리는 종결 메시지를 발송한 후 데이터 전송 단계로 이동한다 → 클라이언트는 협상 과정에서 전송된 모든 메시지에 대해 방식(암호, 키교환, 서명, 압축)을 다음부터 적용할 것을 알리는 종결 메시지를 발송한 후 데이터 전송 단계로 이동한다. 이렇게 서로에게 ChageCipherSpec 메시지를 보내 앞으로 모든 통신 내용은 세션키(대칭키)를 이용해 암호화해 보낼 것을 알려준다.

10) 9단계까지 모두 정상적으로 완료 된다면 클라이언트와 서버 모두 동일한 세션키(대칭키)를 공유하게 된다.

11) 앞 단계에서 서로 공유된 세션키(대칭키)를 이용한 암호화된 전송 과정이 시작된다.

12) 통신이 끝나면 세션키는 폐기한다.

  - 위 내용 중에서 기본적으로 클라이언트가 선으로 SSL 통신을 요청하여 클라이언트 | 서버 양단에서 SSL 통신이 이루어지지만 2개가 세션을 맺지 않고(미러 방식 등, SW에서 복사된 패킷만 받는 경우) 서버에서 전달 받은 인증서(공개키 포함)을 클라이언트에 적용하고 클라이언트는 임의의 세션키를 만들고 공개키로 암호환 시킨 후 서버에게 전달하여 강제적으로 SSL 통신을 하도록 복호화를 유도하는 경우도 있다.

  - 인증서는 최초에 SSL 통신을 맺을 때만 사용되고, SSL Session이 맺고 난 이후에는 인증서의 역할은 없다(맺은 세션이 끊어질 때까지)

기존 SSL 밑 TLS 동작방식(보류)

1) 먼저 클라이언트에서 서버에 Client Hello 메시지를 보낸다 → 여기에는 클라이언트에서 가능한 TLS버전, 서버 도메인, 세션 식별자, 암호 설정 등의 정보가 포함된다

2) 클라이언트의 메시지를 받은 서버는 Server Hello메시지를 클라이언트에게 보낸다 → 여기에는 Client Hello 메시지의 정보 중 서버에서 사용하기로 선택한 TLS버전, 세션 식별자, 암호 설정 등의 정보가 포함된다.

3) 서버가 클라이언트에 Certificate 메시지를 보낸다 → 여기에는 인증서가 들어가는데 해당 인증서는 별도의 인증 기관에서 발급받은 것이며, 서버가 신뢰할 수 있는 자임을 인증한다. 전송이 끝나면 Server Hello Done 메시지를 보내 끝났음을 알린다.

4) 클라이언트는 서버에서 받은 인증서를 검증한다 → 인증서의 유효 기간이 만효되지 않았는지, 그 인증서가 해당 서버에게 발급된 인증서가 맞는지 등을 확인하며 확인 결과 인증서를 신뢰할 수 있다고 판단하면 다음 단계로 넘어간다

5) 클라이언트는 임의의 Pre-Master Secret을 생성한 뒤 서버가 보낸 인증서에 포함된 공개 키를 사용해 암호화 한다. 암호화 된 Pre-Master Secret을 ClientKeyExchange 메시지에 포함시켜 서버에 전송한다.

6) 서버는 전송받은 정보를 복호화하여 Pre-Master Secret을 알아낸 뒤, 이 정보를 사용해 Master Secret을생성한다. 생성한 뒤에는 Master Secret에서 세션키를 생성하고 이 세션키는 앞으로 서버와 클라이언트 간의 통신을 암호환 하는데 사용한다. 물론 클라이언트 역시 자신이 만들어 낸 Pre-Master Secret을 알고 있으므로 같은 과정을 거쳐 세션키를 스스로 만들 수 있다.

7) 이제 서버와 클라이언트는 각자 동일한 세션키를 가지고 있으며 이를 사용해 대칭키 암호를 사용하는 통신을 할 수 있다. 따라서 우선 서로에게 ChangeCipherSpec 메시지를 보내 앞으로의 모든 통신 내용은 세션키를 사용하여 암호화 하고 보낼 것을 알려준 뒤, Finished 메시지를 보내 각자의 Handshake 과정이 끝났음을 알린다.

8) 통신이 끝나면 세션키는 폐기한다. 

 

*추가 정보*

  - SSL은 IETF에 의해 사용중지 되었기에 대부분의 최신 브라우저는 이전 프로토콜을 지원하지 않는 경우가 대부분이므로 최신 브라우저에서 SSL의 사용은 환경이 저하될 우려가 있다. 때문에 SSL을 비활성화 하고 TLS를 활성화하도록 하는 것이 좋다.

  - 인증서와 프로토콜은 별개다. SSL 인증서를 TLS 인증서로 대체 해야 한다는 문제를 걱정할 필요가 없고, 의존하지 않는다는 것을 인지해야 한다. 프로토콜은 인증서가 아니라 서버 구성에 따라 결정되므로 "SSL 및 TLS와 함께 사용할 인증서"라고 하는 것이 좀 더 정확하다.

  - SSL과 TLS는 단순히 클라이언트와 서버간에 발생하는 Handshake를 나타내는 것이 아니며 암호화 자체를 수행하지 않는다. 공유되는 비밀 및 사용될 암호화 유형을 결정하는 절차를 진행하는 것이다.

  - SSL 프로토콜이 지원하는지 확인하기 위해 SSL 서버 테스트를 사용하여 확인 가능하다.

---

*TCP Handshake: 전송 제어 프로토콜(TCP)에서 통신을 하는 장치간 서로 연결이 잘 되어있는지 확인하는 과정, 방법.