세계는 TLS 1.3, 이것은 아주 좋은 것입니다! 이 기사는 TLS 1.3, 새로운 기능의 효과에 대한 토론.
전송 계층 보안
전송 계층 보안 또는 TLS은 컴퓨터 네트워크를 통해 교환되는 데이터를 보호하는 암호화 프로토콜입니다. TLS 로 유명 해졌다 S in HTTPS. 더 구체적으로, TLS 네트워크 공격으로부터 웹 사용자 데이터를 보호하는 데 사용됩니다.
TLS 이전 모델에 대한보다 안전한 대안으로 설계되었습니다. 보안 소켓 레이어 (SSL). 수년에 걸쳐 보안 연구원들은 SSL에 영향을 미치는 수많은 취약점을 발견하여 IETF를 설계하도록 동기를 부여했습니다. TLS 그들을 완화하려는 노력으로.
아이러니하게도, 이전 버전 TLS 위험한 취약점의 영향을 받아 궁극적으로 TLS 1.2 (즉, 업계 전문가가 권장하는 기본 버전).
알려진 프로토콜 취약점의 대부분은 TLS 1.2, 그러나이 수준의 보안은 여전히 결함이있는 디자인 위에 일련의 패치로 인한 결과였습니다.
이에 대한 답변으로 TLS 1.3은 현대적이고 안전한 디자인을 위해 처음부터 작성되었습니다. TLS 실험 계획안. XNUMX 년간의 테스트 끝에 마침내 승인되었으며 이제 기본 인터넷 보안 표준에 가깝습니다.
TLS 버전 및 해당 RFC 문서는 아래 목록에서 찾을 수 있습니다.
- TLS 1.0으로 게시되었습니다 RFC 2246 1996년
- TLS 1.1으로 게시되었습니다 RFC 4346 2006년
- TLS 1.2으로 게시되었습니다 RFC 5246 2008년
- TLS 1.3은 제안 된 표준으로 출판되었다 RFC 8446 2018 인치
나이가 어떻게 TLS 버전이 작동합니까?
의 장점을 효과적으로 논의하기 위해 TLS 1.3, 우리는 먼저 나이에 대해 이야기해야합니다 TLS 버전이 작동합니다 (및 작동하지 않는 방법).
TLS 하는 잡종 암호 시스템, 둘 다 사용한다는 의미 비대칭 인 (공개 키) 및 대칭 (암호 / 구문 기반) 암호화. 이것은 ~ 때문이다 비대칭 암호화 대칭 등가물보다 훨씬 느립니다.
따라서, TLS 클라이언트와 서버가 대칭 키를 안전하게 교환 할 수 있도록 공개 키만 사용합니다. 그런 다음이 키를 사용하여 모든 후속 통신을 암호화하여 비대칭 암호화로 인한 성능 오버 헤드를 방지 할 수 있습니다.
TLS 1.2는 여러 키 교환 알고리즘 (예 : RSA, DH 등)과 여러 알고리즘 (또는 암호)는 메시지를 암호화하고 해독하는 데 사용됩니다. 이 대량의 대체 옵션을 사용하려면 클라이언트와 서버가 협상해야하므로 모든 당사자가 동일한 것을 사용할 수 있습니다 TLS 매개 변수를 설정합니다.
이 협상은 악수. 익숙하지 않은 경우 참조하십시오 이 문서
그래서 뭐가 잘못 됐어 TLS 1.2?
이기는하지만 TLS 1.2는 대부분의 경우 잘 작동하는 것으로 입증되었으며, 수년간의 패치 및 수정 후에 제공되는 전반적인 보안 및 개인 정보 보호 수준에 대한 우려가 있습니다.
그러나 보안 고려 사항 외에도 TLS 1.2는 또한 불필요한 성능과 네트워크 오버 헤드를 부과합니다.
TLS 1.2 보안 문제
수년에 걸쳐 연구원 (및 공격자)은 많은 취약점을 발견했습니다. TLS 1.2 키 교환 알고리즘, 암호 및 디지털 서명을 포함한 구성 요소 이것들 중 일부는 당신이 들었을 수도있는 구현 버그였습니다. Heartbleed와 or 맹렬한. 그러나 일부는 프로토콜 취약점이었습니다. 즉, 이전에 잘못된 설계 결정을 악용합니다. TLS 버전 (즉, 이전 TLS 1.2).
대부분의 구현 및 기타 버그가 수정되었지만 TLS 1.2, 불행히도 프로토콜 설계의 취약점은 소프트웨어 패치만으로는 치료할 수 없습니다. IETF는 핸드 셰이크 프로토콜을 완전히 재 설계해야했습니다. TLS 1.3.
에 대한 많은 우려가 있었다 TLS 보안에 가장 큰 영향을 미치는 것은 TLS 1.2 (및 SSL을 포함한 모든 이전 버전)는 핸드 셰이크 프로토콜 설계의 결함으로 인해 다운 그레이드 공격에 취약합니다. 더 구체적으로, TLS 1.2 핸드 셰이크의 무결성을 보호하기 위해 디지털 서명을 사용하지 않습니다. 서명은 암호-스위트 협상 후에 만 악수의 일부를 보호합니다.
결과적으로 공격자는 동일한 컴퓨터 네트워크 (예 : 공항 Wi-Fi)에서 발생하는 모든 타사 암호 스위트 협상을 조작하고 안전하지 않은 암호를 강제로 사용할 수 있습니다. 그런 다음 해당 취약한 암호를 차단하고 전체 대화에 대한 무단 액세스를 얻을 수 있습니다.
TLS 1.2 성능 문제
이러한 보안 고려 사항 외에도 TLS 1.2 수많은 협상 필요 TLS 매개 변수는 HTTPS (또는 기타 TLS 보호) 통신.
TLS 1.2의 4 단계 핸드 셰이크에는 두 번의 왕복 교환이 필요합니다. 먼저 암호화 제품군을 선택한 다음 인증서와 대칭 키 (또는 키 공유)를 교환해야합니다.
이것은 모든 TLS 연결될 것, 두 개의 추가 거래 서버와 함께 필요합니다. 결과적으로 TLS 연결에는 (암호화되지 않은) HTTP보다 더 많은 대역폭과 전력이 필요하며, 이는 낮은 전력 및 대역폭 소비가 어려운 제약 조건 인 IoT (Internet-of-Things) 응용 프로그램에 특히 비용이 많이들 수 있습니다.
TLS 1.2 개인 정보 보호 문제
마지막으로, TLS 1.2는 웹 사용자 개인 정보를 침해하는 것으로 비난을 받았습니다.
더 구체적으로, TLS 로 알려진 확장명을 제공합니다 서버 이름 표시 또는 SNI. SNI를 사용하면 서버의 호스트 이름을 초기 SSL 핸드 셰이크에 포함시킬 수 있습니다. 이 확장은 서버가 동일한 IP 주소 및 포트에서 여러 도메인을 제공하면서 각 도메인마다 다른 인증서를 제공 할 수있는 가상 호스팅에 사용됩니다.
In TLS 1.2, SNI가 전송됩니다 암호화되지 않은따라서 HTTPS를 사용하더라도 네트워크 공격자는이 정보를 유출하고 사용자가 방문한 웹 페이지를 추적 할 수 있습니다.
어떻게 TLS 1.3 모든 것을 고쳐?
TLS 1.2 (및 이전 버전)는 이전 버전과의 호환성을 유지하는 데 중점을 두었습니다. 각 버전은 이전 버전에서 작성된 취약점을 제거하려고 약간 수정하여 작성되었습니다. TLS 버전.
안타깝게도 잘못된 프로토콜 설계 결정 (예 : 보호되지 않은 핸드 셰이크)도 최신 버전에서 상속되었습니다.
TLS 1.3 적절한 보안 설계를 위해 하위 호환성을 포기합니다. 처음부터 처음부터 다음과 유사한 기능을 제공하도록 설계되었습니다 (아직 호환되지 않음). TLS 1.2, 그러나 성능, 개인 정보 보호 및 보안이 크게 개선되었습니다.
TLS 1.3 보안
핵심 교리 TLS 1.3은 단순하다. 새 버전에서는 키 교환 알고리즘을 제외한 모든 키 교환 알고리즘 디피 - 헬만 (DH) 키 교환이 제거되었습니다. TLS 1.3은 또한 시도되고 테스트 된 DH 매개 변수 세트를 정의하여 서버와 매개 변수를 협상 할 필요가 없습니다.
또 뭔데, TLS 1.3은 더 이상 CBC 모드 및 RC4 암호와 같이 불필요하거나 취약한 암호를 지원하지 않습니다. 이 암호는 공격에 취약한 것으로 알려져 있지만 대부분의 경우 여전히 지원됩니다 TLS 레거시 호환성을위한 구현. 다행히 최근에 다운 그레이드 공격이 조기에 영향을 미침 TLS 버전은 IETF가 그러한 암호를 완전히 제거하도록 동기를 부여했습니다. TLS 1.3.
또한, TLS 1.3 서버는 암호 협상을 포함하여 서버가 전체 핸드 셰이크에 암호로 서명해야하므로 공격자가 핸드 셰이크 매개 변수를 수정하지 못합니다. 이것은 TLS 1.3은 이전에 영향을받은 다운 그레이드 공격에 아키텍처 적으로 영향을 미치지 않습니다. TLS 버전.
마지막으로 시그니처 자체도 새로운 표준 인 RSA-PSS. RSA-PSS 서명은 이전에 사용 된 서명 체계에 영향을주는 암호화 공격에 영향을받지 않습니다. TLS 버전.
TLS 1.3 성능
보안 향상 외에도 매개 변수 세트 감소 및 핸드 셰이크 단순화 TLS 1.3은 또한 전반적인 성능 향상에 기여합니다. 키 교환 알고리즘이 하나만 있고 (베이크 인 매개 변수 포함) 소수의 지원되는 암호 만 있기 때문에 TLS 1.3 채널은 이전 버전보다 상당히 적습니다.
더욱이, TLS 1.3은 이제 새로운 핸드 셰이크 프로토콜을 지원합니다. 1-RTT 모드. 1-RTT에서 클라이언트는 서버가 사용할 매개 변수를 상당히 확신 할 수 있기 때문에 첫 번째 핸드 셰이크 메시지로 DH 키 공유를 보낼 수 있습니다. 드물기는하지만 서버에서 지원하지 않는 경우 클라이언트가 다른 구성을 보내도록 오류가 발생할 수 있습니다.
매개 변수를 먼저 협상 한 다음 키 또는 키 공유를 교환하는 대신, TLS 1.3 클라이언트가 TLS 한 번의 왕복 거래가있는 채널 (이전에 수행 한 두 개 대신). 이는 클라이언트가 서버를 통해 통신하는 데 필요한 처리, 전원 및 네트워크 리소스에 큰 영향을 줄 수 있습니다. TLS 1.3.
성능 최적화는 여기서 멈추지 않습니다. TLS 1.3 기능 0-RTT 재개 모드. 브라우저가 서버를 처음 방문하여 성공적으로 완료 한 경우 TLS 클라이언트와 서버 모두 사전 공유 암호화 키를 로컬로 저장할 수 있습니다.
브라우저가 서버를 다시 방문하면이 재개 키를 사용하여 첫 번째 메시지의 암호화 된 응용 프로그램 데이터를 서버로 보낼 수 있습니다. 초기 핸드 셰이크가 필요하지 않기 때문에 암호화되지 않은 HTTP와 동일한 대기 시간이 있습니다.
보안이 약간 있음에 유의해야합니다. 우려 과거에는 약 0-RTT 모드입니다.
TLS 1.3 개인 정보 보호 정책
과거의 실수로부터 배우고 TLS 1.3은 이제 확장자 SNI 정보를 암호화합니다. 이 확장을 올바르게 사용하면 공격자가 원격 서버의 도메인 이름을 유출하는 것을 방지하므로 HTTPS 사용자 기록을 추적 할 방법이 없습니다. 이 기능은 인터넷 사용자에게 이전 버전의 TLS.
결론
DaVinci에는 TLS 1.2 몇 년 동안 명예롭게 봉사했습니다. TLS 1.3 더 안전하고 효율적입니다. TLS 1.3은 실험적인 브라우저 구현에서 광범위하게 테스트되었으며 이제 교체 할 준비가되었습니다. TLS 선택한 네트워크 보안 프로토콜로 1.2. 출판 TLS 1.3은 더 빠르고 안전한 인터넷을 향한 큰 발걸음입니다.
SSL.com을 선택해 주셔서 감사합니다. 안전 인터넷은 더 인터넷.
