2018.12.12

SSL/TLS의 이해와 TLS 1.3으로 업그레이드해야 하는 이유

Josh Fruhlinger |
웹 초창기부터, SSL(Secure Sockets Layer) 프로토콜과 그 후예인 TLS(Transport Layer Security)는 암호화와 보안을 제공해 인터넷 상거래를 가능하게 만들었다. SSL, TLS와 같은 프로토콜은 점점 더 정교해져 가는 사이버 공격 양상에 발맞춰 10년이 넘는 기간에 걸쳐 지속적으로 업데이트되어 왔다. 
 
ⓒ Getty Images Bank 

이제 곧 TLS의 차세대 메이저 버전인 TLS 1.3이 완성된다. 대부분 웹사이트는 사이버 범죄자들의 표적이 되지 않기 위해서라도 TLS 1.3으로 업그레이드하게 될 것이다. 
 

SSL의 의미 

SSL은 보안 소켓 계층의 약자로, 1990년대 중반 넷스케이프가 처음 개발한 것으로 데이터를 안전하게 전송하기 위한 인터넷 통신 규약 프로토콜이다. 넷스케이프는 당시 가장 유명한 웹 브라우저를 만든 업체이기도 하다. SSL 1.0은 일반에 공개되지는 않았다. SSL 2.0에는 심각한 결함이 있었고, 마침내 이런 결점들을 극복하고 출시된 SSL 3.0은 1996년 이후 생겨난 프로토콜들을 위한 기반을 닦았다.
 

TLS와 SSL의 관계 

1999년, SSL 프로토콜의 차세대 버전이 출시됐다. 이 프로토콜은 인터넷 엔지니어링 태스크포스(Internet Engineering Task Force, IETF)에 의해 표준화됐으며, 새로운 이름을 부여받았다. 그것이 바로 TLS(전송 계층 보안)다. TLS 규격을 보면 알 수 있듯이, 이 프로토콜과 SSL 3.0 사이에는 극적인 차이가 없다. 

이 때문에 중요한 것은 TLS냐, SSL냐의 양자 택일의 문제가 아니라 두 프로토콜이 지속적으로 업데이트되는 일련의 프로토콜들을 형성하며 SSL/TLS로 함께 묶여 분류된다는 사실이다.
 
TLS 프로토콜은 모든 종류의 인터넷 트래픽을 암호화한다. 가장 일반적으로는 웹 트래픽 암호화가 있다.

웹사이트 URL이 https로 시작하고, 연결이 안전하게 이뤄지고 있음을 알려주는 자물쇠 표시가 뜨면 이는 브라우저가 TLS를 통해 연결되어 있다는 의미다. 다음 화면은 크롬 브라우저에서 암호화가 되고 있다는 것을 의미한다. 

이 밖에도 TLS는 이메일이나 유즈넷 등의 애플리케이션에서도 사용할 수 있다.
 

SSL 작동 기전

인터넷 상에서 안전하게 통신하기 위해서는 암호화가 필요하다. 암호화되지 않은 데이터는 누구나 그 패킷을 검사하고 정보를 읽을 수 있다. 암호화 방법 가운데 가장 안전한 것은 비대칭 암호화(asymmetrical cryptography)다. 비대칭 암호화가 제대로 기능하려면 '퍼블릭'과 '프라이빗' 이 2개의 키가 필요하다. 여기서 '키'란, 숫자로 구성된 정보 조각들을 말한다. 

수학적으로 설명하려면 복잡하지만, 기본적으로 퍼블릭 키는 데이터를 암호화 하는데, 프라이빗 키는 이를 복호화하는 데 쓰인다고 보면 된다. 이 두개의 키를 연결하는 것은 역 설계(reverse-engineer)를 하기 어려운 복잡한 수식이다. 

퍼블릭 키는 우편함에, 프라이빗 키는 우편함을 여는 열쇠에 비유할 수 있다. 우편함 자체는 그것이 어디에 있는지만 알고 있으면 누구나 그 안에 우편물을 넣을 수 있다. 그러나 여기 담긴 우편물을 읽기 위해서는 우편함을 여는 열쇠가 필요하다.

