TLS 1.3

Published in

Quantum Ant

12 min readAug 12, 2019

SSL/TLS

인터넷 중에서도 특히 웹에서 사용하는 통신 프로토콜을 HTTP라고 하고, 보안 채널을 추가한 것이 HTTPS라고 합니다. 2018년 우리가 흔히 쓰는 브라우저인 크롬은 그동안 일반적인 통신 방법으로 사용하던 HTTP를 ‘안전하지 않음’으로 표시하기로 했습니다.

TLS는 서로 멀리 떨어진 두 컴퓨터가 안전하지 않은 네트워크를 통해서 안전하게 대화를 주고 받기 위해 만들어진 보안 프로토콜입니다. 각종 사이트에 로그인할 때 입력한 로그인 정보부터 인터넷 결제를 할 때 입력하는 정보까지 우리가 사용하는 웹에서 보안을 책임지고 있습니다.

2018년 8월 10일에는 드디어 새로운 버전인 TLS 1.3이 발표되었습니다.

이번 포스팅에서는 SSL/TLS를 간단하게 살펴보고 새로운 버전까지 알아보도록 하겠습니다.

개요

TLS라는 보안 프로토콜이 필요한 이유는 인터넷에서 데이터를 전달하는 방식이 안전하지 않기 때문입니다.

인터넷에서 데이터를 전달하는 방식은 ‘수업 시간에 쪽지를 주고 받는 행위’를 생각해보면 좋습니다. 수업 시간에 멀리 떨어진 친구에게 쪽지를 보낼 때는 직접 전달하면 들키기 마련입니다. 그래서 몰래 주고 받기 위해서는 우리는 여러 친구들을 통해서 주고 받아야 했습니다.

인터넷에도 마찬가지로, 발신자인 클라이언트와 수신자인 서버는 직접 연결되지 않기 때문에 그 중간에 존재하는 무수한 전달자인 라우터가 데이터를 넘겨주는 방식으로 전달됩니다.

여기서 문제가 발생하게 됩니다. 중간에 친구가 쪽지를 보는 행위, 즉 중간에 있는 라우터를 신뢰할 수 없다는 점입니다.

TLS의 보안

우리는 쪽지를 친구를 통해 전달할때 꼼꼼히 접어서 전달을 합니다. 물론 크기를 줄이기 위해서 일지도 모르지만, 중간에 있는 친구들이 열어보지 않기를 바라는 마음도 있었을 것입니다.

그림을 살펴보면 Eve는 도청자로 중간자 공격(Man-in-the-Middle Attack)를 하는 악의적인 사람입니다. TLS의 목표는 Alice와 Bob이 주고 받는 메시지를 Eve가 방해할 수 없게 만드는 것입니다.

Eve의 공격으로 할 수있는 것들로는 3가지로 정리할 수 있습니다.

Eve는 Alice에게 응답을 보내서 자신을 밥이라고 속일 수 있습니다.
Eve는 Alice가 보낸 메시지를 읽을 수 있습니다.
Eve는 Alice가 보낸 메시지를 변경하거나, 위조할 수 있습니다.

이 세 가지 취약점을 대응하기 위한 목표로는

인증성 (Authenticity)

앨리스와 쪽지를 주고받는 상대방이 밥임을 인증하는 것

기밀성 (Confidentiality)

앨리스와 밥 만이 서로의 쪽지를 읽을 수 있고, 이브는 불가능하게 하는 것

무결성 (Integrity)

앨리스가 쓴 쪽지가 변경되지 않았음을 보장하는 것

TLS는 이렇게 세 가지 목표를 달성함으로써, 안전하지 않은 인터넷에서 안전한 보안된 통신 채널을 만들 수 있게됩니다.

간단하게 TLS가 무엇을 목표하며 왜 사용해야되는지 알아보았습니다.

지금부터는 TLS 1.2 와 1.3을 비교하며 새롭게 등장한 1.3버전을 살펴보도록 하겠습니다.

