2018.11.13

낡은 SSL의 한계를 넘어··· 웹 통신 보안의 시작 'TLS'

Paul Szymanski | Network World
TLS(Transport Layer Security)는 웹 통신을 보호한다는 애초 목표와 달리 설계와 구현의 결함이 발견됐고 결국 데이터 유출로 이어졌다. 이런 가운데 나온 최신 버전 TLS 1.3은 암호화 프로토콜을 강화하고 능률화하는 데 초점을 맞췄다.



TLS란 무엇인가
TLS는 네트워크를 통해 엔드-투-엔드 통신 보안을 제공하는 암호화 프로토콜이다. 인터넷 통신과 온라인 트랜잭션에 널리 사용된다. TLS는 도청, 변조 및 메시지 위조를 방지하기 위한 IETF 표준이다. 웹 브라우저, 인스턴트 메시징, 이메일, IP상의 음성 등 여러 애플리케이션이 TLS를 사용한다. 많은 기업이 중요 데이터가 전송되는지 여부와 관계없이 웹 서버와 브라우저 간의 모든 통신을 보호하기 위해 TLS를 사용한다.

TLS의 이전 버전인 SSL(Secure Socket Layer)은 넷스케이프(Netscape)에서 1995년에 개발했다. SSL 버전 1.0, 2.0에는 프로토콜의 완전한 재설계 없이는 수정할 수 없는 여러 가지 보안 결함이 있었다. 1996년에 넷스케이프는 TLS1.0의 기초가 된 SSL 버전 3.0을 출시했다. 1999년에 PCI위원회는 SSL이 궁극적으로 TLS 1.0으로 대체 된 것이 SSL 3.0으로의 업그레이드라고 말하기도 했다.

TLS vs. SSL
TLS는 메시지 인증, 키 값 생성 및 기타 암호화 알고리즘을 강화해 SSL보다 효율적이고 안전해졌다. 예컨대, SSL과 달리 TLS는 사전 공유 키, 보안 원격 암호, 타원 곡선 키 및 커베로스(Kerberos)를 지원한다. SSL과 TLS는 서로 호환되지 않지만, TLS는 여전히 SSL을 사용하는 오래된 기기를 위해 하위 호환성을 제공한다.

TLS 프로토콜 사양은 2개의 레이어를 정의한다. TLS 레코드 프로토콜은 연결 보안을 제공하며, TLS 핸드셰이크 프로토콜을 사용하면 데이터가 전송되기 전에 클라이언트와 서버가 서로를 인증하고 보안 키를 조율한다.

TLS 핸드셰이크는 여러 단계로 이루어진 절차다. 기본 TLS 핸드셰이크는 클라이언트와 서버 간에 "헬로(hello)"라는 메시지를 보내고 키, 암호 메시지 및 마침 메시지를 전송한다. 다중 프로세스 핸드셰이크 프로세스는 교환의 형식과 순서를 임의로 정할 수 있어, TLS를 다른 응용 프로그램에서 사용하기 편하다.

TLS의 결함과 허점들
프로토콜과 구현상의 허점은 지속적으로 보안 툴과 기술에 문제를 일으키고 있으며, TLS 역시 나름의 데이터 유출 문제를 겪고 있다. TLS/SSL을 타깃으로 한 주요 공격은 다음과 같다.

- BEAST(2011): SSL/TLS에 대한 브라우저 공격(Browser Exploit Against SSL/TLS)의 약자로, CBC(암호 차단 체인)의 약점을 이용해 암호화된 세션에서 암호화되지 않은 일반 텍스트를 추출하는 공격 방식이었다.
- CRIME 및 BREACH(2012 및 2013): BEAST의 TLS를 사용하더라도 해커가 웹 쿠키의 콘텐츠를 검색할 수 있도록 하는 CRIME(Compression Ration Info-link Made Easy)을 만들었다. 일례로, 인증 쿠키를 복구해 공격자가 인증된 웹 세션을 가로챌 수 있다. BREACH(Browser Reconnaisance and Exfiltration via Adaptive Compression of Hypertext)는 CRIME을 기반으로 하며 로그인 토큰, 이메일 주소 및 기타 정보를 추출한다.
- 하트블리드(2014년): 하트블리드(Heartbleed)를 통해 해커는 보안 서버에서도 개인 키를 훔칠 수 있다. 감염된 서버는 인터넷에 있는 모든 사용자가 취약한 버전의 OpenSSL이 보호하는 시스템의 메모리를 읽을 수 있도록 개방된다. 하트블리드를 악용하면 해커가 서버에서 데이터를 훔치거나 대화나 다른 사용자를 속일 수 있다.


