SSL/TLS 알아 보기

안녕하세요. HYEN입니다.

이번에는 Application Gateway SSL 인증서를 적용하여 저와 동기가 만든 Web Server를 https를 이용해서 접근해 보려고 하던 도중, 대체 SSL이 무엇인가! 하는 궁금증이 생겨 공부해 보았습니다. 😎

---

Contents

1. SSL와 TLS란?

• SSL(Secure Socket Layer; 보안 전송 계층)
  • 암호화 기반 인터넷 보안 프로토콜로 웹사이트와 브라우저 사이 또는 두 서버 사이에 전송되는 데이터를 암호화하여 인터넷 연결을 보호하기 위한 표준 기술입니다. 
  • OSI 계층 모델 중 응용 계층과 전송 계층 사이에서 동작하여 애플리케이션 데이터를 보호하고 이를 전송 계층으로 보내는 역할을 합니다. 

 

• TLS(Transport Layer Security; 전송 계층 보안)
  • SSL의 업데이트 버전 (cf. TLS 1.0은 SSL 3.0을 계승함)

➡️ 따라서 SSL과 TLS는 같은 역할을 하는 프로토콜이라고 볼 수 있습니다. 

 

 

TLS 및 SSL 프로토콜을 사용할 경우 클라이언트 및 서버 애플리케이션에서는 메시지 변조, 메시지 가로채기, 메시지 위조 등의 보안 위험을 감지할 수 있습니다. 

 

그렇다면, 대체 SSL/TLS 프로토콜은 이러한 보안 위험을 어떻게 감지하는 걸까요?

바로 SSL/TLS 프로토콜은 암호화, 해시화, 디지털 인증서라는 3가지 기술을 조합하여 사용하여 보안 위험을 감지하는데요. 여기서 해시화에 대해 잠깐 알아보고 가도록 하겠습니다. 

해시화란?
- 애플리케이션 데이터를 고정된 크기의 고유한 값으로 변환하는 기술로 데이터에 작은 변경이 발생해도 결과 해시 값이 크게 변하도록 설계되어 있어 제 3자가 데이터를 바꾸어 쓰는 변조를 감지할 수 있습니다. 
- 해시값은 데이터를 요약한 것이기 때문에 해시값이 유출 되더라도 보안 상 문제는 없습니다.

 

 

이와 같은 기술들을 통해 SSL/TLS 프로토콜이 제공하는 보안 요소는 다음과 같습니다. 

• Confidentiality (기밀성)
  • 인가된 사람들에게만 데이터를 공개하는 것
  • Client와 Server가 서로 주고 받는 데이터는 오직 Client와 Server만 볼 수 있어야 한다는 것을 의미합니다. 
    
    
• Integrity (무결성)
  • 네트워크 상 송, 수신되는 데이터가 임의로 수정되거나 위, 변조되지 않아야 하는 것을 의미합니다.
  • 정보는 변경이 허락된 주체에 의해 인가된 방법을 통해서만 변경되어야 하기 때문이죠.
    
    
• Authentication (인증)
  • 주체의 자격이나 내용을 검증하는 것으로 데이터에 접근할 수 있는 객체인지, 정당한 객체인지 확인되어야  합니다.

 

2. TLS 및 SSL Protocol Stack

TLS 및 SSL 프로토콜은 두 가지 계층으로 나뉘어 집니다.

https://commons.wikimedia.org/wiki/File:TLS_protocol_stack.svg

 

2.1 상위 계층

2.1.1 Handshake Protocol

• Client와 Server가 서로 암호화 통신을 시작할 수 있도록 서로 확인하고 필요한 정보를 서로 주고 받는 과정을 의미합니다. 
• 어떤 TLS 버전을 사용할 것인지, 어떤 암호화 알고리즘을 사용할 것인지 협상하고, Server와 Client의 인증서를 통해 인증하고, 공개키를 공유 (보통 RSA 암호화 알고리즘 사용)합니다. 

 