비대칭 암호화는 이처럼 어려운 수학적 문제를 수반하기 때문에 많은 컴퓨팅 리소스를 필요로 한다. 만약 커뮤니케이션 세션 상의 모든 정보를 다 비대칭 암호화를 사용해 암호화하려 한다면 컴퓨터가 버텨내지 못할 것이다. 그래서 TLS는 커뮤니케이션 세션 시작부에서만 비대칭 암호화를 사용해 이 문제를 우회하는 데 성공했다. 서버와 클라이언트는 양측이 패킷 암호화에 사용하게 될 단일 세션 키에 대해 동의해야 한다. 

한편, 공유 키를 사용한 암호화 과정은 대칭 암호화(symmetrical cryptography)라고 불리며 이 경우 비대칭 암호화보다 훨씬 컴퓨팅 리소스를 덜 소모한다. 세션 키를 비대칭 암호화를 사용해 설정했기 때문에 커뮤니케이션 세션 전체는 훨씬 더 안전해진다.

이렇게 세션 키에 합의하는 과정을 일컬어 '핸드셰이크'라 부른다. 왜냐하면 이 때 2대의 컴퓨터가 처음 만나게 되며 이것이야말로 TLS 프로토콜의 핵심이라 할 수 있기 때문이다. 
 

SSL 핸드셰이크 프로세스

핸드셰이크 프로세스는 꽤 복잡하다. 또한 프로토콜은 핸드셰이크 프로세스의 다양한 변형을 허용하고 있다. 핸드셰이크 프로세스는 대략적으로 다음과 같은 단계들을 밟아 이뤄진다.

1. 클라이언트가 서버에 보안 연결을 요청한다. 서버는 사용 방법을 알고 있는 암호 모음(cipher suites, 암호화된 연결을 만드는 알고리즘 툴 킷)을 제공한다. 클라이언트는 이 목록을 자신이 가지고 있는 암호 모음(cipher suites)과 비교해 하나를 선택하고, 서버에 어떤 모음을 사용할 것인지 알린다. 

2. 서버는 클라이언트에게 자신의 신원을 확인해 줄, 서드파티 기관이 발급한 디지털 인증서(digital certificate)를 제공한다. 디지털 인증서에 대해서는 잠시 뒤에 자세히 설명하겠지만, 여기서 중요한 사실은 디지털 인증서가 서버의 퍼블릭 암호화 키를 내포하고 있다는 것이다. 클라이언트는 서버 인증서를 받아 그 진위를 확인한다.

3. 클라이언트와 서버는 퍼블릭 키를 사용해 나머지 세션에서 커뮤니케이션 암호화에 사용할 세션 키를 설정한다. 여기에는 여러 가지 기술이 사용될 수 있다. 예컨대 클라이언트가 퍼블릭 키를 사용해 무작위 숫자를 암호화한 후 이를 서버에 보내 복호화하고, 양측이 이 무작위 숫자를 사용해 세션 키를 설정하는 방식이 있다. 아니면 서버와 클라이언트가 디피-헬맨(Diffie-Hellman) 키 교환 방식을 사용해 세션 키를 설정할 수도 있다.

SSL.com에서는 깔끔한 다이어그램을 사용해 TLS 핸드셰이크 프로세스의 각 단계를 설명하고 있다.

이름만 봐도 짐작할 수 있지만, 세션 키는 중단없는 단일 커뮤니케이션 세션에 대해서만 유효하다. 어떤 이유에서든지 클라이언트와 서버 간 통신이 끊긴 경우(예컨대 네트워크 문제 또는 클라이언트의 유휴 상태로 인한 경우), 통신이 다시 이어지면 새로운 세션 키 설정을 위해 핸드셰이크 프로세스를 다시 시작해야 한다.
 

SSL 인증서의 의미 

