28번째 초안, 최종 표준으로 통과...구글 등은 이미 적용 시작
호환성과 보안, 퍼포먼스 고려해 미리 시험 기간 거쳐야
[보안뉴스 문가용 기자] 암호화 통신의 최신 표준인 TLS 1.3의 도래가 눈앞으로 다가왔다. 국제인터넷표준화기구(Internet Engineering Task Force, IETF) 산하 네트워크 워킹 그룹(Network Working Group)이 TLS 1.3에 대한 28번째 초안이 최종 표준으로 통과되었다고 발표했기 때문이다.
여기에 더해 오픈SSL(OpenSSL)은 소프트웨어 라이브러리 1.1.1 버전에 이미 28번째 초안을 추가하기도 했다. 구글의 크롬 브라우저도 65 버전부터는 28번째 초안에 대한 지원 기능을 포함하고 있다. 크롬을 통해 지메일에 접속하면 기본적으로 28번째 초안이 작동하기 시작한다. 기다리고 기다리던 TLS 1.3이 드디어 모습을 드러내기 시작한 것이다.
새로운 표준을 도입하려면 조직들은 세 가지 중요한 사안에 집중해야 한다.
1) 0-RTT라고 알려진 ‘제로 라운드 트립 타임’을 어떻게 적용할 것인가?
2) TLS 1.2 다운그레이드
3) 인프라 및 애플리케이션 실험의 필요성
라운드 트립?
TLS 1.3 버전에서 가장 많이 다뤄지는 주제 중 하나가 바로 0-RTT 옵션이다. 엔드포인트 간 암호화된 세션이 진행될 때 속도를 크게 향상시켜주는 것이다. 사실 TLS 1.3 버전은 핸드셰이크 프로토콜이 이전보다 간소화 되어 있어, 0-RTT 없이도 클라이언트와 서버 간 통신 속도가 높다.
TLS 1.2 버전으로 웹 통신을 보호하는 경우, 클라이언트와 서버 간 두 번 왕복(round trip)을 해야 클라이언트가 HTTP 요청을 서버로 보내고, 서버가 그에 대한 응답을 보낼 수 있었다. 하지만 TLS 1.3에서는 이를 한 번의 왕복으로 줄여준다. 또한 클라이언트와 서버 간 신뢰가 형성될 경우 왕복의 필요성이 0으로 줄어든다. 그게 바로 0-RTT다.
0-RTT 옵션은 보안보다는 퍼포먼스를 위한 옵션이다. 그렇기 때문에 보안 구멍으로 비춰지기도 한다. 라운드 트립이 하나도 없는 환경에서는 어떠한 거래라도 쉬운 목표물이 될 수 있다. 공격자들은 암호화된 클라이언트 메시지를 가로채고 이를 다시 서버로 자기들이 임의로 전송할 수 있게 된다. 그럼으로써 서버의 ‘신뢰’ 구조를 자신들에게 유리하게 작동시키는 것이다.
그러니 TLS 1.3을 도입해야 하는 각 조직은 0-RTT의 이러한 위험성을 이해하고, 인터넷을 통해 제공하는 서비스와 애플리케이션들을 먼저 손봐야 한다. 개발자들이 특히 이 문제에 민감하게 반응해야 하는데, 0-RTT의 안전한 도입을 위해서는 능동적인 보안 점검 및 실험이 필요하기 때문이다. 속도가 대단히 민감한 부분이 아니라면 0-RTT 옵션은 비활성화시키는 것도 나쁘지 않은 선택이다.
다운그레이드
TLS 1.3 버전의 가장 큰 장점 중 하나는 오래된 암호화 표준이나 솔루션을 더 이상 지원하지 않는다는 것이다. 하지만 TLS 1.2로의 하위 호환은 가능하게 만들어준다. 물론 표준을 바꾼다고 했을 때 호환성 문제 때문에 이전 버전에 대한 지원을 유지하는 건 필수적인 일이다. 그러나 호환성에서 문제가 발생했다고 해서 곧바로 TLS 1.2로 다운그레이드 하기 보다는, 다른 환경설정부터 먼저 점검해야 한다. 다운그레이드는 정말 최후의 최후까지 가서 써볼 수 있는, 어쩔 수 없을 때 꺼내야 하는 카드일뿐이다.
그리고 다운그레이드를 했다고 해서 TLS 1.2에 머물러서는 안 된다. 거기서부터 암호화 알고리즘이나 솔루션을 보다 더 강력하고, 1.3 버전과 호환이 되는 것과 차근차근 바꿔나가야 한다. 그래서 결국에는 TLS 1.3으로 되돌아오는 것이 필요하다. 강력한 암호화 알고리즘이란 타원 곡선 암호 키 교환이나 대형 비대칭 키 방식 등을 말한다. 또한 완전 순방향 비밀성도 도입해야 한다.
실험, 실험, 실험
다운그레이드도 문제지만, 새것이라면 무조건 도입부터 하고 보는 것도 문제다. 그러니 TLS 1.3으로 갈아타기 전에 현존하는 인프라와 앱들을 충실히 실험해보는 것이 필요하다. 사실 바로 지금이 이러한 실험의 가장 적절한 시기라고 볼 수 있다. 암호화 시스템을 바꾼다는 건 시스템과 인프라에 큰 무리가 가는 일일 수 있다. 그러므로 실험을 통해 충분히 대비하고 실제 변화를 적용시켜야 한다.
가장 먼저는 호환성을 실험해야 한다. 그 다음이 보안이며, 그 다음이 퍼포먼스다. 이 세 가지가 가장 아름답게 구현되는 절충점을 찾는 게 실험의 목표다. 셋 중 그 어느 것도 간과될 수 없으며, 하나를 살리기 위해 다른 하나를 죽이는 일도 있어서는 안 된다. 보통 보안이 많이 희생이 되는데, 절대로 피해야 할 일이다.
실험을 할 땐 현실적인 트래픽들을 적용해보고, 내부 사용자와 외부 사용자 모두의 피드백을 얻어내야 한다. 내부 직원들은 물론 고객, 파트너사, 그 외 모든 관련자들의 의견을 최대한 듣는 데 시간을 할애해야 한다. 모바일 기기와 태블릿들을 포함한 네트워크 클라이언트들을 실험에 참가시키고, 서버들 여기 모두 실험 대상이 되어야 한다. 보안 장비들도 마찬가지다.
TLS 1.3이 본격적으로 도입되기 시작하면 보안과 퍼포먼스 모두가 강화될 것으로 예상된다. 또한 현재 사용되고 있는 암호화 기술이 일으키는 수많은 문제들 역시 해결될 것으로 업계는 기대하고 있다. 그러니 지금 초안이 돌아다닐 때 미리 대비하고 준비하다.
글 : 데이비드 디산토(David DeSanto), Spirent
[국제부 문가용 기자(globoan@boannews.com)]
호환성과 보안, 퍼포먼스 고려해 미리 시험 기간 거쳐야
[보안뉴스 문가용 기자] 암호화 통신의 최신 표준인 TLS 1.3의 도래가 눈앞으로 다가왔다. 국제인터넷표준화기구(Internet Engineering Task Force, IETF) 산하 네트워크 워킹 그룹(Network Working Group)이 TLS 1.3에 대한 28번째 초안이 최종 표준으로 통과되었다고 발표했기 때문이다.
[이미지 = iclickart]
여기에 더해 오픈SSL(OpenSSL)은 소프트웨어 라이브러리 1.1.1 버전에 이미 28번째 초안을 추가하기도 했다. 구글의 크롬 브라우저도 65 버전부터는 28번째 초안에 대한 지원 기능을 포함하고 있다. 크롬을 통해 지메일에 접속하면 기본적으로 28번째 초안이 작동하기 시작한다. 기다리고 기다리던 TLS 1.3이 드디어 모습을 드러내기 시작한 것이다.
새로운 표준을 도입하려면 조직들은 세 가지 중요한 사안에 집중해야 한다.
1) 0-RTT라고 알려진 ‘제로 라운드 트립 타임’을 어떻게 적용할 것인가?
2) TLS 1.2 다운그레이드
3) 인프라 및 애플리케이션 실험의 필요성
라운드 트립?
TLS 1.3 버전에서 가장 많이 다뤄지는 주제 중 하나가 바로 0-RTT 옵션이다. 엔드포인트 간 암호화된 세션이 진행될 때 속도를 크게 향상시켜주는 것이다. 사실 TLS 1.3 버전은 핸드셰이크 프로토콜이 이전보다 간소화 되어 있어, 0-RTT 없이도 클라이언트와 서버 간 통신 속도가 높다.
TLS 1.2 버전으로 웹 통신을 보호하는 경우, 클라이언트와 서버 간 두 번 왕복(round trip)을 해야 클라이언트가 HTTP 요청을 서버로 보내고, 서버가 그에 대한 응답을 보낼 수 있었다. 하지만 TLS 1.3에서는 이를 한 번의 왕복으로 줄여준다. 또한 클라이언트와 서버 간 신뢰가 형성될 경우 왕복의 필요성이 0으로 줄어든다. 그게 바로 0-RTT다.
0-RTT 옵션은 보안보다는 퍼포먼스를 위한 옵션이다. 그렇기 때문에 보안 구멍으로 비춰지기도 한다. 라운드 트립이 하나도 없는 환경에서는 어떠한 거래라도 쉬운 목표물이 될 수 있다. 공격자들은 암호화된 클라이언트 메시지를 가로채고 이를 다시 서버로 자기들이 임의로 전송할 수 있게 된다. 그럼으로써 서버의 ‘신뢰’ 구조를 자신들에게 유리하게 작동시키는 것이다.
그러니 TLS 1.3을 도입해야 하는 각 조직은 0-RTT의 이러한 위험성을 이해하고, 인터넷을 통해 제공하는 서비스와 애플리케이션들을 먼저 손봐야 한다. 개발자들이 특히 이 문제에 민감하게 반응해야 하는데, 0-RTT의 안전한 도입을 위해서는 능동적인 보안 점검 및 실험이 필요하기 때문이다. 속도가 대단히 민감한 부분이 아니라면 0-RTT 옵션은 비활성화시키는 것도 나쁘지 않은 선택이다.
다운그레이드
TLS 1.3 버전의 가장 큰 장점 중 하나는 오래된 암호화 표준이나 솔루션을 더 이상 지원하지 않는다는 것이다. 하지만 TLS 1.2로의 하위 호환은 가능하게 만들어준다. 물론 표준을 바꾼다고 했을 때 호환성 문제 때문에 이전 버전에 대한 지원을 유지하는 건 필수적인 일이다. 그러나 호환성에서 문제가 발생했다고 해서 곧바로 TLS 1.2로 다운그레이드 하기 보다는, 다른 환경설정부터 먼저 점검해야 한다. 다운그레이드는 정말 최후의 최후까지 가서 써볼 수 있는, 어쩔 수 없을 때 꺼내야 하는 카드일뿐이다.
그리고 다운그레이드를 했다고 해서 TLS 1.2에 머물러서는 안 된다. 거기서부터 암호화 알고리즘이나 솔루션을 보다 더 강력하고, 1.3 버전과 호환이 되는 것과 차근차근 바꿔나가야 한다. 그래서 결국에는 TLS 1.3으로 되돌아오는 것이 필요하다. 강력한 암호화 알고리즘이란 타원 곡선 암호 키 교환이나 대형 비대칭 키 방식 등을 말한다. 또한 완전 순방향 비밀성도 도입해야 한다.
실험, 실험, 실험
다운그레이드도 문제지만, 새것이라면 무조건 도입부터 하고 보는 것도 문제다. 그러니 TLS 1.3으로 갈아타기 전에 현존하는 인프라와 앱들을 충실히 실험해보는 것이 필요하다. 사실 바로 지금이 이러한 실험의 가장 적절한 시기라고 볼 수 있다. 암호화 시스템을 바꾼다는 건 시스템과 인프라에 큰 무리가 가는 일일 수 있다. 그러므로 실험을 통해 충분히 대비하고 실제 변화를 적용시켜야 한다.
가장 먼저는 호환성을 실험해야 한다. 그 다음이 보안이며, 그 다음이 퍼포먼스다. 이 세 가지가 가장 아름답게 구현되는 절충점을 찾는 게 실험의 목표다. 셋 중 그 어느 것도 간과될 수 없으며, 하나를 살리기 위해 다른 하나를 죽이는 일도 있어서는 안 된다. 보통 보안이 많이 희생이 되는데, 절대로 피해야 할 일이다.
실험을 할 땐 현실적인 트래픽들을 적용해보고, 내부 사용자와 외부 사용자 모두의 피드백을 얻어내야 한다. 내부 직원들은 물론 고객, 파트너사, 그 외 모든 관련자들의 의견을 최대한 듣는 데 시간을 할애해야 한다. 모바일 기기와 태블릿들을 포함한 네트워크 클라이언트들을 실험에 참가시키고, 서버들 여기 모두 실험 대상이 되어야 한다. 보안 장비들도 마찬가지다.
TLS 1.3이 본격적으로 도입되기 시작하면 보안과 퍼포먼스 모두가 강화될 것으로 예상된다. 또한 현재 사용되고 있는 암호화 기술이 일으키는 수많은 문제들 역시 해결될 것으로 업계는 기대하고 있다. 그러니 지금 초안이 돌아다닐 때 미리 대비하고 준비하다.
글 : 데이비드 디산토(David DeSanto), Spirent
[국제부 문가용 기자(globoan@boannews.com)]
Copyrighted 2015. UBM-Tech. 117153:0515BC
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-04-18] 
.jpg)
