브라우저에 자물쇠 아이콘이 표시되면 해당 사이트가 SSL을 사용해 통신을 보호하고 있다고 생각하는 것이 자연스럽습니다. 또한 이 아이콘은 소비자에게 해당 사이트가 실제로 안전하다는 신호로 받아들여지는 듯합니다. 실제로 CA Security Council의 2015년 소비자 신뢰도 조사에 따르면, “자물쇠 아이콘이 없는 사이트에 신용카드 정보를 제공하겠다는 응답자는 3%에 불과했습니다.”
그 영향은 소비자에게만 국한되지 않습니다. 당사의 최신 애플리케이션 딜리버리 현황 설문조사에서 이미 ‘SSL Everywhere’를 구현했거나 구현할 계획이라고 답한 응답자들은 애플리케이션 계층 공격을 견뎌낼 수 있는 조직의 역량에 대해 더 높은 신뢰도(1~5점 척도에서 3점 이상)를 보였습니다.
사실 대부분의 사람들은 SSL이 무엇의 약자인지 설명하지 못하며, 작동 원리는 더더욱 알지 못합니다. 하지만 앱이나 웹사이트를 이용할 때 거래와 그에 수반될 수 있는 기밀 정보의 보안을 보장하는 메커니즘이라는 점은 알고 있습니다.
이는 부분적으로 우리(즉, 시장)의 잘못입니다. 우리는 SSL을 프로토콜(RFC 6101)을 지칭하는 용어로도, 보안 연결을 일반적으로 설명하는 표현으로도 사용해 왔습니다. SSL은 보안 업계의 밴드에이드이자, 검색 엔진 업계의 구글이며, 티슈 업계의 크리넥스입니다.
사실 HTTPS에 SSL이 반드시 필요한 것은 아닙니다. ‘HTTPS’의 ‘S’는 보안(secure)을 의미하며, 브라우저와 웹사이트 같은 두 엔드포인트 간의 연결을 보호할 수단만 있으면 됩니다. 그리고 점점 더 많은 경우, 이는 SSL이 아니라 TLS를 통한 HTTP를 의미합니다.
이는 중요한 차이입니다. TLS와 SSL은 뿌리는 같지만 서로 동일하지 않기 때문입니다. 둘은 서로 다른 프로토콜이며, 각각 고유한 과제와 문제점, 영향을 수반합니다. 둘 다 인증에는 인증서를, 암호화에는 공개 키/개인 키 쌍을 사용하는 동일한 방식으로 연결을 보호하지만, 구현상의 차이는 여전히 존재합니다.
왜 이 점에 주목해야 할까요? 최신 웹 애플리케이션 프로토콜(HTTP/2 및 SPDY)은 SSL을 지원하지 않기 때문입니다. 이 프로토콜들이 최고인지는 좀 더 지켜봐야겠지만, TLS는 지원합니다. 엄밀히 말해 TLS가 필수는 아니지만, 두 프로토콜을 모두 지원하는 브라우저 구현에서는 TLS를 통해서만 사용할 수 있습니다. SSL은 지원되지 않습니다.
물론 현재 HTTP/2나 SPDY를 사용하는 사이트가 많지는 않지만, 그 수는 점차 늘고 있습니다. 상위 1,000개 사이트 중 7.5%가 현재 HTTP/2를 통해 콘텐츠를 제공하고 있다는 점을 생각해 보십시오:
W3CTech 자료(2015년 7월):
2015년 5월에 최종 버전이 발표된 새로운 HTTP/2 표준은 현재 전체 웹사이트의 0.4%(월초의 0.24%에서 증가)와 상위 1,000개 사이트의 7.5%에서 사용되고 있습니다.
이제 브라우저와 서버만 이야기하는 것이 아니라는 점을 생각해 보세요. 통합 측면에서 이것이 무엇을 의미하는지도 고려해야 합니다. 즉, 상위 1,000개 사이트 중 일부(예: Google)에서 제공하는 API를 사용할 때 HTTP/2나 SPDY뿐 아니라 TLS까지 사용하도록 요구할 수 있다는 뜻입니다. 암호화를 제공하는 Google의 모든 공개 서비스는 TLS를 사용합니다. Google의 일부 기능을 통합하고 있다면 Google이 SSL 대신 TLS를 사용한다는 점이 중요할 수 있습니다. 내부 작동 방식에 차이가 생기기 때문입니다.
또한 비즈니스 측면에서도 파급 효과가 있다는 점에 유의해야 합니다. PCI 규정에 따라 2016년 6월 30일 이후에는 SSL을 더 이상 사용할 수 없으며, 그 이후부터는 TLS 사용이 명시적으로 요구됩니다. 따라서 PCI 규정을 계속 준수하려면 일부 변경이 필요합니다. 물론 규정을 준수해야 합니다. 그렇지 않으면 수많은 불이익이 따를 수 있기 때문입니다. 예를 들어 가맹점 계정 수수료가 인상되거나 신용카드 발급사로부터 벌금이 부과될 수 있으며, 결제 및 거래 처리 권한이 완전히 취소될 수도 있습니다. 보안과 관련해 상당한 주의 의무를 다하지 않은 상태에서 침해 사고가 발생하면 기업은 소송과 벌금에 노출될 위험이 더 커집니다.
마지막으로, 매우 강한 어조로 작성된 이 RFC(RFC 7568)에서는 TLS로 반드시 전환해야 하는 이유를 명확히 설명합니다:
3. SSL 버전 3.0을 사용하지 마십시오
SSLv3는 절대로 사용해서는 안 됩니다. 모든 버전의 TLS에서 SSLv3로 협상해서는 안 됩니다.
허용해서는 안 됩니다.
모든 버전의 TLS는 SSLv3보다 더 안전하지만, 가장 높은
사용 가능한 버전 중 가장 높은 버전을 사용하는 것이 좋습니다.
그렇다고 지금 당장 SSL에서 TLS로 전환할 수 있다고 생각하는 것은 현실적이지 않습니다. TLS는 SSL v3를 기반으로 하지만 이전 버전과 100% 하위 호환되지는 않으며, SSL을 비활성화하고 TLS를 강제로 사용하려면 몇 가지 구성 변경이 필요합니다. 이러한 구성 변경에는 일반적으로 재부팅이 필요합니다. 대규모 환경에서는 이 과정이 업무에 지장을 주고 많은 시간이 소요될 수밖에 없습니다.
하지만 이제 SSL 지원을 언제까지 유지할지, 그리고 언제 TLS만 사용하도록 전환할지 진지하게 고민해 볼 때입니다.
작성자 소개
Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.
Lori Mac Vittie의 다른 블로그 게시물관련 블로그 게시물
성평등을 향한 여정: 사이버 보안 분야에서 성공적인 커리어를 개척하는 방법에 관한 Jenn Gile과의 Q&A
F5의 ‘성평등을 향한 여정’ 시리즈 네 번째 Q&A에서는 Rachael Shah와 NGINX 제품 마케팅 책임자 Jenn Gile이 사이버 보안 직종에 대한 오해를 바로잡고, 사이버 보안 분야의 성별 격차를 해소하기 위한 조언과 그 이점에 대해 이야기합니다.
TLS 검사에서 피터 파커 원칙 다루기
“큰 힘에는 큰 책임이 따른다.” 볼테르와 처칠도 이와 비슷한 말을 남겼지만, 이 문구는 스파이더맨 코믹스에서 벤 삼촌의 말로 가장 널리 알려져 있습니다. 물론 이 문구가 문화적으로 널리 통용되는 이유 중 하나는 TLS 검사를 비롯해 수많은 상황과 주제에 적용할 수 있기 때문입니다.
Venafi와 F5를 통한 머신 아이덴티티 보호
‘머신 아이덴티티’란 간단히 말해 자동화된 프로세스가 자신의 신원을 식별할 수 있도록 하고, 다른 자동화 시스템과 프로세스가 관련 리소스에 적절한 수준의 접근 권한을 부여하도록 하는 방법을 의미합니다. 이 개념 자체는 새로운 것이 아닙니다. 비교적 새로운 점은 이를 구현해야 하는 규모입니다.
마이너와 미니언: 데이터 유출만이 비용을 초래하는 것은 아닙니다
물론 데이터 유출은 더 큰 비용을 초래할 수 있고(적어도 지금은), 실패 사실을 세상에 드러낼 수밖에 없게 합니다(통지 의무가 있으니까요). 하지만 보안을 단순히 데이터 노출 문제로만 봐서는 안 됩니다. 요즘은 데이터가...
내 클라우드에서 나가!
F5의 Jay Kelley가 전하는 최신 소식에는 Microsoft Office 365용 신규 ID 및 액세스 솔루션을 배포할 때 고려해야 할 사항이 정리되어 있습니다.
Shift(웹 앱) 보안 레터
웹 앱 보안을 개발 초기 단계로 앞당기세요. F5 블로그에서 DevOps 파이프라인 초기에 보안을 통합하여 취약점을 예방하고 시간을 절약하는 방법을 알아보세요.