SSL 인증서 개념에 대해 알아보자. 앞서 설명한 바와 같이, 이 인증서는 SSL/TLS 프로토콜의 핵심이라 할 수 있다. SSL 인증서는 안전한 연결을 시작하는 데 반드시 필요한 퍼블릭 암호화 키를 클라이언트에게 제공한다.

하지만 인증서의 기능은 단순히 키를 제공하는 것에 국한되지 않는다. 인증서는 퍼블릭 키가 그것을 제공하는 단체와 관련되어 있음을 클라이언트에게 증명해주는 역할을 한다.

인증서의 작동 기전은 다음과 같다. 우선, 인증서를 발급하는 기관은 CA(Certificate Authorities)라는 곳으로, CA는 신원 확인에 있어서는 여권 사무소와 비슷한 역할을 한다. TLS로 서비스를 암호화하려는 기관에서는 CA로부터 인증서를 구매해야 하며, CA는 해당 조직이 실제로 자신이 주장하는 그 단체가 맞는지를 확인한다. 

예를 들어, example.com이라는 웹사이트 보호를 위해 인증서를 구입하려 한다고 해보자. 이 경우 자신은 일련의 단계를 밟아 example.com 도메인을 제어한다는 사실을 CA에 증명해야 한다. 그렇게 해야 만약 누군가가 example.com에 연결했을 때 신뢰할 수 있는 CA에서 발부한 SSL 인증서를 보고 자신이 example.com의 합법적 소유자와 통신하고 있음을 확인할 수 있다. 이는 또한 중간자 공격을 예방한다.

앞서 '신뢰할 수 있는 CA(trusted CA)'라는 표현을 사용한 이유는 다음과 같다. 누구나 원한다면 인증 기관임을 자처할 수는 있다. 하지만 수많은 기관 가운데 어떤 기관이 고객 인증에 필요한 상당한 주의 의무를 다하고 있는지 어떻게 알 수 있을까. 

다행히도 이런 인증 기관 식별 작업은 소프트웨어 제조업체들이 해결하고 있다. 예컨대 모질라 재단에서는 파이어폭스가 신뢰하는 CA 목록을 제공하고 있으며, 마이크로소프트와 애플 역시 윈도우, 맥OS 및 iOS 등 플랫폼에서 크롬이 사용할 CA 목록을 가지고 있다. 

신뢰할 수 있는 CA를 선택하는 것은 무척 중요한 문제다. 2017년, SSL 인증서를 둘러싼 구글과 시만텍 간의 갈등에서 구글은 시만텍의 기준이 너무 느슨하다고 지적한 바 있다.

SSL 인증서를 정의하는 표준을 가리켜 X.509라고 한다. 이 표준 덕분에 이 인증서들은 퍼블릭 키와 인증서 소유자의 확인된 신원 외에도 많은 정보를 휴대할 수 있다. 디지서트(DigiCert)는 이런 표준에 대한 자세한 명세서를 담은 지식 기반의 CA다.
 

SSL 체커

앞서 설명한 정보의 교환 및 확인 과정은 TLS 암호화 연결을 제공하는 서버와 통신하는 과정에서 눈에 보이지 않는 곳에서 이뤄진다. 이에 대해 좀 더 많은 정보를 투명하게 얻고 싶다면 SSL/TLS 암호화 웹사이트 URL을 SSL 체커(SSL checkers) 웹사이트에 입력하면 된다. SSL 체커는 서버 형태를 포함해 해당 인증서를 신뢰하거나 하지않는 웹 브라우저, 인증서 발급자, 일련 번호, 그리고 만료일 등 해당 웹사이트 인증서에 대한 다양한 정보를 내놓을 것이다.

