HTTPS프로토콜이란? (SSL,TLS)

HTTPS란?

-보안에 취약했던 HTTP의 보안 버전입니다.SSL/TLS 프로토콜을 사용하여 클라이언트와 서버간의 통신을 암호화하여 데이터를 안전하게 전송할 수 있게 합니다. 중간자 공격과 같은 보안 위협으로 부터 데이터를 보호하고, 웹사이트에서 서버의 SSL 인증서를 받아와 해당 정보를 신뢰할 수 있는지 없는지를 확인시켜주는 프로토콜입니다.

 

SSL이란?

-웹사이트와 사용자 사이에서 암호화된 연결을 제공하는 인터넷 보안 프로토콜입니다. 공개키 암호화 방식을 사용하며, 공개키는 모든 클라이언트에게 공개되어있으며, 개인키는 서버만 가지고 있습니다. 공개키를 사용하여 암호화를 한 값은, 개인키를 사용하여 복호화 할 수 있습니다.

 

TLS란?

-SSL에서 업데이트된 버전입니다. SSL과 같이 대칭키와 공개키 암호화 기술을 사용하며 SSL과 같이 데이터 통신 보안을 위해 설계된 암호화 프로토콜입니다. 이해하기 쉽게 SSL에서 업그레이된 버전이 TLS이고, 현재는 TLS만 쓴다. 라고 생각하면 됩니다. 최신버전인 TLS 1.3은 더 강력한 암호화 및 보안 기능을 제공합니다.

 

 

 

 

자, 그러면 이 TLS는 왜 생겨났으며, 어떻게 쓰일까요??

 

SSL/TLS가 생겨난 배경은 다음과 같습니다. 아주 과거에는 HTTP로 서로 통신을 하였습니다. 초창기에는 데이터 송수신만 하면 됐기에, HTTP통신으로 통신을 시작해도 아무런 문제가 없었습니다. 
하지만, 점차 기술이 발전하게 되면서 중간에 HTTP 메세지를 탈취하여 정보를 빼가는 이른바 '해커'들이 생겨났습니다. HTTP는 보안이 없기때문에 해당 메세지가 그대로 해커에게 노출되는 상황이 벌어집니다. 

이때, 저희는 이거에 대한 대안으로 '대칭키'와 '비대칭키'로 암호화를 하면 해결되지 않을까? 라는 생각을 하였고, 이를 기반으로 컴퓨터간 서로 메세지를 암호화 하기쉽게 규칙을 정하여 시작한게 SSL/TLS이고, 이를 활용한 프로토콜이 HTTPS입니다. 

다음은 SSL/TLS 프로토콜의 구조이며, 해당 프로토콜은 Transport Layer(4계층), Application Layer(7계층)의 사이에 위치 해 있습니다.

 

 

 

 

SSL(TLS) 프로토콜

 

해당 TLS 내부구조의 프로토콜은 각각의 TLS과정에서 쓰이는 프로토콜이 다릅니다. 
즉,TLS 과정마다 프로토콜이 변환 되어서 각각 다른 프로토콜이 쓰입니다.

• Handshake Protocol(핸드셰이크 프로토콜)
  - 클라이언트와 서버간 통신 시작전에 3-way 핸드셰이크를 합니다.
  - 핸드셰이크 과정에서 클라이언트와 서버간 서로 인증을 하고, 암/복호화에 사용할 key를 공유합니다.
• Cipher Change Protocol
  -핸드셰이크에서 서로간 암호화 방법에 대한 협상을 마친 후, 실제 데이터 전송이 시작되기전에 보내는 메세지입니다.
  -암호화 통신이 시작된다는 것을 상대방에게 알리는 역할을 하는 프로토콜입니다.
  
  
• Alert Protocol
  -통신할때 발생하는 오류, 예외 상황을 전달할 때 사용하는 프로토콜입니다.
  -문제를 감지하면 'Alert'메세지를 상대방에게 전송하여 통신을 중단하거나, 조치를 취합니다.
  
  