보안, 성능 강화한 TLS 1.3
TLS 1.3은 IETF(Internet Engineering Task Force)가 시작한 최초의 프로토콜을 현대화 시도였다. 이전 버전은 불량 코드에 붙여 놓은 반창고 정도라고 생각할 수 있다. 반창고를 붙여 놓으면 잠시 동안은 피가 멈출 지 몰라도, 결국 근본적인 치료를 하지 않으면 상처가 곪게 된다. TLS 1.3 작업은 2014년 4월에 시작됐으며, 2018년 3월 승인되기까지 총 4년간 28개 초안 작업이 소요됐다.

IETF는 대규모 개정과 더불어 "보안, 성능 및 프라이버시 분야의 주요 개선"을 마련하기 시작했다. 가장 큰 변화는 TLS 1.3에서는 공격자가 HTTPS 암호화 트래픽을 해독하기 훨씬 어렵기 때문에 개인 정보를 더 잘 보호할 수 있게 됐다는 사실이었다.

버전 1.3은 또한 암호화 프로세스 속도를 높여 핸드셰이크 처리 속도를 높인다. 이는 보안상 이점을 제공하지만 보안 웹 애플리케이션의 성능도 향상시켜야 했다. TLS 1.2에서는 핸드셰이크 프로세스에 몇 번의 왕복 이동이 필수였다. 그러나 1.3을 사용할 경우 한 번의 왕복만으로 모든 정보가 전달된다.

TLS 1.3은 TLS 1.2를 원활하게 대체해야 하며, 동일한 인증서와 키를 사용하기 때문에, 최대한 구현이 간단해야 한다. 또한 클라이언트와 서버 모두에서 TLS 1.3을 지원하면 자동으로 커넥션을 조율할 수 있다.

TLS 개발 초기에는 몇 가지 문제가 있었다. 대표적인 것이 메릴랜드의 한 학교 시스템에서 크롬북 약 2만대를 업그레이드했을 때 드러났다. 이밖에도 금융서비스 기관은 네트워크 상에서 발생하는 일을 알 수 없게 만든다는 이유로 암호화에 대해 격렬히 반대하기도 했다. IETF는 프로토콜이 정확하게 구현될 경우 모니터링 도구와 함께 작동할 수 있도록 몇 가지 기능을 개선했다.

보안기능 개선 외에도, TLS 1.3은 취약성을 초래하는 부분과, 아무런 생산적 기능을 하지 않던 오래된 알고리즘을 제거했다. 이렇게 제거된 알고리즘에는 RC4 스팀 암호, DES, 3DES, RSA 키 전송, SHA-1 해싱, CBC 모드 암호, MD5, Diffie-Hellman 그룹, EXPORT 암호 등이 있다.

또한 업데이트된 프로토콜에서는, 클라이언트와 서버가 이전에 통신했는지 여부를 기억할 수 있도록 "0-RTT resumption" 기능을 추가했다. 과거 통신 내역이 있는 경우 이전 키를 사용할 수 있고, 보안 검사를 건너뛰고 클라이언트와 서버가 즉시 통신을 시작할 수 있게 했다. 일부 대기업은 연결 속도가 빠르다는 이유로 0-RTT를 선호하지만, 이를 우려하는 보안 전문가도 많다.

TLS 1.3은 보안상의 이점 하나만으로도 매우 훌륭하지만, 거기에 더해 네트워크상의 이유도 있다. TLS 1.3은 이전 버전보다 가벼우며 리소스를 적게 사용한다. 즉, 효율성을 향상해 CPU 사이클이 줄어들고 지연 시간이 줄어들어 성능이 개선된다. ciokr@idg.co.kr 

SSL / TLS / 보안
2018.11.13