대부분의 SSL 체커는 CA에서 마케팅 전략의 일환으로 무료로 제공하고 있다. 또한 상당수 SSL 체커는 인증서 만료일에 맞춰 알람을 설정할 수 있도록 하고 있다. 물론 해당 인증서가 자신의 것이고, 만료일이 다가오면 새로운 인증서를 구매해야 한다는 전제 하에 말이다. 좀 더 상업성이 덜한 대안을 원한다면 퀄리스 SSL 랩스(Qualys SSL Labs)의 SSL 체커를 추천한다. 이 SSL 체커는 특히 웹사이트에 대한 탄탄한 정보 컬렉션을 제공한다.
 

TLS 1.2와 관련된 취약점 

TLS 1.2는 TLS 프로토콜 가운데 가장 최근에 정의된 버전으로 수년 전 출시됐다. TLS 1.2는 서버 클라이언트 간 통신을 위한 여러 가지 새로운 암호화 옵션을 제공하고 있다. 그러나 이전 버전이 그랬듯, 오래된 컴퓨터들을 지원해야 하므로 기존의 암호화 기술 사용도 허용하고 있다. 하지만 이로 인해 여러 가지 취약점이 생기게 되었는데, 기존 암호화 기술들은 시간이 지남에 따라 더더욱 공격에 취약해 지고, 컴퓨팅 파워는 더욱 저렴해지고 있기 때문이다. 

특히 TLS 1.2는 소위 중간자(Man in The Middle, MiTM) 공격에 갈수록 더 취약해지고 있다. MiTM 공격이란 해커가 커뮤니케이션 중간에 패킷을 가로채서 이를 읽거나 수정한 후에 송신하는 공격 방식을 말한다. TLS 1.2는 또한 POODLE(Padding Oracle On Downloaded Legacy Encryption), SLOTH(Security Losses from Obsolete and Truncated Transcript Hashes), 그리고 DROWN(Decrypting RSA with Obsolete and Weakened eNcryption) 공격에도 취약하다. 특히 지난 2년 동안 이런 취약점들이 불거져 나오면서 TLS 프로토콜 갱신이 더욱 시급해지고 있다.
 

TLS 1.3

다행히도, 희망은 있다. TLS 프로토콜의 버전 1.3은 현재 초안 상태이지만 곧 마무리될 예정이다. TLS 1.3은 레거시 암호화 시스템에 대한 불필요한 지원을 모두 제거함으로써 이런 취약점 가운데 상당 부분을 해소하고 있다. 만약 한 쪽이 TLS 1.3이 허용한 새로운 암호화 시스템을 사용할 수 없는 경우 TLS 1.2로 다시 되돌아간다는 점에서 역호환성이 있다고도 할 것이다. 그러나 공격자가 패킷을 엿보기 위해 강제로 TLS 1.2로의 전환을 시도할 경우 프로토콜은 이를 감지하고 연결을 끊는다.
 
아직도 TLS 1.2보다 더 오래된 버전을 사용하는 서버들도 있다. 이 가운데 일부는 아직까지 오리지널 SSL 프로토콜을 사용하기도 한다. 지금 사용하는 서버가 이런 경우라면, 당장 업그레이드할 것을 추천한다. 되도록이면 1.3 버전으로 말이다.
 

TLS를 사용한 크라임웨어

TLS 및 보안에 대해 마지막으로 알아야 할 사실은 이런 프로토콜을 사용하는 사람이 항상 선한 의도를 가진 사람은 아닐 수도 있다는 것이다. 실제로 많은 사이버 범죄자가 TLS를 사용해 피해자 컴퓨터에 설치된 악성코드와 서버 간 명령 및 제어 트래픽을 암호화하고 있다. 이로 인해 본래의 목적과는 달리 사이버 범죄의 피해자들이 오히려 트래픽을 복호화할 방법을 찾아야 하는 일도 발생한다. 

이런 식의 암호화 공격에 대처할 수 있는 방법이 몇 가지 있는데, 암호화 트래픽에 대한 네트워크 메타데이터를 사용해 공격자가 무엇을 하고 있는지 짐작해 보는 방법도 이 가운데 하나다. editor@itworld.co.kr 


/ SSL / TLS / 암호화
2018.12.12