• Record Protocol(레코드 프로토콜)
  -핸드셰이크가 완료된 후, 실제 데이터 전송을 Record Protocol을 사용합니다.
  -레코드 프로토콜은 원래 데이터를 블록으로 나눈 후, 각각 암호화하여 전달합니다.
  -암호화에는 대칭키(세션키)가 사용되며, 이를 통해 안전하고 효율적인 데이터 전송을 보장합니다.

 

 

 

 

이렇게 SSL/TLS의 프로토콜을 알아보았고,  각 프로토콜이 어떻게 쓰이는지를 알게 되었습니다. 이렇게 각 프로토콜의 사용법에 대해 알아보았으니, 다음은 SSL/TLS의 동작과정에 대해서 알아보겠습니다.
SSL/TLS의 동작과정은 크게 연결 -> 통신 -> 종료로 나뉘어지며, 자세한 과정은 다음과 같습니다.

 

 

 

SSL(TLS) 과정

1. Client Hello
   -클라이언트가 서버에 접속할때 자신의 데이터를 주며 인사를 하는과정입니다.
   클라이언트가 생성한 랜덤 데이터와 클라이언트가 현재 지원가능한 암호화 방식을 서버에게 전달하는데 주요 내용은 다음과 같습니다.
   • random
     -클라이언트가 생성한 32바이트 랜덤값으로, 나중에 master secret 세션키를 생성하는 재료입니다.
   • session ID
     -세션을 처음 생성할때는 빈값, 이미 전에 생성된 세션이 있다면 해당 세션ID를 전달합니다.
   • cipher suite
     -클라이언트가 자신이 가능한 암호화 알고리즘을 전달합니다.
     (이때 클라이언트는 암호화방식을 지원하는것이 서버에 비해 많지 않음)
     
     
2. Server Hello
   -클라이언트의 메세지를 받은 서버가 응답으로 똑같이 인사를 하는 과정입니다.
   이때, 서버가 생성한 랜덤데이터와 인증서,공개키 , 암호화 방식을 클라이언트에게 전달하는데 주요 내용은 다음과 같습니다.
   • random
     -서버가 생성한 32바이트 랜덤값으로, 나중에 master secret 세션키를 생성하는 재료입니다.
   • session ID
     -세션 값을 보냅니다. 클라이언트로부터 이전 세션ID를 받았다면, 해당 세션 값을 보내고, 전의 세션값이 없다면 새로운 세션 값을 만들어 클라이언트에게 보내게 됩니다.
   • server certificate
     -클라이언트가 서버를 신뢰할 수 있게, 서버의 인증서를 보냅니다. 이 인증서는 CA가 인증한 인증서로, 공식적으로 인증받은 서버의 인증서이며, 인증서 내부엔 서버의 공개키가 포함되어있습니다.
   • server key exchange
     -키 교환에 필요한 정보를 제공합니다. 만약 키교환이 필요하지 않다면 이 과정은 생략가능합니다.
   • certificate request
     -서버가 클라이언트 인증이 필요한 경우 클라이언트에게 인증서를 요구합니다. 이 과정도 생략이 가능합니다.
     (서버는 지원하는 암호화방식이 매우많아 클라이언트에 맞출 수 있음)
     
     
3. 인증서 인증, premaster secret 암호화
   -Server hello에서 요청한 클라이언트의 인증서 인증과, 클라이언트와 서버가 각각 생성한 random값 2개를 조합해 pre-master secret값을 생성하는 과정입니다. 자세한 사항은 다음과 같습니다.
   • 서버 인증서 복호화 
     -Server hello에서 받은 서버의 인증서를, 클라이언트가 가지고 있는 CA 공개키를 이용해 복호하합니다.
     이때, 만약 복호화가 되지않는다면, 서버의 인증서가 잘못된 것으로, 서버를 신뢰할 수 없는 상태입니다.
     (CA의 공개키는 클라이언트의 내부 OS에 저장되어있습니다.)
   • premaster secret 생성
     -클라이언트가 생성한 random값과 서버가 생성한 random값을 조합하여 premaster secret 키를 생성합니다.
     -premaster secret키의 생성 방법은 보통 RSA,Diffie-Hellman 방식을 주로 사용합니다.
     
     
     
