[네트워크] TLS/SSL HandShake

TLS / SSL 이란?

SSL(Secure Sockets Layer)은 보안 프로토콜로서, 개인정보 보호, 인증, 무결성 을 인터넷 통신에 제공한다. 

• SSL/TLS를 사용하는 웹사이트의 URL에는 "HTTP" 대신 "HTTPS" 가 있다.
• SSL 이란 명칭은 TLS(Transport Layer Security)로 발전했다.
  • 최근 명칭: TLS(Transport Layer Security)
  • 과거 명칭: SSL(Secure Sockets Layer)

• SSL의 인지도가 크기 때문에 TLS을 SSL로 부르며 사용한다.
• Certificate Authority(CA)라 불리는 서드 파티로부터 서버와 클라이언트의 인증을 하는데 사용된다.
• 주로 전송계층과 응용계층 사이에서 보안조치를 하는데 사용하게 된다.

 

SSL (Secure Sockets Layer)

웹사이트와 브라우저 사이(또는 두 서버 사이)에 전송되는 데이터를 암호화하여 인터넷 연결을 보호하기 위한 표준 보안 프로토콜이다.

• 해커가 개인 데이터나 금융 데이터 등의 전송되는 정보를 보거나 훔치는 것을 방지한다.
• 우 통신 장치 사이에 HandShake라는 인증 프로세스를 시작하여 두 장치의 ID를 확인한다.
• 데이터 무결성을 제공하기 위해, 데이터에 디지털 서명을 하여 데이터가 의도된 수신자에게 도착하기 전에 조작되지 않았다는 것을 확인한다.

 

TLS (Transport Layer Security)

인터넷을 통해 서로 통신하는 클라이언트 서버 응용 프로그램 간의 통신 보안을 제공하는 프로토콜이다.

• SSL의 향상된, 더욱 안전한 버전이다.
• SSL 의 발전이며 추가 개인 정보 보호 및 보안 기능으로 구성된다.

 

 

SSL 인증서란?

클라이언트와 서버간의 통신을 제 3자가 보증화 해주는 전자화된 문서이다.

• 통신 내용이 공격자에게 노출되고 악의적으로 변경되는 것을 막고 서버의 신뢰성을 올릴 수 있다.

 

SSL 인증서의 목표

• 클라이언트가 접속한 서버가 신뢰 할 수 있는 서버인지를 판단한다.
• SSL 통신에 사용될 공개키를 클라이언트에게 전달한다.

 

SSL인증서에 들어있는 내용은? (두 가지)

1. 서비스의 정보 (인증서를 발급한 CA, 서비스의 도메인 등)
2. 서버측 공개키

CA(Certificate Authority) 란?
SSL인증서를 기준으로 클라이언트가 접속한 서버가 클라이언트가 의도한 서버가 맞는지를 확인을 하게 된다.
이러한 일을 해주는 공인된 회사들을 CA라고 한다.
이러한 CA는 브라우저가 리스트를 가지고 있고 이 CA들의 공개키들을 가지고 있다

 

인증서로 서버가 신뢰할 수 있는지 어떻게 판단할까?

공개키 서명방식을 사용한다.

우리가 사용하는 일반적인 브라우저에 신뢰할 수 있는 CA 기관의 리스트와 해당 기관의 공개키를 이미 가지고 있다.

그래서 클라이언트는 내장된 CA의 공개 키를 활용하여 인증서를 복호화함으로써 인증서를 검증한 뒤, 서버의 공개 키를 가져올 수 있다.

 

웹 브라우저가 서버에 접속한다면

1. 서버는 SSL 인증서를 제공한다. 이 인증서에는 서버측의 공개키와 서비스의 정보를 담고있다.
2. 브라우저는 이 인증서를 발급한 CA가 자신의 CA리스트에 있는지 확인한다.
3. 있다면 CA의 해당 공개키를 이용해서 인증서를 복호화한다.
4. 복호화가 된다면 이 인증서는 CA의 비공개키에 의해 암호화 되었다는 것을 알 수 있다.

 

공개키와 대칭키 방식

1. 대칭키

그림을 보자. 그림을 보게 되면 두 사람은 하나의 내용을 주고 받을 때 암호화 후 내용을 전달하고 복호화를 하여 읽게 된다.그리고 이 때 같은 키(대칭키)를 사용하는 방식이다. 이 경우 대칭키가 있게 되면 내용을 모두 읽을 수 있게 된다. 속도가 빠른 장점이 있지만 만약 누군가가 이 대칭키를 악의적으로 가진다면 내용을 별다른 노력없이 볼 수 있게 된다.

 

2. 공개키 