SSL/TLS의 이해와 TLS 1.3으로 업그레이드해야 하는 이유

Josh Fruhlinger |
웹 초창기부터, SSL(Secure Sockets Layer) 프로토콜과 그 후예인 TLS(Transport Layer Security)는 암호화와 보안을 제공해 인터넷 상거래를 가능하게 만들었다. SSL, TLS와 같은 프로토콜은 점점 더 정교해져 가는 사이버 공격 양상에 발맞춰 10년이 넘는 기간에 걸쳐 지속적으로 업데이트되어 왔다. 
 
ⓒ Getty Images Bank 

이제 곧 TLS의 차세대 메이저 버전인 TLS 1.3이 완성된다. 대부분 웹사이트는 사이버 범죄자들의 표적이 되지 않기 위해서라도 TLS 1.3으로 업그레이드하게 될 것이다. 
 

SSL의 의미 

SSL은 보안 소켓 계층의 약자로, 1990년대 중반 넷스케이프가 처음 개발한 것으로 데이터를 안전하게 전송하기 위한 인터넷 통신 규약 프로토콜이다. 넷스케이프는 당시 가장 유명한 웹 브라우저를 만든 업체이기도 하다. SSL 1.0은 일반에 공개되지는 않았다. SSL 2.0에는 심각한 결함이 있었고, 마침내 이런 결점들을 극복하고 출시된 SSL 3.0은 1996년 이후 생겨난 프로토콜들을 위한 기반을 닦았다.
 

TLS와 SSL의 관계 

1999년, SSL 프로토콜의 차세대 버전이 출시됐다. 이 프로토콜은 인터넷 엔지니어링 태스크포스(Internet Engineering Task Force, IETF)에 의해 표준화됐으며, 새로운 이름을 부여받았다. 그것이 바로 TLS(전송 계층 보안)다. TLS 규격을 보면 알 수 있듯이, 이 프로토콜과 SSL 3.0 사이에는 극적인 차이가 없다. 

이 때문에 중요한 것은 TLS냐, SSL냐의 양자 택일의 문제가 아니라 두 프로토콜이 지속적으로 업데이트되는 일련의 프로토콜들을 형성하며 SSL/TLS로 함께 묶여 분류된다는 사실이다.
 
TLS 프로토콜은 모든 종류의 인터넷 트래픽을 암호화한다. 가장 일반적으로는 웹 트래픽 암호화가 있다.

웹사이트 URL이 https로 시작하고, 연결이 안전하게 이뤄지고 있음을 알려주는 자물쇠 표시가 뜨면 이는 브라우저가 TLS를 통해 연결되어 있다는 의미다. 다음 화면은 크롬 브라우저에서 암호화가 되고 있다는 것을 의미한다. 

이 밖에도 TLS는 이메일이나 유즈넷 등의 애플리케이션에서도 사용할 수 있다.
 

SSL 작동 기전

인터넷 상에서 안전하게 통신하기 위해서는 암호화가 필요하다. 암호화되지 않은 데이터는 누구나 그 패킷을 검사하고 정보를 읽을 수 있다. 암호화 방법 가운데 가장 안전한 것은 비대칭 암호화(asymmetrical cryptography)다. 비대칭 암호화가 제대로 기능하려면 '퍼블릭'과 '프라이빗' 이 2개의 키가 필요하다. 여기서 '키'란, 숫자로 구성된 정보 조각들을 말한다. 

수학적으로 설명하려면 복잡하지만, 기본적으로 퍼블릭 키는 데이터를 암호화 하는데, 프라이빗 키는 이를 복호화하는 데 쓰인다고 보면 된다. 이 두개의 키를 연결하는 것은 역 설계(reverse-engineer)를 하기 어려운 복잡한 수식이다. 

퍼블릭 키는 우편함에, 프라이빗 키는 우편함을 여는 열쇠에 비유할 수 있다. 우편함 자체는 그것이 어디에 있는지만 알고 있으면 누구나 그 안에 우편물을 넣을 수 있다. 그러나 여기 담긴 우편물을 읽기 위해서는 우편함을 여는 열쇠가 필요하다.