4. premaster secret 전송
   -클라이언트 본인이 생성한 premaster secret를 서버의 공개키로 암호화 하여 서버에 전송을 합니다.
   -서버가 클라이언트 인증서를 요청한 상황이라면 클라이언트 인증서도 함께 보내게 됩니다.
   
   
5. premaster secret 복호화
   -서버는 본인이 가지고 있는 본인의 개인키로 클라이언트가 보낸 데이터를 복호화 하여 정보를 가집니다.
   (이 때, 정상적으로 복호화가 된 경우, 클라이언트와 서버는 동일한 premaster secret를 가지고 있습니다.)
   
   
6. session key 생성
   -서버와 클라이언트 둘다 각자 동일하게 가지고 있는 premaseter secret값을 HMAC 처리를 하여 서로 동일한 session key 만듭니다. 이 세션 키는 서버와 클라이언트가 연결되는 동안 유지되는 세션키이며, 연결이 종료될 때 폐기합니다.
   
   
7. 서로 데이터 통신
   -생성된 session key를 이용해 대칭키 방식으로 활용해 데이터를 암호화 하여 주고받습니다.
   -세션키(대칭키) 방식으로 암/복호화를 진행하기에 공개키 암호화 과정보다 속도가 빠릅니다.
   
   
8. 세션종료
   -세선종료되면서 세션키는 버립니다.

 

 

 

자, 이렇게 SSL/TLS의 원리와 동작과정을 알아보았는데, 굉장히 복잡해 보이지않나요?  우리가 이렇게 인터넷을 사용하면서 통신을 할때 이 과정을 하나하나씩 계속 해야한다는건데, 너무 복잡하고 어려운 과정같은데 이것을 왜 해야할까요? 이 SSL/TLS의 장점은 다음과 같습니다.

 

SSL/TLS의 장점

• KEY 탈취 안정성
  SSL/TLS는 세션키를 이용해 서로 암호화를 하여 통신을 진행합니다. 이후, 연결이 끊기면 세션키도 버리는데요.
  만약, 세션키를 사용하지않는다면, 나중에 외부에서 우리의 개인키를 탈취했을 시, 우리가 지금동안 통신했던 기록이 다 털리게 됩니다. 
  하지만,세션키를 사용해서 나중에 키를 탈취당했을 시에도, 일정 통신마다 세션키가 달라 기록이 털리는 범위를 줄여주게됩니다.
• 빠른 암/복호화 속도
  -우리가 만약 공개키와 개인키로 암/복호화를 한다고 가정하면, 굉장히 암호화와 복호화가 편합니다. 또한 개인키가 탈취당하지만 않는다면 안전합니다.
  다만, 이 과정에는 한가지 문제점이 있습니다. 바로, 암/복호화 속도가 느리다는건데요......우리가 흔히 사용하는 웹페이지에서도 이 과정을 거쳐서 진행해야하는데 속도가 느리면 사용자들의 불만이 터져나올겁니다.
  따라서,굳이굳이 이렇게 복잡하게 서로 같은 세션키를 가져 대칭키처럼 암/복호화를 하여 통신을 진행하는 것입니다. 
  
  
• 클라이언트/서버 인증
  -우리가 통신할때, 상대방이 믿을만한 개체인지 확인을 해야합니다. 현실세계에선 직접 대면으로 만나기 때문에 서로 확인을 할 수 있지만, 인터넷에서는 그것이 불가능 하기때문에 '인증서'라는 것을 통해 클라이언트와 서버가 서로 인증을 할 수 있습니다.
  만약 이 과정에서 인증이 되지않는다면, 추가 조치를 취하거나, 통신을 시작하지않아 위험을 없애는 작업을 진행할 수 있습니다.