지금부터는 Handshake 프로토콜의 Flow를 좀 더 자세하게 알아보겠습니다. (RSA 암호화 알고리즘을 기준으로 작성하였습니다.)

Security Deployment in TR-069 CPE WAN Management Protocol - Scientific Figure on ResearchGate

 

1. Client Hello
   • Client는 Server에 접속하여 자신이 사용할 SSL/TLS 버전, Cipher Suite List(Client가 지원하는 암호화 방식), 세션 ID, 초기 랜덤 넘버(추후 대칭키 생성에 사용됨)를 포함한 Client Hello라는 패킷을 Server에게 보냅니다.
     
     
2. Server Hello
   • Server에서 사용하는 SSL/TLS 버전, Client가 보낸 암호화 방식 중 Server가 사용할 수 있는 암호화 방식을 선택(Selected Suite)하여 보냅니다. → 협상
   • Server에서 생성한 랜덤 넘버 (추후 대칭키 생성에 사용됨) 및 세션 ID도 함께 보냅니다. 
   • Client Hello와 거의 동일함
     
     
3. Server Certificate
   • Server의 Certificate을 Client에게 보냅니다. 
     • 인증서 내부에는 Server가 발행한 공개키가 들어 있습니다. 
     • Client는 Server가 보낸, CA(Certificate Authority)의 개인 키로 암호화된 Certificate을, CA의 공개키를 사용하여 복호화 합니다. → 복호화 여부를 통해 Certificate 진위 여부를 검증할 수 있습니다.
   • Client는 Server의 Certificate에 대한 무결성을 검증한 후 검증이 되었다면 데이터 암호화에 사용할 대칭키를 생성하게 됩니다. 
     
     
4. Server Key Exchange
   • Server의 공개키가 Certificate 내부에 없는 경우, Server가 직접 공개키를 전달하게 됩니다.
   • 만약 공개키가 Certificate 내부에 있을 경우 이 과정은 생략된다고 보시면 됩니다. 
     • Certificate 내부에 공개키가 있다면 3번의 CA의 공개키를 사용하여 Certificate를 복호화 하는 과정에서 이미 Server의 공개키를 확보하였을 것이기 때문이죠. 
       
       
5. Server Hello Done
   • Server의 Hello 절차가 완료되었음을 Client에게 전송하기 위한 메시지입니다. 
     
     
6. Client Certificate (optional)
   • Client의 인증서를 Server에 전송하는 과정입니다. 
     
     
7. Client Key Exchange
   • Client는 3번 과정에서 생성한 대칭키를 Server가 보낸 Certificate 내부에 들어 있던 공개키로 암호화 하여 Server에게 전송합니다. 
   • 대칭키는 데이터를 실제로 암호화하는 키를 의미합니다. 
     • 이 키를 통해 Client와 Server는 교환하고자 하는 데이터를 암호화 할 수 있습니다. 
       
       
8. Change Cipher Spec
   • 이 이후로 전송되는 모든 메시지에 대해서 정해진 암호화 알고리즘과 키를 사용하여 암호화 하겠다고 알리는 패킷입니다.
   • Client와 Server가 서로에게 날리는 패킷으로 교환할 정보를 모두 교환한 후 통신 준비 완료를 알리는 역할을 하죠. 
     
     
9. Finished
   • SSL/TLS Handshake가 성공적으로 끝나서 이를 종료한다는 의미를 담은 패킷입니다. 

 

2.1.2 Change Cipher Spec Protocol

• Handshake 과정 중 Client와 Server 간의 통신에서 암호화된 부분을 나타내는 신호 역할을 합니다. 
  
  
• Handshake 프로토콜의 일부로 간주되며 이 메시지 이후 Client와 Server 간의 통신은 새로운 암호화 및 보안 매개변수를 사용하게 됩니다. 

 

2.1.3 Alert Protocol