비대칭 암호화는 이처럼 어려운 수학적 문제를 수반하기 때문에 많은 컴퓨팅 리소스를 필요로 한다. 만약 커뮤니케이션 세션 상의 모든 정보를 다 비대칭 암호화를 사용해 암호화하려 한다면 컴퓨터가 버텨내지 못할 것이다. 그래서 TLS는 커뮤니케이션 세션 시작부에서만 비대칭 암호화를 사용해 이 문제를 우회하는 데 성공했다. 서버와 클라이언트는 양측이 패킷 암호화에 사용하게 될 단일 세션 키에 대해 동의해야 한다. 

한편, 공유 키를 사용한 암호화 과정은 대칭 암호화(symmetrical cryptography)라고 불리며 이 경우 비대칭 암호화보다 훨씬 컴퓨팅 리소스를 덜 소모한다. 세션 키를 비대칭 암호화를 사용해 설정했기 때문에 커뮤니케이션 세션 전체는 훨씬 더 안전해진다.

이렇게 세션 키에 합의하는 과정을 일컬어 '핸드셰이크'라 부른다. 왜냐하면 이 때 2대의 컴퓨터가 처음 만나게 되며 이것이야말로 TLS 프로토콜의 핵심이라 할 수 있기 때문이다. 
 

SSL 핸드셰이크 프로세스

핸드셰이크 프로세스는 꽤 복잡하다. 또한 프로토콜은 핸드셰이크 프로세스의 다양한 변형을 허용하고 있다. 핸드셰이크 프로세스는 대략적으로 다음과 같은 단계들을 밟아 이뤄진다.

1. 클라이언트가 서버에 보안 연결을 요청한다. 서버는 사용 방법을 알고 있는 암호 모음(cipher suites, 암호화된 연결을 만드는 알고리즘 툴 킷)을 제공한다. 클라이언트는 이 목록을 자신이 가지고 있는 암호 모음(cipher suites)과 비교해 하나를 선택하고, 서버에 어떤 모음을 사용할 것인지 알린다. 

2. 서버는 클라이언트에게 자신의 신원을 확인해 줄, 서드파티 기관이 발급한 디지털 인증서(digital certificate)를 제공한다. 디지털 인증서에 대해서는 잠시 뒤에 자세히 설명하겠지만, 여기서 중요한 사실은 디지털 인증서가 서버의 퍼블릭 암호화 키를 내포하고 있다는 것이다. 클라이언트는 서버 인증서를 받아 그 진위를 확인한다.

3. 클라이언트와 서버는 퍼블릭 키를 사용해 나머지 세션에서 커뮤니케이션 암호화에 사용할 세션 키를 설정한다. 여기에는 여러 가지 기술이 사용될 수 있다. 예컨대 클라이언트가 퍼블릭 키를 사용해 무작위 숫자를 암호화한 후 이를 서버에 보내 복호화하고, 양측이 이 무작위 숫자를 사용해 세션 키를 설정하는 방식이 있다. 아니면 서버와 클라이언트가 디피-헬맨(Diffie-Hellman) 키 교환 방식을 사용해 세션 키를 설정할 수도 있다.

SSL.com에서는 깔끔한 다이어그램을 사용해 TLS 핸드셰이크 프로세스의 각 단계를 설명하고 있다.

이름만 봐도 짐작할 수 있지만, 세션 키는 중단없는 단일 커뮤니케이션 세션에 대해서만 유효하다. 어떤 이유에서든지 클라이언트와 서버 간 통신이 끊긴 경우(예컨대 네트워크 문제 또는 클라이언트의 유휴 상태로 인한 경우), 통신이 다시 이어지면 새로운 세션 키 설정을 위해 핸드셰이크 프로세스를 다시 시작해야 한다.
 

SSL 인증서의 의미 