TLS 1.3

TLS 1.3이 이전 버전에서 개선한 것들을 정리해보면 크게 속도와 정리 그리고 보안으로 볼 수 있습니다.

TLS 1.3의 속도

TLS1.3은 RTT(Round Trip Time)를 줄여서 속도를 개선했습니다. 어떤 데이터를 상대방에게 보내기 시작한 시간부터 그것에 대한 응답을 받기 시작하는 시간까지, 즉 데이터가 네트워크를 한 바퀴 돌아서 다시 돌아오는데 걸리는 시간을 말합니다. 쉽게 비유하면 바다에서 잠수함이 주변을 볼때 레이더를 살펴봅니다. 이 레이더는 강한 전자기파 를 발사하고 그것이 물체에 맞고 반사되어 되돌아 오는 전자파를 분석하여 대상물과의 거리를 측정합니다. 결론적으로 왔다 갔다 하는데 걸리는 시간입니다.

TLS는 보안 채널을 구성하기 위해서 Handshake 과정이 필요한데, 이 과정에서 많은 시간이 소요되게 됩니다. Handshake는 크게 처음 연결하는 경우와 기존에 연결했던 것을 다시 연결하고자 하는 경우가 존재합니다. TLS 1.3은 기존과 비교해서 각각 1 RTT만큼 감소시켰습니다.

위는 TLS 1.2의 Handshake, 밑은 TLS 1.3의 Handshake 입니다.

위는 클라이언트-서버-클라이언트-서버 이렇게 2 RTT 후에 암호화된 데이터가 송수신되는 것을 볼 수 있지만, 밑은 클라이언트-서버 1 RTT 후에 Finished와 암호화된 데이터가 같이 전달되는 것을 볼 수 있습니다.

즉, 왔다 갔다하며 확인 했던 이전 버전과는 다르게 한번의 과정으로 처리 합니다.

TLS 1.3의 정리

TLS의 암호화 모음 (Cipher Suite)

TLS는 안전한 네트워크 연결을 위해서 앞에서 언급했던 각각의 보안 목표를 달성하는 암호화 기법을 여러 가지 조합하여 암호화 모음을 만들었습니다. 클라이언트와 서버는 적절한 암호화 모음을 선택하기만 하면, 세 가지의 보안 목표를 달성할 수 있습니다. 암호화 모음은 구별을 위해서 이름을 가지고 있는데, 암호화 모음의 이름은 일반적으로 다음과 같은 구조를 가집니다.

TLS {키 함의 프로토콜} {인증 방법} _ WITH _ {암호화 기법} _ {데이터 무결성 체크 방법}

예를 들어서 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

키 합의 프로토콜 : DHE(Diffie-Hellman(-Merkel) Key Exchange, 디피-헬만(-머클) 키 합의 프로토콜)
인증 방법 : RSA (공개키)
암호화 기법 : AES256CBC(대칭키)
데이터 무결성 체크 방법 : SHA256

키에 관한 상세한 설명은 나중에 따로 포스팅을 진행하겠습니다.*

암호화 모음 관리 단순화

TLS 1.3에서는 기본의 암호화 모음 관리 방법이 가지던 복잡성을 줄이기 위해서 암호화 모음을 3개의 요소로 분리하고, 이를 조합하는 형태로 개선했습니다.

기존의 방식인 키 합의 프로토콜, 인증 알고리즘, 암호화 기법, 무결성 체크 기법을 모두 묶은 것으로 한 줄 한 줄에 대해서 구별이 되는 코드값을 부여를 하게 도면 확장성이 매우 떨어지게 됩니다. 왜냐하면 만약 키 합의 프로토콜에서 새로운 프로토콜이 추가 된다면 다른 모든 조합에 대해서 무수히 많은 새로운 항목을 만들어놔야 하기 때문입니다.

