블로그

암호화의 변화하는 세계: 2020년 TLS 배포

데이비드 워버튼 썸네일
데이비드 워버튼
2020년 7월 14일 게시

온라인 개인 정보 보호는 더 이상 단순히 엿보는 눈을 피하는 것만을 의미하지 않습니다. 웹 상의 암호화는 우리의 개인 정보를 보호하는 데 중요한 역할을 하며, 끊임없이 변화하고 있습니다.

로그인과 체크아웃 페이지에만 사용되던 TLS(전송 계층 보안)와 같은 암호화 프로토콜이 최근에 각광을 받고 있으며, 엔드포인트를 인증하고 기밀을 유지하며 통신할 수 있는 방법을 제공합니다. 지난 2년 동안 TLS 표준도 업데이트되었습니다. 브라우저는 곧 TLS 1.0 및 1.1과 같은 오래되고 취약한 프로토콜 구현을 차단할 것입니다. 오늘날에도 널리 사용되는 안전하지 않은 프로토콜을 잠그기 위해 새로운 프로토콜도 도입되고 있습니다.

기업들이 이러한 추세에 발맞추는 데 어려움을 겪는다는 것은 쉽게 알 수 있습니다. 예를 들어 작년 초, 보안 연구원들은 새로운 도메인 이름 시스템 암호화 프로토콜인 DNS-over-HTTPS(DoH)를 사용하는 최초의 맬웨어 샘플을 발견했습니다.

TLS 환경은 예전과 같지 않으며, 조직은 웹사이트가 안전하게 배포되고 수명 동안 유지되도록 하기 위해 최신 개발 사항을 최신 상태로 유지해야 합니다.

변화에 발맞추다

대부분의 기업은 새로운 TLS 업데이트가 가져올 수 있는 이점을 알고 있으며, 이에 적극적으로 변화를 수용하는 것으로 보입니다. 예를 들어, F5 Labs의 최신 TLS 원격 측정 보고서에 따르면 Alexa 상위 100만 개 사이트 중 거의 3분의 1이 TLS 1.3 연결을 허용하고 있는 것으로 나타났습니다. 여러 면에서 이는 사업적으로 좋은 이치에 맞습니다. 대부분 인기 웹 브라우저는 이미 새로운 표준을 지원하고 있으며, 이 표준은 다양한 보안 및 성능상의 이점을 제공합니다.

하지만 최신 TLS를 도입하는 것은 아직 모든 사람에게 가능한 일은 아닙니다.

이 경우 회사에서는 해당 기능을 제공하는 암호화 제품군을 제거하여 RSA 키 교환을 완전히 비활성화하는 것을 고려해야 합니다. F5 연구에 따르면 세계에서 가장 인기 있는 웹사이트의 3분의 1 이상이 여전히 RSA를 선호하는 암호화 알고리즘으로 제공하고 있습니다. 보안 연구원들은 여전히 RSA를 공격할 방법을 찾고 있습니다. 여기에는 TLS 서버의 개인 키를 사용하여 RSA 암호 해독 및 서명 작업을 수행할 수 있는 19년 된 ROBOT 취약성이 포함됩니다. F5 Labs 조사에 따르면, 전 세계 상위 사이트 중 2%가 조금 넘는 사이트만이 여전히 이 악용에 취약할 가능성이 높습니다.

다른 소프트웨어와 마찬가지로 보안 연구원은 종종 TLS 라이브러리의 취약점을 발견합니다. 따라서 조직에서는 웹 서버, 로드 밸런서 또는 애플리케이션 전송 컨트롤러의 TLS 스택이 업데이트될 때 알림을 받도록 해야 합니다. 신속한 패치 정책 역시 중요합니다.

