현재 TLS1.3의 낮은 보급, 하지만 개봉박두
Posted on Saturday, December 30, 2017.
Cloudflare의 Nick Sullivan씨의 글을 풀어본 것입니다.
현재 TLS1.3은 호환성 이슈가 많다. 보안성 강화와 빠른 속도를 장점으로 가지는 TLS1.3에 대해서 많은 브라우저들이 구현체를 탑재하였지만 대부분 기본적으로 비활성화 되어있다. 그 문제는 TLS 1.3 프로토콜 자체에 있다기 보다는 미들박스, 즉 이미 많이 도입되어 있는 SSL-proxy들이 TLS1.3 통신에 있어 장애요소가 되기 때문이다.
TLS 세션이 처음 맺어질때 클라이언트와 서버는 각각 자신의 최대 지원 가능 TLS버젼을 보내면 그 중 작은 값의 버젼으로 통신이 이루어진다. 이 간단한 프로토콜을 잘 지키지 못하는 서버들이 있다는 것이 문제의 시발점이다. TLS1.2를 오퍼받았을때, TLS1.0으로 카운터오퍼해야 정상인데 세션을 끊어버리는 서버들이 상당히 많이 존재한다. 그래서 브라우저들은 세션이 끊어졌을 때 낮은 TLS버젼으로 재시도를 하게 되었다.
- TLS1.2로 하자 → 아니 대신 TLS1.0으로 하자 (secure downgrade. 전화연결이라고 볼 때 연결이 끊기지 않고 바로 통화. 바람직한 접근)
- TLS1.2로 하자.. 아니 얘가 전화를 끊네. 그럼 TLS 1.1로 하자.. 아니 또 끊네.. 그럼 TLS1.0으로 하자.. SSLv3로 하자… (insecure downgrade. 보편적인 구현. 재시도가 많아서 속도도 느림)
보안강도로 볼 때 TLS1.2 » TLS1.1 > TLS1.0 »> SSLv3 순이 된다. 따라서 가능하면 TLS1.2로 연결하는 것이 보안상 유리하다. 이는 반대로 SSLv3로 연결되는 세션은 굉장이 취약하다는 것이다. SSLv3의 취약성 POODLE이 2014년 발표되어 SSLv3는 보안성을 상실하였다. 그러면 공격자 입장에서 어떻게 공격할 수 있을까?
많은 브라우저들의 insecure downgrade를 이용하는 것이다. 프로토콜 때문에 전화가 끊겼는지 옆에서 누가 수화기를 놓았는지 브라우저는 알기가 어렵기 때문에 전화가 끊기기만 하면 낮은 프로토콜로 다시 전화를 건다. 공격자 공격대상 옆에서 기다리다가 TLS1.2, 1.1, 1.0으로 전화를 걸때마다 전화를 끊어주면, 두 사람은 결국 SSLv3로 전화를 연결하게 되고, 그 때 유유히 엿들을 수 있는 것이다.
그래서 여러 대처가 있었다. 대부분의 브라우저는 SSLv3 지원을 중단하였고, insecure downgrade메카니즘을 꺼버렸다. POODLE 사단을 겪은 서버들이 secure downgrade를 제대로 지원하겠지라고 기대하면서.
하지만 역사는 반복된다고 하였다. 많은 서버들이 “TLS1.3으로 하자"요청에 대해서 “아니 대신 TLS1.2로 하자"라는 답을 보내지 않고 전화를 끊어버리는 것이다. TLS1.3의 세션 장애율이 3%에 육박한다는 결과가 보고되었다. 해결을 위해 다시 insecure downgrade를 도입한다면 보안성 및 속도 향상을 기치로 내건 TLS1.3이 의미가 완전히 없어진다.
울며 겨자먹기로 제안된 것이 extension을 이용하는 것이다. “나 TLS1.2야. 하지만 사실은 TLS1.3이야"라고 요청하면 TLS1.3을 지원하지 않은 서버들은 TLS1.2로 응답하고, 지원하는 서버들은 TLS1.3으로 응답하는 것이다[TLS1.3 draft16, September 2016]. 이 방식으로 진행하면 대부분의 서버들과의 통신 문제가 사라졌다.
그래서 2017년 2월에 크롬과 파이어폭스가 TLS1.3을 켰다. 그런데 gmail서비스시에
- TLS1.2로는 1.7%장애
- TLS1.3으로는 7.7%장애
라는 결과가 나타났다. 조사결과 SSL 미들박스들이 충돌을 일으키는 것으로 나타났다. 대표적인 것이 Bluecoat 6.5 proxy이다.
미들박스 제조사를 비난할 수만도 없는게, 근 20년간 있었던 인프라 프로토콜의 변경인 것이기 때문이다. TLS1.0은 1999년에 발표되었다. 20년이면 강산도 변하고, 그 시간동안 변하지 않는다면 버그도 표준이 되는 시간이다.
2017년 11월 싱가포르 IETF미팅에서 제시된 해결책은 다음과 같다
필요없다고 삭제해버린 프로토콜 파트를 다시 되살린다 TLS1.3을 최대한 TLS1.2와 유사하게 만든다. 이러한 노력으로 인해 Chrome과 Firefox에서 다음과 같이 호환성을 올릴 수 있었다.
- TLS1.2 - 1.4%장애
- TLS1.3 Experimental (PR1091 on github) - 1.2% 장애
이 결과는 [TLS1.3 draft 22, November 2017] 에 반영되었다.
TLS1.3의 보급이 머지 않았다.
마지막으로 미들박스를 만드는 분들은 Cloudflare에서 제공하는 TLS1.3 미들박스 호환성 테스트를 사용해보는 것을 추천한다. https://tls13.mitm.watch/