SSL 인증서 개념에 대해 알아보자. 앞서 설명한 바와 같이, 이 인증서는 SSL/TLS 프로토콜의 핵심이라 할 수 있다. SSL 인증서는 안전한 연결을 시작하는 데 반드시 필요한 퍼블릭 암호화 키를 클라이언트에게 제공한다.

하지만 인증서의 기능은 단순히 키를 제공하는 것에 국한되지 않는다. 인증서는 퍼블릭 키가 그것을 제공하는 단체와 관련되어 있음을 클라이언트에게 증명해주는 역할을 한다.

인증서의 작동 기전은 다음과 같다. 우선, 인증서를 발급하는 기관은 CA(Certificate Authorities)라는 곳으로, CA는 신원 확인에 있어서는 여권 사무소와 비슷한 역할을 한다. TLS로 서비스를 암호화하려는 기관에서는 CA로부터 인증서를 구매해야 하며, CA는 해당 조직이 실제로 자신이 주장하는 그 단체가 맞는지를 확인한다. 

예를 들어, example.com이라는 웹사이트 보호를 위해 인증서를 구입하려 한다고 해보자. 이 경우 자신은 일련의 단계를 밟아 example.com 도메인을 제어한다는 사실을 CA에 증명해야 한다. 그렇게 해야 만약 누군가가 example.com에 연결했을 때 신뢰할 수 있는 CA에서 발부한 SSL 인증서를 보고 자신이 example.com의 합법적 소유자와 통신하고 있음을 확인할 수 있다. 이는 또한 중간자 공격을 예방한다.

앞서 '신뢰할 수 있는 CA(trusted CA)'라는 표현을 사용한 이유는 다음과 같다. 누구나 원한다면 인증 기관임을 자처할 수는 있다. 하지만 수많은 기관 가운데 어떤 기관이 고객 인증에 필요한 상당한 주의 의무를 다하고 있는지 어떻게 알 수 있을까. 

다행히도 이런 인증 기관 식별 작업은 소프트웨어 제조업체들이 해결하고 있다. 예컨대 모질라 재단에서는 파이어폭스가 신뢰하는 CA 목록을 제공하고 있으며, 마이크로소프트와 애플 역시 윈도우, 맥OS 및 iOS 등 플랫폼에서 크롬이 사용할 CA 목록을 가지고 있다. 

신뢰할 수 있는 CA를 선택하는 것은 무척 중요한 문제다. 2017년, SSL 인증서를 둘러싼 구글과 시만텍 간의 갈등에서 구글은 시만텍의 기준이 너무 느슨하다고 지적한 바 있다.

SSL 인증서를 정의하는 표준을 가리켜 X.509라고 한다. 이 표준 덕분에 이 인증서들은 퍼블릭 키와 인증서 소유자의 확인된 신원 외에도 많은 정보를 휴대할 수 있다. 디지서트(DigiCert)는 이런 표준에 대한 자세한 명세서를 담은 지식 기반의 CA다.
 

SSL 체커

앞서 설명한 정보의 교환 및 확인 과정은 TLS 암호화 연결을 제공하는 서버와 통신하는 과정에서 눈에 보이지 않는 곳에서 이뤄진다. 이에 대해 좀 더 많은 정보를 투명하게 얻고 싶다면 SSL/TLS 암호화 웹사이트 URL을 SSL 체커(SSL checkers) 웹사이트에 입력하면 된다. SSL 체커는 서버 형태를 포함해 해당 인증서를 신뢰하거나 하지않는 웹 브라우저, 인증서 발급자, 일련 번호, 그리고 만료일 등 해당 웹사이트 인증서에 대한 다양한 정보를 내놓을 것이다.