또한 모든 인증 기관(CA)이 웹상의 모든 도메인에 대한 인증서를 만들 수 있다는 점도 알아두는 것이 중요합니다. 이러한 이유로 두세 개의 잘 알려지고 신뢰할 수 있는 CA에만 권한을 제한하는 것이 좋습니다. 이는 DNS 인증 기관 승인(CAA) 레코드를 생성하여 달성할 수 있습니다. 또한, 웹 앱에 HSTS(HTTP Strict Transport Security) 헤더를 적용하면 브라우저가 HTTPS를 통해서만 사이트를 안전하게 로드하려고 시도하므로 보안 계층이 추가로 제공됩니다. 이는 안전하지 않은 페이지가 로드되도록 강제하는 네트워크 공격을 방지하는 데 도움이 되는 중요한 단계이며, 공격자가 네트워크 트래픽을 감청하고, 다시 쓰고, 리디렉션할 수 있도록 합니다.

DNS CAA 레코드는 유효한 도메인에 대한 인증서가 잘못 발급되는 것을 방지하기 위해 만들어졌지만 사기꾼이 mybank.com과 같은 기존 도메인에 대한 인증서를 만들려고 시도하는 경우는 거의 없습니다. 대신 그들은 'mybank'라는 브랜드 이름을 하위 도메인으로 사용하여 자신이 소유한 도메인에 대한 인증서를 만듭니다(예: mybank.attacker.com).

다행히도, 모든 CA에서 인증서를 생성할 때마다 이는 전 세계적으로 분산된 데이터베이스(인증서 투명성 로그)에 기록됩니다. CT 로그를 모니터링하면 위협 행위자가 도메인이나 브랜드를 사칭할 때 알림을 받을 수 있는 유용한 방법입니다.

이제 HTTPS가 널리 사용되면서 관리해야 할 암호, 키, 인증서도 늘어났습니다. DevOps 방법론의 채택이 증가함에 따라 이는 변화와 배포 속도가 끊임없이 빨라지고 있음을 의미합니다.

보안 도구와 테스트가 자동화 툴체인에 통합되는 것처럼 HTTPS 구성 역시 통합되어야 합니다. 즉, 디지털 인증서의 조직적인 생성을 검토하고 최소 키 길이 및 암호화 제품군과 같은 표준을 정의하는 내부 정책을 개발하는 것을 의미합니다. 이러한 특성의 자동화는 만료 예정인 인증서를 처리하는 데도 도움이 되며, 서비스가 중단되기 전에 인증서를 자동으로 갱신합니다. 

TLS 보안 격차를 주의하다

불행히도 TLS가 올바르게 배포된 경우에도 여전히 많은 개인정보 보호 및 보안 허점이 존재합니다. DoH(DNS-over-HTTPS)와 같은 프로토콜은 이런 격차를 메우는 데 도움이 되는 것으로 부상하고 있으며, 웹 사용자의 개인 정보 보호는 향상되지만, 기업 보안팀이 악성 트래픽을 식별하여 차단하기 어렵게 만들 수도 있습니다. 어떤 경우에는 기업 네트워크의 DoH를 비활성화하거나 사용자를 위한 내부 DoH 서비스를 배포해야 합니다. 이러한 서비스는 웹 프록시와 함께 작동하여 원치 않는 트래픽을 걸러내는 데 도움이 됩니다.

결국, 세계 최고의 TLS 배포조차도 클라이언트 측 맬웨어에 의해 악성 코드가 삽입되거나 타사 스크립트로 인해 손상되는 것을 막을 수 없습니다. 따라서 HTTPS의 한계와 존재하는 차이점을 항상 이해하는 것이 좋습니다.

확실한 점 하나는 암호화가 끊임없이 발전하고 있다는 것입니다. 키 길이가 늘어나고, 인증서가 자동화되고, 정부가 제한을 가하고, 새로운 프로토콜이 등장하고 있습니다. 이러한 끊임없는 변화는 많은 기업과 고객에게 새로운 차원의 위험을 초래합니다. TLS 배포가 제대로 되지 않으면 해커, 규제 기관 및 사이버 보안 보험 회사는 이를 간과할 수 없으며 조직의 나머지 인프라에 대한 심각한 의문을 제기할 수 있습니다.