낡은 SSL의 한계를 넘어··· 웹 통신 보안의 시작 'TLS'

Paul Szymanski | Network World
TLS(Transport Layer Security)는 웹 통신을 보호한다는 애초 목표와 달리 설계와 구현의 결함이 발견됐고 결국 데이터 유출로 이어졌다. 이런 가운데 나온 최신 버전 TLS 1.3은 암호화 프로토콜을 강화하고 능률화하는 데 초점을 맞췄다.



TLS란 무엇인가
TLS는 네트워크를 통해 엔드-투-엔드 통신 보안을 제공하는 암호화 프로토콜이다. 인터넷 통신과 온라인 트랜잭션에 널리 사용된다. TLS는 도청, 변조 및 메시지 위조를 방지하기 위한 IETF 표준이다. 웹 브라우저, 인스턴트 메시징, 이메일, IP상의 음성 등 여러 애플리케이션이 TLS를 사용한다. 많은 기업이 중요 데이터가 전송되는지 여부와 관계없이 웹 서버와 브라우저 간의 모든 통신을 보호하기 위해 TLS를 사용한다.

TLS의 이전 버전인 SSL(Secure Socket Layer)은 넷스케이프(Netscape)에서 1995년에 개발했다. SSL 버전 1.0, 2.0에는 프로토콜의 완전한 재설계 없이는 수정할 수 없는 여러 가지 보안 결함이 있었다. 1996년에 넷스케이프는 TLS1.0의 기초가 된 SSL 버전 3.0을 출시했다. 1999년에 PCI위원회는 SSL이 궁극적으로 TLS 1.0으로 대체 된 것이 SSL 3.0으로의 업그레이드라고 말하기도 했다.

TLS vs. SSL
TLS는 메시지 인증, 키 값 생성 및 기타 암호화 알고리즘을 강화해 SSL보다 효율적이고 안전해졌다. 예컨대, SSL과 달리 TLS는 사전 공유 키, 보안 원격 암호, 타원 곡선 키 및 커베로스(Kerberos)를 지원한다. SSL과 TLS는 서로 호환되지 않지만, TLS는 여전히 SSL을 사용하는 오래된 기기를 위해 하위 호환성을 제공한다.

TLS 프로토콜 사양은 2개의 레이어를 정의한다. TLS 레코드 프로토콜은 연결 보안을 제공하며, TLS 핸드셰이크 프로토콜을 사용하면 데이터가 전송되기 전에 클라이언트와 서버가 서로를 인증하고 보안 키를 조율한다.

TLS 핸드셰이크는 여러 단계로 이루어진 절차다. 기본 TLS 핸드셰이크는 클라이언트와 서버 간에 "헬로(hello)"라는 메시지를 보내고 키, 암호 메시지 및 마침 메시지를 전송한다. 다중 프로세스 핸드셰이크 프로세스는 교환의 형식과 순서를 임의로 정할 수 있어, TLS를 다른 응용 프로그램에서 사용하기 편하다.

TLS의 결함과 허점들
프로토콜과 구현상의 허점은 지속적으로 보안 툴과 기술에 문제를 일으키고 있으며, TLS 역시 나름의 데이터 유출 문제를 겪고 있다. TLS/SSL을 타깃으로 한 주요 공격은 다음과 같다.

- BEAST(2011): SSL/TLS에 대한 브라우저 공격(Browser Exploit Against SSL/TLS)의 약자로, CBC(암호 차단 체인)의 약점을 이용해 암호화된 세션에서 암호화되지 않은 일반 텍스트를 추출하는 공격 방식이었다.
- CRIME 및 BREACH(2012 및 2013): BEAST의 TLS를 사용하더라도 해커가 웹 쿠키의 콘텐츠를 검색할 수 있도록 하는 CRIME(Compression Ration Info-link Made Easy)을 만들었다. 일례로, 인증 쿠키를 복구해 공격자가 인증된 웹 세션을 가로챌 수 있다. BREACH(Browser Reconnaisance and Exfiltration via Adaptive Compression of Hypertext)는 CRIME을 기반으로 하며 로그인 토큰, 이메일 주소 및 기타 정보를 추출한다.
- 하트블리드(2014년): 하트블리드(Heartbleed)를 통해 해커는 보안 서버에서도 개인 키를 훔칠 수 있다. 감염된 서버는 인터넷에 있는 모든 사용자가 취약한 버전의 OpenSSL이 보호하는 시스템의 메모리를 읽을 수 있도록 개방된다. 하트블리드를 악용하면 해커가 서버에서 데이터를 훔치거나 대화나 다른 사용자를 속일 수 있다.


