[Knowledge] SSL/TLS 프로토콜과 Cipher Suite의 이해

들어가기 전

SSL/TLS와 Cipher Suite를 자세히 이해하기 위해 그리고 취약점을 진단할 때 반드시 기억해야하는 사항들을 정리하기 위해 글을 쓴다.

---

본문

1. SSL/TLS 이란?

SSL과 TLS는 같은 의미의 단어이다.

우리가 흔히 인터넷을 사용할 때 https를 이용한 인터넷 접속은 SSL(TLS)을 이용한 것이다.

• SSL 암호화 통신은 'SSL(Secure Socket Layer) 또는 TLS(Transport Layer Security)'라는 보안 프로토콜을 통해 클라이언트와 서버 간의 보안이 향상된 통신을 말한다.
• SSL/TLS는 브라우저(사용자의 컴퓨터)와 서버(웹사이트) 사이의 암호화된 연결을 수립하는 데 사용된다.

---

2. SSL/TLS Protocol 

2.1 SSL/TLS Protocol

SSL Handshake 기반이 되는 SSL/TLS Protocol의 버전을 의미한다. 보통 SSLv3, TLSv1.0, TLSv1.1, TLSv1.2 등이 있지만 최근 TLSv1.0과 TLSv1.1의 지원이 종료되어 TLSv1.2 이상을 쓸 것을 권고하고 있다.

 

2.2 SSL Handshake

HTTPS 통신과정에서도 송신자와 수신자가 암호화 통신을 하기 위한 방법과 수단에 대해 공유한다.

HTTPS 통신과정에서 한 쌍의 공개키와 개인키가 있다.

 

송신자와 수신자가 암호화된 데이터를 교환하기 위한 일련의 협상과정을 의미한다. 협상과정에서 SSL 인증서 전달, 대칭키(비밀키) 전달, 암호화 알고리즘 결정, SSL/TLS 프로토콜 결정 등이 포함된다.

 

※ 추가

서버에서 SSL로 암호화를 진행 할 때 암/복호화를 인증서를 통해서 진행을 하는데, 해당 인증서에서 어떤 언어를 쓰고 어떤식으로 암호화 할건지는 평문으로 서로 전달을 한다. 그래서 우리가 인증서를 확인해 보면 어떤식으로 암호화를 하는지 나와있는 이유 중 하나이다.

 

2.3 SSL/TLS Protocol 구조

SSL/TLS는 보안 계층이라는 독립적인 프로토콜 계층을 만들어 응용계층과 전송계층 사이에서 동작한다.

 

이때 응용계층의 프로토콜들은 외부로 보내는 데이터를 TCP가 아닌 SSL에 보내게 되고, SSL은 받은 데이터를 암호화한 후 TCP에 보내어 외부 인터넷으로 전달하게 된다.

 

전달받을 때 역시, TCP로부터 받은 데이터를 복호화하여 응용계층에 전달하게 되는데, 이 과정에서 Application은 SSL을 TCP로 인식하고, TCP는 SSL을 Application으로 인식한다.

 

HTTPS는 SSL 또는 TLS 위에 HTTP 프로토콜을 얹어 보완된 HTTP 통신을 하는 프로토콜이다. 즉, SSL과 TLS는 HTTP뿐만 아니라 FTP, SMTP와 같이 다른 프로토콜에도 적용할 수 있다. 

 

※ 추가

1. 데이터링크 계층은 암호화를 하지 않는다.

2. 네트워크 계층은 암호화를 하는 경우가 있고, 아닌 경우도 있다. 만약 하게 된다면 VPN을 쓰는 경우일 것이다.

3. 전송 계층은 SSL로 암호화를 진행한다.

4. 우리가 Burp Suite라는 도구를 이용하여 패킷을 잡아서 보는 것도 전송계층 위쪽 부분들을 보는 것이다.

---

3. SSL 통신 절차

1. 서버가 클라이언트에게 서버 인증서를 보낸다. (이때 클라이언트 인증을 필요로 할 경우 클라이언트의 인증서를 전송하게 됨)

2.  클라이언트는 받은 서버 인증서를 분석하여 신뢰할 수 있는 인증서인지를 검토한 후, 서버의 공개키를 추출한다.

3. 클라이언트가 세션키로 사용할 임의의 메시지를 서버의 공개키로 암호화하여 서버에 전송한다.

4. 서버에서는 자신의 개인키로 세션키를 복호화하여 그 키를 사용하여 대칭키 암호방식으로 메시지를 암호화하여 클라이언트와 통신하게 된다.

 

 

