[Network] HTTS 통신 과정 파헤치기(1) - TLS/SSL

이번 글에서는 TLS/SSL handshake에 대해 정리해보겠습니다.

 

intro

본격적인 설명에 앞서서 이번 글을 정리하는 배경을 

간단하게 설명해볼까 합니다.

 

저희 회사에서 운영하는 서비스 중

정말 오래된 몇몇 레거시 서비스에서

3DES 알고리즘 등과 같은 몇가지 보안 취약점이 발견되었습니다.

 

이번 글은 위의 보안 취약점을 비활성화하는 과정을 공유드릴까 합니다.

HTTPS와 TLS/SSL

본격적으로 문제 해결 과정을 설명하기 전에

글을 이해하기 위한 기초지식을 최대한 간략하게 살펴보겠습니다.

 

HTTPS는 HyperText Tranfer Protocol over Secure socket layer의 약어로,

직역하자면 Secure socket layer 위에서 동작하는 HTTP 프로토콜을 의미합니다. 

 

그렇다면 'Secure socket layer 위에서 동작'한다는 것은

무엇을 의미하는 걸까요?

 

이를 위해서는 먼저, SSL/TLS에 대해 알아볼 필요가 있습니다.

SSL(Secure Sockets Layer)

SSL(Secure Sockets Layer)는 네트워크로 연결된 컴퓨터간에

인증되고 암호화 된 된 데이터를 전달하기위한 프로토콜입니다.

TLS(Transport Layer Security)

이후 SSL은 3.0 버전에서 1999년,

TLS 1.0버전으로 재정의 및 표준화 되었습니다.

 

SSL 3.0과 TLS 1.0은 기능상으로 큰 차이는 없지만

동시에 사용될 수 없을 만큼 이 둘을 구분하는 것은 중요합니다.

 

TLS는 이후로도 계속 새로운 버전이 릴리즈되었고

가장 최근 버전은 1.3입니다.

 

그렇다면 위 프로토콜은 어떠한 방식으로 동작할까요?

 

TLS handshake(출처: https://medium.com/@vanrijn/what-is-new-with-tls-1-3-e991df2caaac)

 

위 그림은 TLS 1.2 / 1.3 handshake 과정을 도식화 한 것입니다.

 

해당 과정을 통해 우리가 하고 싶은 것은 결국,

HTTPS를 통해 정보를 전달하는 것이고

handshake는 이를 위한 과정입니다.

 

그렇다면 HTTPS를 통해 정보를 전달하기 위해서는

무엇이 필요할까요?

 

다시 그림으로 돌아가서,

(여기서는 TLS v1.3을 기준으로 설명하겠습니다.)

client는 client hello라는 메세지와 함께 

client가 지원하는 암호화 알고리즘, 키 교환 방법 등을 server에게 보냅니다.

 

위 메세지를 받은 server는 client가 보낸 정보를 기반으로

public key, 암호화 방식(cipher suite)를 전달합니다.

 

이후에 client는 보내는 데이터들을 암호화하여 server 주고받게 됩니다.

 

간략하게 설명하기 위해 많은 부분이 생략되어 있지만

중요한 것은, handshake는 데이터를 암호화하여 주고받기 위해

server와 client가 합의하는 과정이라는 것,

 

그리고 위에서 설명한 'Secure socket layer 위에서 동작'한다는 것은

위와 같은 암호화 과정을 거쳐 데이터를 주고받는 다는 것입니다.

DES / 3DES

다음으로는 문제가 된 보안 취약점에 대해 알아보겠습니다.

DES

DES(Data Encryption Standard)는 1974년 IBM에서 제작되어

1977년 미국 국제 표준으로 제정된 암호화 알고리즘입니다.

 

DES에서 사용하는 암호화 키 길이는 56비트로,

해당 알고리즘이 탄생한 시기에는 충분히 안전하였지만

컴퓨팅 능력이 좋아진 지금은 쉽게 해독이 가능하다는 문제점을 가지고 있습니다.

3DES

3DES(Triple DES)는 이름에서 알 수 있듯이

DES 암호화 알고리즘을 세 번 수행한 암호화 알고리즘입니다.

 

암호화과정이 복잡한만큼 DES에 비해서는 안전하다고 볼 수 있지만

그럼에도 불구하고 3DES 역시 몇가지 보안 취약점을 가지고 있어,

NIST(미국 국립표준기술연구소)에서는  2023년부터 해당 알고리즘의 사용을 중지할 계획입니다.

 

 

다음글에서는 본격적으로

위 보안 취약점을 비활성화했던 경험에 대해 설명하도록 하겠습니다.

Reference

• https://www.ssl.com/ko/faqs/faq-what-is-ssl/
• https://www.a10networks.com/blog/key-differences-between-tls-1-2-and-tls-1-3/
• https://tools.ietf.org/html/rfc8446#section-4
• https://hyolo.tistory.com/8
• https://www.nist.gov/
• https://csrc.nist.gov/News/2017/Update-to-Current-Use-and-Deprecation-of-TDEA
• https://www.cryptomathic.com/news-events/blog/3des-is-officially-being-retired
• www.fsec.or.kr/common/proc/fsec/bbs/42/fileDownLoad/1605.do