보안, 성능 강화한 TLS 1.3
TLS 1.3은 IETF(Internet Engineering Task Force)가 시작한 최초의 프로토콜을 현대화 시도였다. 이전 버전은 불량 코드에 붙여 놓은 반창고 정도라고 생각할 수 있다. 반창고를 붙여 놓으면 잠시 동안은 피가 멈출 지 몰라도, 결국 근본적인 치료를 하지 않으면 상처가 곪게 된다. TLS 1.3 작업은 2014년 4월에 시작됐으며, 2018년 3월 승인되기까지 총 4년간 28개 초안 작업이 소요됐다.

IETF는 대규모 개정과 더불어 "보안, 성능 및 프라이버시 분야의 주요 개선"을 마련하기 시작했다. 가장 큰 변화는 TLS 1.3에서는 공격자가 HTTPS 암호화 트래픽을 해독하기 훨씬 어렵기 때문에 개인 정보를 더 잘 보호할 수 있게 됐다는 사실이었다.

버전 1.3은 또한 암호화 프로세스 속도를 높여 핸드셰이크 처리 속도를 높인다. 이는 보안상 이점을 제공하지만 보안 웹 애플리케이션의 성능도 향상시켜야 했다. TLS 1.2에서는 핸드셰이크 프로세스에 몇 번의 왕복 이동이 필수였다. 그러나 1.3을 사용할 경우 한 번의 왕복만으로 모든 정보가 전달된다.

TLS 1.3은 TLS 1.2를 원활하게 대체해야 하며, 동일한 인증서와 키를 사용하기 때문에, 최대한 구현이 간단해야 한다. 또한 클라이언트와 서버 모두에서 TLS 1.3을 지원하면 자동으로 커넥션을 조율할 수 있다.

TLS 개발 초기에는 몇 가지 문제가 있었다. 대표적인 것이 메릴랜드의 한 학교 시스템에서 크롬북 약 2만대를 업그레이드했을 때 드러났다. 이밖에도 금융서비스 기관은 네트워크 상에서 발생하는 일을 알 수 없게 만든다는 이유로 암호화에 대해 격렬히 반대하기도 했다. IETF는 프로토콜이 정확하게 구현될 경우 모니터링 도구와 함께 작동할 수 있도록 몇 가지 기능을 개선했다.

보안기능 개선 외에도, TLS 1.3은 취약성을 초래하는 부분과, 아무런 생산적 기능을 하지 않던 오래된 알고리즘을 제거했다. 이렇게 제거된 알고리즘에는 RC4 스팀 암호, DES, 3DES, RSA 키 전송, SHA-1 해싱, CBC 모드 암호, MD5, Diffie-Hellman 그룹, EXPORT 암호 등이 있다.

또한 업데이트된 프로토콜에서는, 클라이언트와 서버가 이전에 통신했는지 여부를 기억할 수 있도록 "0-RTT resumption" 기능을 추가했다. 과거 통신 내역이 있는 경우 이전 키를 사용할 수 있고, 보안 검사를 건너뛰고 클라이언트와 서버가 즉시 통신을 시작할 수 있게 했다. 일부 대기업은 연결 속도가 빠르다는 이유로 0-RTT를 선호하지만, 이를 우려하는 보안 전문가도 많다.

TLS 1.3은 보안상의 이점 하나만으로도 매우 훌륭하지만, 거기에 더해 네트워크상의 이유도 있다. TLS 1.3은 이전 버전보다 가벼우며 리소스를 적게 사용한다. 즉, 효율성을 향상해 CPU 사이클이 줄어들고 지연 시간이 줄어들어 성능이 개선된다. ciokr@idg.co.kr 

SSL / TLS / 보안
X