• SSL/TLS 통신 과정에서 발생하는 오류 및 경고 상황을 알리고 대응하기 위한 프로토콜로, Client와 Server 간 오류 및 경고 메시지를 교환하는데 사용됩니다.
  
  
• Alert Level에는 Fatal(치명적)과 Warning(경고) 총 두 가지 Level이 존재 합니다. 
  
  • Fatal
    • 이 경우 connection이 즉시 끊어집니다.
    • ex. 인증에 실패했을 때, 프로토콜 버전이 호환되지 않을 때 등
      
      
  • Warning
    • 일반적인 경고 메시지입니다. 
    • ex. 암호화 키의 유효 기간이 다가왔을 때, 암호화 알고리즘의 안전하지 않은 사용 등

 

2.2 하위 계층

2.2.1 Record Protocol

• 데이터의 기밀성, 무결성 및 인증을 위한 프로토콜로, SSL/TLS 세션에서 데이터의 보호를 담당하며 Handshake 프로토콜에서 협상된 보안 매개변수에 따라 데이터의 암복호화, 인증 및 압축을 수행합니다.
  
  • 암호화 : Handshake 과정에서 협상된 대칭키를 사용하여 데이터를 암호화합니다.
  • 무결성 : MAC(Message Authentication Code)을 사용하여 데이터의 무결성을 보장합니다.
  • 압축 : 선택적으로 데이터를 압축하여 전송할 수 있습니다. 
    
    
• 이 프로토콜에 의해 암호화 및 인증 처리된 데이터는 TCP와 같은 전송 계층(L4) 프로토콜에 의해 전송됩니다. 

 

여기서 MAC은 또 뭘 의미하는 걸까요? 🫠 빠르게 알아보도록 하겠습니다.

MAC(Message Authentication Code)
- 해시 함수와 유사하나 더 많은 보안 기능을 제공하는, 메시지의 무결성과 인증을 확인하기 위한 코드입니다.
- 주로 대칭키 암호화에서 사용되며, 특히 데이터 전송 중 메시지 변조를 탐지하는 데 활용됩니다. 

 

 

주로 HMAC(Hash-based Message Authentication Code)가 흔히 사용되는데요. HMAC의 특징은 다음과 같습니다. 

• 해시 함수를 기반으로 하면서 키를 사용하여 보안 수준을 높임
• 대칭키 암호화 방식 사용
• 메시지에 대한 내부 해시를 계산하고, 외부에서 추가된 키를 사용하여 한 번 더 해시를 수행함

 

3. SSL Temination이란?

https://commons.wikimedia.org/wiki/File:SSL_termination_proxy.svg#/media/File:SSL_termination_proxy.svg

 

• 부하 분산 장치의 옵션 기능의 하나로 Server에서 수행하던 SSL 처리를 부하 분산 장치에서 수행하는 기능을 의미하며, 암호화, 복호화에 필요한 작업을 부하 분산 장치에 위임하는 것으로 SSL Offloading이라고도 합니다. 
  
  
• Client가 HTTPS로 request하면 그 request를 받은 부하 분산 장치에서 SSL 처리를 하고 부하 분산 대상 Server에는 HTTP로 전달하게 됩니다. 
  • 부하 분산 장치는 Client로부터 받은 암호화된 트래픽을 해독하고, clear text 데이터로 변환합니다. 
  • 부하 분산 장치는 해독된 clear text를 Server로 전송합니다. (이 구간의 통신은 암호화 X)
    
    
• 부하 분산 장치에서 SSL Offloading이 이루어지므로 부하 분산 장치가 SSL/TLS 암호화 및 복호화를 처리할 수 있는 기능을 가지고 있어야 합니다. 
  
  
• Server가 SSL 처리를 하지 않아도 되기 때문에 처리 부하가 감소한다는 장점이 있습니다. 

---

이상으로, 간단하게 SSL/TLS에 대해 알아보았습니다. 

다음에는 실제로 Azure Application Gateway에 SSL 인증서를 적용하는 과정에 대해 알아보도록 하겠습니다. 🎶