대부분의 SSL 체커는 CA에서 마케팅 전략의 일환으로 무료로 제공하고 있다. 또한 상당수 SSL 체커는 인증서 만료일에 맞춰 알람을 설정할 수 있도록 하고 있다. 물론 해당 인증서가 자신의 것이고, 만료일이 다가오면 새로운 인증서를 구매해야 한다는 전제 하에 말이다. 좀 더 상업성이 덜한 대안을 원한다면 퀄리스 SSL 랩스(Qualys SSL Labs)의 SSL 체커를 추천한다. 이 SSL 체커는 특히 웹사이트에 대한 탄탄한 정보 컬렉션을 제공한다.
 

TLS 1.2와 관련된 취약점 

TLS 1.2는 TLS 프로토콜 가운데 가장 최근에 정의된 버전으로 수년 전 출시됐다. TLS 1.2는 서버 클라이언트 간 통신을 위한 여러 가지 새로운 암호화 옵션을 제공하고 있다. 그러나 이전 버전이 그랬듯, 오래된 컴퓨터들을 지원해야 하므로 기존의 암호화 기술 사용도 허용하고 있다. 하지만 이로 인해 여러 가지 취약점이 생기게 되었는데, 기존 암호화 기술들은 시간이 지남에 따라 더더욱 공격에 취약해 지고, 컴퓨팅 파워는 더욱 저렴해지고 있기 때문이다. 

특히 TLS 1.2는 소위 중간자(Man in The Middle, MiTM) 공격에 갈수록 더 취약해지고 있다. MiTM 공격이란 해커가 커뮤니케이션 중간에 패킷을 가로채서 이를 읽거나 수정한 후에 송신하는 공격 방식을 말한다. TLS 1.2는 또한 POODLE(Padding Oracle On Downloaded Legacy Encryption), SLOTH(Security Losses from Obsolete and Truncated Transcript Hashes), 그리고 DROWN(Decrypting RSA with Obsolete and Weakened eNcryption) 공격에도 취약하다. 특히 지난 2년 동안 이런 취약점들이 불거져 나오면서 TLS 프로토콜 갱신이 더욱 시급해지고 있다.
 

TLS 1.3

다행히도, 희망은 있다. TLS 프로토콜의 버전 1.3은 현재 초안 상태이지만 곧 마무리될 예정이다. TLS 1.3은 레거시 암호화 시스템에 대한 불필요한 지원을 모두 제거함으로써 이런 취약점 가운데 상당 부분을 해소하고 있다. 만약 한 쪽이 TLS 1.3이 허용한 새로운 암호화 시스템을 사용할 수 없는 경우 TLS 1.2로 다시 되돌아간다는 점에서 역호환성이 있다고도 할 것이다. 그러나 공격자가 패킷을 엿보기 위해 강제로 TLS 1.2로의 전환을 시도할 경우 프로토콜은 이를 감지하고 연결을 끊는다.
 
아직도 TLS 1.2보다 더 오래된 버전을 사용하는 서버들도 있다. 이 가운데 일부는 아직까지 오리지널 SSL 프로토콜을 사용하기도 한다. 지금 사용하는 서버가 이런 경우라면, 당장 업그레이드할 것을 추천한다. 되도록이면 1.3 버전으로 말이다.
 

TLS를 사용한 크라임웨어

TLS 및 보안에 대해 마지막으로 알아야 할 사실은 이런 프로토콜을 사용하는 사람이 항상 선한 의도를 가진 사람은 아닐 수도 있다는 것이다. 실제로 많은 사이버 범죄자가 TLS를 사용해 피해자 컴퓨터에 설치된 악성코드와 서버 간 명령 및 제어 트래픽을 암호화하고 있다. 이로 인해 본래의 목적과는 달리 사이버 범죄의 피해자들이 오히려 트래픽을 복호화할 방법을 찾아야 하는 일도 발생한다. 

이런 식의 암호화 공격에 대처할 수 있는 방법이 몇 가지 있는데, 암호화 트래픽에 대한 네트워크 메타데이터를 사용해 공격자가 무엇을 하고 있는지 짐작해 보는 방법도 이 가운데 하나다. editor@itworld.co.kr 


/ SSL / TLS / 암호화
X