반면에 새롭게 개선된 방법은 서로 구별되는 요소들인 암호화 기법, 키 합의 프로토콜, 인증 알고리즘으로 분리해서 나타내기 때문에 키 합의 프로토콜에 새로운 프로토콜이 추가되어도 가운데 항목에만 새로운 값을 부여하면 나머지 모든 조합도 자동으로 지원하게 됩니다.

미리 만들어 놓지 않고 요구할때마다 자동으로 각 항목별로 하나씩 조합을 시킨다고 보면 될꺼같습니다.

TLS 1.3의 보안

이전 버전까지는 기존의 버전과의 호환성을 위해 지원하던 legacy 기능이 많이 존재 했었지만, 이러한 호환성을 위한 것들 때문에 보안에 위협이 되기도 했습니다.

TLS 1.3에서는 보안강화를 위해서 기존의 이런 호환성을 위해 존재했던 것들을 과감히 삭제하고 정리했습니다. 주로 상대적으로 더 높은 보안 강도를 가지는 키 길이(256bit), 짧은 길이로도 더 높은 보안 강도를 높이는 타원 곡선 암호, 미래에도 안전함을 보장하는 순방향 비밀성을 기준으로 선택한 것으로 보입니다.

위는 TLS 1.2에서 지원하던 키 합의 프로토콜을 나타내고, 밑은 TLS 1.3에서 지원하는 키 합의 프로토콜을 나타냅니다.

TLS 1.3에서는 순방향 비밀성을 보장하지 않는 RSA 등의 다른 방법들은 제거되었고 (EC)DHE, PSK-only, PSK with (EC)DHE만 남았습니다. PSK는 미리 안전한 방법으로 공유된 키를 사용하는 방법인 사전 공유 키(pre-shared key)의 줄임말로, 엄밀히는 순방향 비밀성을 보장하지는 않습니다.

PSK를 사용하면서 순방향 비밀성을 보장하고자 할 때는 PSK with (EC)DHE를 사용하면 됩니다.

강한 기법들만 남은 서명 알고리즘

서명 알고리즘에서도 변경이 있었습니다. TLS 1.2에서는 RSA, 디지털 서명 알고리즘(DSA), 타원곡선 디지털 서명 알고리즘(ECDSA)을 지원하고 있었습니다.

2048 bit의 키를 지원하는 RSA와 비교해서 1024 bit이라는 짧은 키를 강제하는 문제가 있었던 디지털 서명 알고리즘은 TLS 1.3에서 삭제되었습니다. 그리고 에드워드 곡선이라는 안전하다고 알려진 새로운 종류의 타원 곡선을 사용하는 에드워드 곡선 디지털 서명 알고리즘(EdDSA)이 추가되었습니다.

여러가지 알고리즘에 관해서는 다음에 따로 포스팅 하겠습니다.*

TLS 1.3을 당장 사용할 수 있을까?

주요 웹브라우저에 대해서 살펴보면, 2019년 1월 파이어폭스와 크롬, 삼성 인터넷만이 TLS 1.3을 지원하는 것을 확인할 수 있습니다. IE와 Edge, Safari, Opera 등은 아직 TLS 1.3을 지원하지 않습니다. 크롬의 경우는 chrome://flags로 들어가서 TLS 1.3 플래그를 켜야 합니다. 이 플래그를 켜고 TLS 1.3을 지원하는 서버에 접속하면 아래와 같이 TLS 1.3을 사용하는 것을 확인할 수 있습니다.

아직 기본적으로 지원하지는 않지만 지원하는 웹브라우저에서 개인이 설정하면 사용할 수 있습니다.

HTTP 에서 HTTPS로 옮겨진것 처럼 1.3 버전도 시간이 지나면 자연스럽게 보안강화와 함께 모두가 쓰게될 것같습니다.

참고 문헌 : 버즈빌, Buzzvil | Tech Blog Hello, TLS 1.3

요즘 내가 관심있게 보는 것?