그림을 보게 되면 오른쪽에 글을 읽고 있는 사람을 서버(데이터를 받는 수신 측)이라고 보겠습니다. 그리고 이 수신측에는 수신측만 가지는 private key를 가질 수 있습니다. 데이터를 암호화 할 때 어떤 키를 사용하느냐에 따라 암호의 의미를 가질지 서명의 의미를 가질 지 고민해 볼 수 있습니다.

• 공개키 암호: 암호로 사용될 경우 공개 공개키를 가지고 내용을 암호화 하게 됩니다. 그리고 이 내용은 private key를 가진 경우에만 열람이 가능해 집니다.
• 공개키 서명: 서명 용도로 사용 될 경우 private key를 가지고 암호를 하게 됩니다. 그리고 이 내용은 공개키를 통해 열 수 있게 되는데 이 경우 공개키를 가지는 누구나 이 내용을 열 수 있게 되지만 이 내용을 어느 쪽에서 서명 된 것인지 알 수 있게 됩니다. 브라우저에서는 이 방식을 사용하게 됩니다.

 

 

TLS / SSL HandShake

HTTPS에서 클라이언트와 서버간의 통신 전에 SSL 인증서로 신뢰성 여부를 판단하기 위한 연결 방식이다.

 

TLS / SSL Handshake의 동작 과정

Client 와 Server 간 TCP 를 거쳐 TLS 까지 Handshake 하는 과정이다.
파란색 부분 은 TCP 의 3-way handshake 주황색 부분 은 TLS-handshake 가 그려져 있다.

 

파란색 칸과 노란색 칸은 네트워크 상에서 전달되는 IP 패킷을 표현한 것이다. 파란색 칸에 해당하는 SYN, SYN ACK, ACK는 TCP 레이어의 3-way handshake로, HTTPS가 TCP 기반의 프로토콜이므로 SSL Handshke에 앞서 연결을 생성하기 위해 실시하는 과정이다. 노란색 칸에 해당하는 패킷들이 SSL Handshake라고 보면 된다.

 

TLS / SSL Handshake 진행 순서

 

 

1. 클라이언트는 서버에게 "client hello" 메시지를 암호화된 정보와 함께 전송한다.
   이때 암호화된 정보에는 버전, 암호 알고리즘, 압축 방식, 등을 담는다.
2. 서버는 클라이언트가 보낸 암호 알고리즘, 압축 방식 을 받는다.
   그 후, 세션 ID, CA 공개 인증서 를 "server hello"메시지와 함께 담아 클라이언트에게 응답한다.
   이 CA 인증서에는 앞으로 HandShake(연결) 이후에 사용할 대칭키가 생성되기 전, 클라이언트에서 HandShake 과정 속 암호화에 사용될 공개키를 담고 있다.
3. 클라이언트 측은 서버에서 보낸 CA 인증서에 대해 유효한 지 CA 목록에서 확인하는 과정을 진행한다.
4. CA 인증서에 대한 신뢰성이 확보되었다면, 클라이언트는 난수 바이트를 생성하여 서버의 공개키로 암호화한다.
   이 난수 바이트는 대칭키를 정하는데 사용이 되고, 앞으로 서로 메시지를 통신할 때 암호화하는데 사용된다.
5. 만약 2번 단계에서 서버가 클라이언트 인증서를 함께 요구했다면, 클라이언트의 인증서와 클라이언트의 개인키로 암호화된 임의의 바이트 문자열을 함께 보내준다.
6. 서버는 클라이언트의 인증서를 확인 후, 난수 바이트를 자신의 개인키로 복호화 후 대칭 마스터 키 생성에 활용한다.
7. 클라이언트는 handshake 과정이 완료되었다는 finished 메시지를 서버에 보내면서, 지금까지 보낸 교환 내역들을 해싱 후 그 값을 대칭키로 암호화하여 같이 담아 보내준다.
8. 서버도 동일하게 교환 내용들을 해싱한 뒤 클라이언트에서 보내준 값과 일치하는 지 확인한다. 일치하면 서버도 마찬가지로 finished 메시지를 이번에 만든 대칭키로 암호화하여 보낸다.
9. 클라이언트는 해당 메시지를 대칭키로 복호화하여 서로 통신이 가능한 신뢰받은 사용자란 걸 인지하고, 앞으로 클라이언트와 서버는 해당 대칭키로 데이터를 주고받을 수 있게 된다.

---

참고 자료

https://steady-coding.tistory.com/512

https://velog.io/@osk3856/TLS-Handshake

https://hanjungv.github.io/2017-11-07-1_CS_SSL/

https://velog.io/@yuseogi0218/TLS-SSL-HandShake