SSL 통신을 하고 있는데 Burp에서는 Request 값이 평문으로 보일까? (자동으로 MITM 공격을 해줌)

1. 서버가 클라이언트에게 서버 인증서를 보낸다. 예를 들어 서버가 구글이라고 한다면 클라이언트는 서버가 구글이 맞는지를 확인해야한다. 그래서 서버는 CA에서 보장한 CA인증서로 전자서명으로 인증된 서버 인증서를 보내게 되며 서버 인증서와 CA인증서를 같이 보낸다. (CA = 가장 큰 인증기관) 

 

2. 그러면 클라이언트는 서버 인증서를 확인하여 누가 확인했는지 검토하게 된다 → CA에서 확인했다는 것을 알게된다. → 인증된 서버라는 것을 알 수 있다.

 

3. 그러면 또 CA인증서가 맞다는 것은 어떻게 아는가? → 클라이언트에는 이미 맞는 CA인증서가 PC에 다 설치되어 있는데 서버가 보낸 CA 인증서와 클라이언트에 설치되어 있는 CA 인증서를 비교 해서 파일이 존재한다면 맞다는 것을 확인한다.

 

4. 이런식으로 이제 통신을 하게되는데 이를 통해 우리가 Burp Suite라는 해킹툴을 이용할 때 CA인증서를 다운 받아 클라이언트 또는 단말기에 설치를 진행하는데 왜 그 과정이 팔요한지 알 수 있다.

 

5. Burp를 클라이언트에 인증 시키기 위해 설치하는 것이며 이제 맞다는 것을 확인했으니 서버와 키공유가 된다.

 

6. 암호화 통신을 하게 되며 SSL 통신으로 키교환을 하고 키를 이용해서 암호화에 접근하여 통신을 한다.

 

7. 클라이언트와 서버의 중간에 존재하는 burp는 키를 가지고 있으니 SSL 암호화를 사용하는데도 우리가 평문으로 보이는 이유 중 하나이다.

 

8. 클라이언트 → Burp → 서버 : Burp는 사이에서 SSL을 통해 클라이언트에게는 서버인척을 하며 서버에게는 클라이언트인 척을 한다.

 

그렇다면 공격자가 burp 처럼 중간자 공격을 할 수 없을까?

공격자가 통신에 껴서 중간자 공격을 하려고 하면 해당 인증서가 클라이언트에 설치되어 있어야 하는데 해당 인증서를 클라이언트에 설치할 수 없다. → 그렇다고 못하는 건 아니다.  CA문서로 MITM 공격을 하려고하면 브라우저에서 "통신을 신뢰할 수 없습니다" 경고가 뜨는데 여기서 사용자가 무시하기 위해서 계속해서 통신을 굴리면 통신이 성립되서 → 중간에서 볼 수 있게 된다. → 이걸 못보게 하기 위해서 브라우저에서 SSL 사용에 대한 경고창을 띄우는 것이다.

---

 

4. TLS/SSL Cipher Suite

4.1 Cipher Suite란 무엇인가

Cipher Suite란 TLS/SSL 암호통신을 하는 데 사용되는 암호 알고리즘 집합을 의미한다.

취약한 HTTPS 관련 취약점을 점검할 때 SSL Scanner 등을 이용해서 확인할 때 만날 수 있는 것이 바로 Cipher Suite이다.

 

비대칭키 암호화를 이용해서 인증, 키교환 한 다음 키교환이 되면 대칭키 암호화로 암호화 통신을 한다.

 

(A) 키 교환 알고리즘: 서버와 클라이언트 간 Key를 교환할 방식을 선정하는 것

(B) 인증 알고리즘: 서버와 클라이언트 간 교환한 인증서를 확인하는 알고리즘

(C) 대칭 암호 알고리즘: 실제 데이터를 암호화하는 알고리즘

(D) 블록 암호 운용 방식: 데이터를 암호화할 때 한꺼번에 암호화 하는 것이 아니라 블록 단위로 암호화하게 됨

(E) 해시 알고리즘: 상대방이 암호화한 것이 맞는지 확인하기 위한 알고리즘

 

예시: TLS_DHE_RSA_WITH_AES_128_CBC_SHA

TLS 프로토콜을 사용하며, 키교환 방식은 DHE, 인증알고리즘은 RSA, 대칭알고리즘으로 AES를 사용하며 암호키 길이는 128비트, 블록 암호의 운용모드는 CBC이고 메시지 인증 코드를 계산하는 해시 알고리즘은 SHA를 사용한다는 것이다.

---

마무리

해당 포스터에 제가 잘못된 정보를 알고 있는 경우 댓글로 알려주시면 감사하겠습니다.