해외 불법·유해 사이트를 차단하는 기술을 고도화하면서 불거진 문제다. 주요 논란점은 차단 과정에서 불법적으로 의 일부분(헤더)을 해킹 한다는 것이다. 또한, 불법 사이트 차단을 명분으로 인터넷 검열 또는 민간인 도청이 가능해지고, 심지어는 중국처럼 표현의 자유를 손쉽고 강력하게 억압할 수 있다는 가능성에 대한 우려가 현실화되었다고 볼 수 있다는 논란이다. 즉, 국가가 마음만 먹으면 직접적으로 악용이 가능하다는 것이 논란의 쟁점이다.

2019년부터 이렇게 정부에서 강제적으로 불법 사이트 차단을 명분으로 인터넷검열과 도청을 가능하게 한것에 대해서 어떤 원리로 차단을 하는지에 대해서 공부를 진행하고 있습니다.

2019년도 이전에도 warnig.or.kr 이라는 경고 문구를 본적이 있을 겁니다.

시간순으로 기술을 보면 이렇습니다.

URL 차단 — https가 등장하면서 뚫립니다.
DNS 스프핑 — DNS 주소 변경 등으로 우회가 가능합니다.
SNI 차단 — 요즘 사용하는 방식으로 SNI 필드를 차단하는 방식

SNI (Server Name Indication)

위에서 설명했던 TLS의 확장 표준 중 하나로, 인증서에서 사용하는 방식입니다.

이 기술이 나오게 된 큰 이유는 하나의 웹서버가 여러 웹사이트를 서비스하면서 인증서 인증에 문제가 생겼기 때문입니다. 기존까지는 대상 서버의 IP 주소와 도메인이 1:1 대응 관계라서 서버의 인증서 제공에 문제가 없었지만, 여러 도메인을 하나의 IP 주소로 연결하는 서비스가 대중화되면서 보낼 인증서를 특정하지 못하게 되었다. 이 때문에 클라이언트가 사이트에 접속하면서 도메인 정보를 보내도록 변경한 것입니다.

이 SNI를 사용하게 되면 하나의 웹 서버에서 여러 도메인의 웹사이트를 서비스하는 경우에도 인증서를 사용한 HTTPS를 활성화시킬 수 있습니다.

TLS 표준에는 SNI 암호화가 없어서, SNI 부분이 평문 형태로 전송됩니다. 이로 인해 제 3자에게 쉽게 노출이 되어 보안 문제가 생기기 때문에, TLS에 SNI의 암호화 규격을 추가하는 문제는 오랜 기간 논의되어 왔습니다.

2018년 7월 2일 에 Apple, Cloudflare, Fastly, Mozilla 에 의해 작성된, TLS 1.3을 전제로 한 확장 규격으로서의 SNI 암호화 규격의 초안 문서가 IETF에 등재됐습니다.
2018년 9월 24일에 Cloudflare가 위 초안 규격에 의한 암호화된 SNI, ESNI(Encrypted SNI) 시범 서비스를 개시했습니다.
2018년 12월 12일 부터 Firefox의 최신 안정화 버전에서 ESNI 지원이 시작되었다. 반면 2019년 2월 기준 MS Edge, IE 등 다른 브라우저에서는 지원되지 않습니다.

이 ESNI 구현은 클라이언트 브라우저에 서버의 공개키가 전달되는 시점을 DNS 통신 단계로 앞당겨서, 서버와 연결하는 시점에 해당 공개키로 도메인이 암호화될 수 있도록 하는 것이다. 파이어폭스는 ESNI 구현이 DNS 통신의 암호화가 이루어지지 않는 상황에서는 별 의미가 없다는 점을 들어, ESNI가 작동하려면 DoH(DNS over HTTPS)가 활성화되어 있을 것을 요구하고 있습니다. 차후 운영체제 기능에 DNS 통신 암호화가 구현되거나 플래그 등이 만들어져서 암호화 통신인지 아닌지를 구분할 수 있게 된다면 운영체제 기능으로도 ESNI를 쓸 수 있도록 제약이 풀릴 것같습니다.