자물쇠 아이콘이 떴다고 안전한 것이 아닙니다. 그 자물쇠가 얼마나 단단한지가 중요합니다.
들어가며: 암호화는 기본값이지 옵션이 아니다
2부에서 우리는 서버에 접근하는 경로를 단단히 했습니다. 3부에서는 시선을 돌립니다. 데이터가 네트워크를 오갈 때, 그 통신 자체를 어떻게 보호하는가입니다. 그 핵심에 TLS가 있습니다.
TLS(Transport Layer Security)는 인터넷 통신을 암호화하는 표준 기술입니다. 웹 주소가 https로 시작하고 브라우저에 자물쇠 아이콘이 뜨는 것이 바로 TLS가 작동하고 있다는 표시입니다. TLS는 세 가지를 보장합니다. 기밀성(통신 내용을 제3자가 엿볼 수 없음), 무결성(통신 내용이 중간에 변조되지 않음), 그리고 인증(접속한 상대가 진짜 그 서버임을 확인).
오늘날 TLS는 선택이 아니라 기본값입니다. 암호화되지 않은 통신은 같은 네트워크에 있는 누구나 엿볼 수 있고, 중간에서 변조할 수 있습니다. 공공 와이파이에서 암호화 없이 로그인하면, 같은 네트워크의 공격자가 그 자격 증명을 그대로 가로챌 수 있습니다. 그래서 모든 웹 통신은 TLS로 암호화되어야 합니다. 이것은 논쟁의 여지가 없는 현대의 기본입니다.
그러나 이 장의 핵심은 더 미묘합니다. TLS를 켜는 것과 TLS를 제대로 설정하는 것은 다릅니다. 자물쇠 아이콘이 떴다고 해서 그 통신이 충분히 안전한 것은 아닙니다. 낡고 약한 버전의 TLS, 취약한 암호 알고리즘, 잘못된 인증서 설정 — 이 모든 것이 자물쇠 아이콘 뒤에 숨어 있을 수 있습니다. 공격자는 바로 이 약한 설정을 노립니다. 서문에서 지적한 "TLS 1.0이 아직 열려 있는 사이트"가 바로 이 문제입니다.
이 장에서는 TLS를 제대로 설정하는 법을 다룹니다. 왜 낡은 버전을 꺼야 하는지, 어떤 암호 알고리즘을 써야 하는지, 인증서를 어떻게 관리하는지, 그리고 무엇보다 — 자신의 설정이 실제로 안전한지를 SSL Labs로 검증하고 최고 등급(A+)을 받는 구체적인 방법을 살펴봅니다. 이것은 4부의 "검증" 정신을 미리 적용하는 것이기도 합니다. 설정했다고 믿지 말고, 측정하여 확인하는 것입니다(원칙 4).
8.1 TLS 버전: 낡은 것을 죽여야 하는 이유
TLS에는 여러 버전이 있고, 시간이 지나며 발전해 왔습니다. 핵심 원칙은 간단합니다. 낡은 버전을 비활성화하고, 충분히 현대적인 버전만 허용하라. 구체적으로, 오래되고 취약한 것으로 판명된 초기 버전들을 끄고, TLS 1.2 이상만 허용해야 합니다.
왜 낡은 버전이 위험한가
초기의 TLS 버전들(그리고 그 전신인 SSL)은 시간이 지나며 여러 심각한 약점이 발견되었습니다. 이 약점들은 단순한 이론적 문제가 아니라, 실제로 통신을 복호화하거나 변조할 수 있는 공격으로 이어졌습니다. 암호 기술은 시간이 지나면서 연구자들에 의해 약점이 드러나고, 계산 능력이 발전하며, 새로운 공격 기법이 등장합니다. 한때 안전했던 것이 더 이상 안전하지 않게 됩니다.
그래서 낡은 TLS/SSL 버전을 계속 허용하는 것은, 알려진 약점을 가진 문을 열어 두는 것과 같습니다. 설령 서버가 최신 버전도 지원한다 해도, 낡은 버전을 함께 허용하면 공격자가 통신을 낡은 버전으로 끌어내리도록(다운그레이드 — 양쪽이 합의하는 버전을 약한 쪽으로 깎아내리는 수법) 유도하여 그 약점을 악용할 수 있습니다. 따라서 낡은 버전은 단지 쓰지 않는 것을 넘어, 명시적으로 비활성화해야 합니다.
이 "알려진 약점에 패치·대안이 이미 있는데도 옛 설정을 그대로 둬서 당하는" 패턴은 TLS만의 이야기가 아닙니다. 예컨대 Citrix Bleed(CVE-2023-4966)는 고칠 방법이 있었는데도 적용하지 않은 곳들이 대규모로 침해당한 사건이었습니다. 2026년 현재에도 공격자들이 가장 즐겨 찾는 것은 새로운 0-day가 아니라, 이렇게 "닫을 수 있었는데 열려 있는 문"입니다. 낡은 TLS 버전을 끄지 않고 방치하는 것이 바로 그런 문 중 하나입니다.
무엇을 허용할 것인가
현재 권장되는 기준은 TLS 1.2와 TLS 1.3만 허용하고, 그 이전 버전은 모두 비활성화하는 것입니다.
TLS 1.3은 가장 최신 버전으로, 이전 버전들의 약점을 제거하고, 더 안전한 기본 설정을 강제하며, 연결 속도도 개선했습니다. 가능한 한 TLS 1.3을 우선하고, 아직 TLS 1.3을 지원하지 못하는 일부 환경을 위해 TLS 1.2를 함께 허용하는 것이 현실적인 구성입니다.
TLS 1.2 이전의 버전들은 비활성화해야 합니다. 이들을 허용하는 것은 서문에서 지적한 "10년 지난 기술"의 전형이며, SSL Labs 평가에서도 즉시 감점 요인이 됩니다.
호환성에 대한 현실적 고려
낡은 버전을 끄면 아주 오래된 일부 클라이언트가 접속하지 못할 수 있다는 우려가 있습니다. 그러나 현대의 거의 모든 브라우저와 클라이언트는 TLS 1.2 이상을 지원합니다. TLS 1.2 이전 버전만 지원하는 클라이언트는 극히 오래된 것으로, 그런 클라이언트를 위해 보안을 희생하는 것은 잘못된 거래입니다. 오히려 그렇게 오래된 클라이언트는 그 자체로 다른 보안 위험을 안고 있을 가능성이 높습니다. 대부분의 경우, TLS 1.2 이상만 허용해도 실질적인 호환성 문제는 발생하지 않습니다.
8.2 암호 스위트: 무엇으로 암호화할 것인가
TLS 버전을 정한 다음 단계는, 실제 암호화에 사용할 알고리즘의 조합 — 암호 스위트(cipher suite) — 를 선택하는 것입니다.
암호 스위트란 무엇인가
하나의 TLS 연결은 여러 암호 알고리즘의 조합으로 보호됩니다. 키를 교환하는 방식, 데이터를 암호화하는 방식, 무결성을 검증하는 방식 등이 결합되어 하나의 암호 스위트를 이룹니다. 서버와 클라이언트는 연결을 맺을 때, 양쪽이 모두 지원하는 암호 스위트 중 하나를 골라 사용합니다.
문제는, TLS 버전과 마찬가지로 암호 알고리즘에도 강약이 있다는 것입니다. 어떤 알고리즘은 시간이 지나며 약점이 드러났고, 어떤 것은 여전히 견고합니다. 약한 암호 스위트를 허용하면, 통신이 그 약한 방식으로 보호되어 공격에 노출될 수 있습니다.
강한 것만 허용하고, 순서를 정한다
암호 스위트 설정의 원칙은 두 가지입니다.
첫째, 약한 것을 배제합니다. 알려진 약점이 있는 암호 알고리즘, 더 이상 안전하지 않은 것으로 판명된 것들을 비활성화합니다. 오래된 암호화 방식, 약한 키 교환, 취약한 해시 등이 여기에 해당합니다.
둘째, 강한 것을 우선합니다. 여러 안전한 암호 스위트 중에서도, 더 강하고 효율적인 것을 우선적으로 선택하도록 순서를 정합니다. 특히 중요한 속성으로 순방향 비밀성(forward secrecy) 이 있습니다. 이것은 설령 서버의 키가 미래에 유출되더라도, 과거에 주고받은 통신은 복호화할 수 없게 하는 성질입니다. 순방향 비밀성을 제공하는 암호 스위트를 우선하면, 키 유출의 피해가 과거로 소급되지 않게 가둘 수 있습니다. 이것은 침해를 가정하는 원칙 2의 암호학적 적용입니다.
구체적 목록은 최신 가이드를 따른다
여기서 중요한 실용적 조언이 있습니다. 어떤 암호 스위트가 안전한지는 시간에 따라 변합니다. 오늘 권장되는 목록이 몇 년 뒤에는 갱신될 수 있습니다. 따라서 이 책에 특정 목록을 박제하는 것보다, 신뢰할 수 있는 출처가 제공하는 최신 권장 설정을 따르는 것이 옳습니다.
다행히, 주요 서버 소프트웨어에 대한 안전한 TLS 설정을 자동으로 생성해 주는 신뢰할 수 있는 도구들이 있습니다. 대표적인 것이 Mozilla SSL Configuration Generator입니다. 서버 소프트웨어(Nginx, Apache 등)와 버전, 그리고 보안 수준(현대적/중간/구형 호환)을 선택하면, 그에 맞는 최신 권장 설정 — 허용할 TLS 버전과 암호 스위트 목록을 포함한 — 을 그대로 복사해 쓸 수 있게 생성해 줍니다. 이렇게 생성된 설정을 적용하면, 직접 암호 스위트를 일일이 고르는 것보다 안전하고 최신 상태를 유지하기 쉽습니다. 그리고 이것을 정기적으로 다시 확인하여 갱신하는 것이 원칙 5(과정으로서의 보안)에 부합합니다.
무엇을 고를까. 대상 독자 대부분에게는 "중간(Intermediate)" 프로파일이 정답입니다. 현대적인 거의 모든 브라우저·클라이언트와 호환되면서도 안전합니다. "구형(Old)"은 아주 오래된 클라이언트까지 받아야 하는 특수한 경우에만 쓰고, 평소에는 절대 기본값으로 삼지 마십시오 — 그 순간 8.1에서 끄라고 한 낡은 프로토콜이 다시 켜집니다. 내가 서버 설정을 새로 잡을 때 가장 먼저 여는 페이지가 바로 이 생성기입니다. 손으로 암호 스위트를 나열하던 시절에는 오타 하나로 약한 스위트가 슬쩍 끼어드는 일이 잦았는데, 이 도구로 바꾼 뒤로는 그런 사고가 사라졌습니다.
8.3 인증서: 신뢰의 토대
TLS의 인증 기능 — 접속한 상대가 진짜 그 서버임을 확인하는 것 — 은 인증서(certificate)에 기반합니다. 인증서 관리는 TLS 설정의 중요한 한 축입니다.
인증서의 역할
인증서는 "이 도메인이 진짜 이 서버의 것"임을 신뢰할 수 있는 제3자(인증 기관, CA)가 보증하는 전자 문서입니다. 브라우저는 이 인증서를 검증하여, 접속한 서버가 사칭이 아닌 진짜임을 확인합니다. 인증서가 없거나 유효하지 않으면, 브라우저는 경고를 표시합니다. 이 검증이 없다면, 공격자가 중간에서 서버인 척 가장하여 통신을 가로챌 수 있습니다(중간자 공격).
무료 인증서와 자동 갱신
과거에는 인증서 발급에 비용과 번거로움이 따랐지만, 이제는 Let's Encrypt 같은 무료 인증 기관 덕분에 누구나 비용 없이 신뢰받는 인증서를 발급받을 수 있습니다. 이것이 HTTPS가 보편화된 큰 이유입니다. ACME(인증서 발급·갱신을 자동화하는 표준 프로토콜)를 통해 발급 전 과정을 기계가 처리하므로, 사람이 개입할 일이 사실상 없습니다.
다만 이런 무료 인증서는 유효 기간이 비교적 짧습니다. 이것은 보안상 의도된 설계입니다. 인증서가 자주 갱신되면, 설령 키가 유출되어도 그 영향 기간이 짧기 때문입니다. 짧은 유효 기간의 단점 — 자주 갱신해야 하는 번거로움 — 은 자동화로 해결합니다.
인증서 갱신은 반드시 자동화하십시오. ACME 프로토콜을 지원하는 도구(certbot 등)를 쓰면, 인증서 발급과 갱신을 자동으로 처리할 수 있습니다. 자동 갱신을 설정해 두면, 사람이 신경 쓰지 않아도 인증서가 만료 전에 갱신됩니다. 자동 갱신을 설정하지 않으면, 어느 날 인증서가 만료되어 서비스에 접속할 때 보안 경고가 뜨는 사고가 발생합니다. 이것은 매우 흔한 운영 사고이며, 자동화로 완전히 예방할 수 있습니다.
# certbot을 이용한 인증서 발급 예시 (Nginx)
sudo certbot --nginx -d example.com -d www.example.com
# 자동 갱신이 설정되었는지 확인 (대개 자동으로 타이머가 등록됨)
sudo certbot renew --dry-run6장에서 Cloudflare를 쓰는 경우에는, Cloudflare가 인증서를 관리해 주므로 이 부분이 단순해집니다. 다만 Cloudflare와 오리진 서버 사이의 통신도 암호화되도록 설정하는 것을 잊지 마십시오. 구체적으로는 Cloudflare 대시보드의 SSL/TLS 암호화 모드를 반드시 Full (Strict) 로 두십시오 — "Flexible"로 두면 사용자~Cloudflare 구간만 암호화되고 Cloudflare~오리진 구간은 평문으로 오가, 8.5에서 경고하는 "오리진 통신 미암호화" 함정에 그대로 빠집니다.
OCSP 스테이플링
인증서와 관련된 추가 최적화로 OCSP 스테이플링(OCSP stapling)이 있습니다. 이것은 인증서가 폐기되지 않았는지를 확인하는 과정을 효율화하는 기술입니다. 서버가 인증서의 유효성 증명을 미리 받아 두었다가 연결 시 함께 제공함으로써, 클라이언트가 별도로 확인하는 부담을 줄이고 속도와 프라이버시를 개선합니다. 이것은 SSL Labs 평가에서도 긍정적으로 반영되는 항목입니다. 대부분의 현대 서버 소프트웨어에서 간단한 설정으로 활성화할 수 있습니다.
8.4 SSL Labs로 검증하기: A+를 받는 길
이제 이 장의 가장 실용적인 부분입니다. 지금까지의 설정이 실제로 안전한지를 어떻게 확인할까요? 그리고 어떻게 최고 등급을 받을까요?
측정하지 않으면 모른다
이 책의 네 번째 원칙은 "검증 없는 보안은 희망일 뿐이다"입니다. TLS 설정만큼 이 원칙이 잘 적용되는 영역도 드뭅니다. 설정 파일에 무언가를 적어 넣었다고 해서 그것이 의도대로 작동하는지는, 실제로 측정해 보기 전에는 알 수 없습니다. 설정의 오타, 예상치 못한 기본값, 소프트웨어 버전의 차이 등으로 인해, 의도와 실제가 어긋나는 경우가 흔합니다.
다행히 TLS 설정을 정밀하게 측정하는 훌륭한 무료 도구가 있습니다. SSL Labs의 SSL 서버 테스트입니다. 이 도구는 당신의 서버에 실제로 연결하여, TLS 설정의 모든 측면을 점검하고, A+부터 F까지의 등급으로 평가합니다. 그리고 단순히 등급만 주는 것이 아니라, 무엇이 좋고 무엇이 문제인지를 상세히 알려 줍니다.
자신의 서버 도메인을 SSL Labs 테스트에 입력하면, 잠시 후 상세한 평가 보고서를 받을 수 있습니다. 이것은 자신의 서버에 대한 점검이므로 합법적이며, 정기적으로 수행할 가치가 있습니다. 한 가지만 유의하십시오 — SSL Labs는 기본적으로 결과를 게시판에 공개하므로, 점검 전에 "Do not show the results on the boards" 항목을 체크해 두면 우리 도메인의 평가 내역이 외부에 노출되지 않습니다.
등급은 무엇으로 결정되는가
SSL Labs의 등급은 여러 요소를 종합하여 매겨집니다. 핵심 요소들은 이 장에서 다룬 것들과 정확히 일치합니다.
- 프로토콜 버전. 낡은 버전을 허용하면 감점되고, 심하면 등급에 상한이 걸립니다(8.1). TLS 1.2 이상만 허용해야 높은 등급이 가능합니다.
- 암호 스위트. 약한 암호 스위트를 허용하면 감점됩니다(8.2). 강한 것만 허용하고 순방향 비밀성을 제공해야 합니다.
- 인증서. 인증서가 유효하고, 올바르게 구성되어 있으며, 신뢰 사슬이 완전해야 합니다(8.3).
- 키 교환과 암호 강도. 충분히 강한 키와 안전한 키 교환 방식을 써야 합니다.
낮은 등급(C 이하)이나 경고가 나온다면, 보고서가 그 원인을 짚어 줍니다. 대개는 낡은 프로토콜이 켜져 있거나, 약한 암호 스위트가 허용되어 있거나, 인증서 사슬에 문제가 있는 경우입니다. 보고서의 지적을 하나씩 해결하면 등급이 올라갑니다.
A에서 A+로
기본적인 설정을 제대로 하면 A 등급에 도달합니다. A에서 한 단계 더 나아가 A+를 받으려면, 추가적인 보안 강화가 필요합니다. 그 핵심이 바로 다음 장에서 다룰 HSTS입니다.
HSTS는 브라우저에게 "이 사이트는 앞으로 항상 HTTPS로만 접속하라"고 지시하는 보안 헤더입니다. 이것을 올바르게 설정하면 SSL Labs에서 A+를 받을 수 있습니다. HSTS는 단순히 등급을 올리기 위한 것이 아니라, 그 자체로 중요한 보안 메커니즘이며, 잘못 설정하면 위험할 수도 있는 까다로운 측면이 있습니다. 그래서 다음 장(9장)에서 HSTS와 다른 보안 헤더들을 별도로 깊이 다룹니다. TLS 설정(8장)과 보안 헤더(9장)는 함께 작동하여 전송 계층 방어를 완성합니다.
요컨대, A+로 가는 길은 이렇습니다. 이 장의 설정(낡은 프로토콜 비활성화, 강한 암호 스위트, 올바른 인증서, OCSP 스테이플링)으로 A 등급의 토대를 만들고, 다음 장의 HSTS로 A+를 완성하는 것입니다.
정기적으로 다시 측정하라
한 번 A+를 받았다고 영원히 A+인 것은 아닙니다. 시간이 지나면 한때 안전했던 설정이 약해질 수 있고(8.2에서 본 암호 알고리즘의 노화), 소프트웨어 업데이트로 설정이 바뀔 수도 있습니다. SSL Labs 테스트를 정기적으로 다시 수행하여, 등급이 유지되는지 확인하십시오. 이것은 원칙 5(과정으로서의 보안)의 적용이며, 10장에서 다룰 자가 진단의 일부입니다.
SSL Labs는 브라우저로 한 번 돌려 보기에 좋지만, 내부망 서버처럼 외부에서 닿지 않는 대상이거나 점검을 스크립트로 자동화하고 싶다면 명령줄 도구가 더 편합니다. testssl.sh는 설치가 필요 없는 셸 스크립트 하나로 TLS 버전·암호 스위트·인증서·알려진 취약점을 한 번에 점검해 줍니다.
# testssl.sh — 한 줄로 종합 점검 (자신이 운영하는 서버에만 사용)
./testssl.sh https://example.comsslyze는 파이썬 기반의 또 다른 점검 도구로, 결과를 JSON으로 뽑아 CI 파이프라인이나 정기 작업에 끼워 넣기 좋습니다. 내가 운영하는 서버들에서는 이런 도구를 주기적 작업으로 걸어 두고, 등급이 떨어지면 알림이 오게 해 둡니다 — A+는 한 번 받는 점수가 아니라 유지해야 하는 상태이기 때문입니다(10장).
8.5 흔한 실수와 함정
TLS 설정에서 자주 발생하는 실수들을 정리합니다. 이것을 미리 알면 같은 함정을 피할 수 있습니다.
낡은 버전을 끄지 않음. 가장 흔한 문제입니다. 최신 버전을 추가하면서 낡은 버전을 끄는 것을 잊어, 둘 다 허용된 상태로 둡니다. 다운그레이드 공격의 여지를 남기고 등급도 깎입니다.
인증서 사슬이 불완전함. 인증서는 단독으로 존재하지 않고, 신뢰 사슬(중간 인증서)을 동반합니다. 이 사슬이 불완전하면, 일부 클라이언트에서 인증서가 신뢰되지 않거나 경고가 발생합니다. 서버 자신에서는 잘 보여도 다른 환경에서 문제가 생길 수 있으므로, SSL Labs로 사슬의 완전성을 확인해야 합니다.
자동 갱신 미설정으로 인한 만료. 8.3에서 강조했듯, 자동 갱신을 설정하지 않아 인증서가 만료되는 사고가 흔합니다. 갱신을 자동화하고, 자동화가 실제로 작동하는지 검증하십시오(--dry-run).
설정만 하고 검증하지 않음. 설정 파일을 수정한 뒤 실제로 측정하지 않아, 의도와 다른 결과가 방치됩니다. 항상 SSL Labs로 결과를 확인하십시오(원칙 4).
오리진 통신을 암호화하지 않음. 6장에서 Cloudflare 같은 프록시를 쓸 때, 사용자와 프록시 사이는 암호화되지만 프록시와 오리진 서버 사이는 암호화되지 않은 채로 두는 실수가 있습니다. 이 경우 그 구간이 노출됩니다. 종단 간 암호화가 유지되도록 설정해야 합니다.
혼합 콘텐츠(mixed content). HTTPS 페이지가 일부 자원(이미지, 스크립트 등)을 HTTP로 불러오면, 그 부분이 암호화되지 않아 전체 보안이 약화되고 브라우저 경고가 발생합니다. 모든 자원이 HTTPS로 로드되도록 해야 합니다.
8.6 이 장이 남기는 교훈
이 장에서 확인한 것을 압축합니다.
첫째, 암호화는 기본값이지 옵션이 아닙니다. 모든 웹 통신은 TLS로 암호화되어야 하며, 이것은 논쟁의 여지가 없는 현대의 기본입니다.
둘째, TLS를 켜는 것과 제대로 설정하는 것은 다릅니다. 자물쇠 아이콘이 떴다고 안전한 것이 아닙니다. 약한 버전과 약한 암호 스위트가 그 뒤에 숨어 있을 수 있습니다.
셋째, 낡은 버전은 명시적으로 비활성화해야 합니다. TLS 1.2 이상만 허용하고 그 이전은 모두 끄십시오. 단지 안 쓰는 것을 넘어 다운그레이드 공격을 막기 위해 명시적으로 차단해야 합니다.
넷째, 암호 스위트는 강한 것만, 순방향 비밀성을 우선하여 허용하십시오. 구체적 목록은 시간에 따라 변하므로, 신뢰할 수 있는 도구가 생성하는 최신 권장 설정을 따르고 정기적으로 갱신하십시오.
다섯째, 인증서는 자동 갱신하십시오. 무료 인증서와 ACME 자동화로 비용과 만료 사고를 모두 해결할 수 있습니다. OCSP 스테이플링도 활성화하십시오.
여섯째, 측정하지 않으면 모릅니다. SSL Labs로 설정을 검증하고, A 등급의 토대를 만든 뒤, 다음 장의 HSTS로 A+를 완성하십시오. 그리고 정기적으로 다시 측정하십시오(원칙 4, 5).
이 장에서 우리는 통신을 단단히 암호화했습니다. 그러나 전송 계층 방어는 암호화만으로 완성되지 않습니다. 브라우저에게 어떻게 행동하라고 지시하는 보안 헤더들이 또 다른 중요한 방어 계층을 이룹니다. 그리고 그중 하나인 HSTS가 바로 A+의 마지막 열쇠입니다. 다음 장에서 HSTS를 비롯한 보안 헤더들을 한 줄씩 살펴보겠습니다.
이 장의 실행 항목
- TLS 1.2 이상만 허용하고 이전 버전을 비활성화하십시오. 명시적으로 끄십시오. (8.1)
- 강한 암호 스위트만 허용하십시오. 신뢰할 수 있는 도구로 최신 권장 설정을 생성해 적용하십시오. (8.2)
- 인증서 자동 갱신을 설정하고 검증하십시오.
--dry-run으로 자동화가 작동함을 확인하십시오. (8.3) - OCSP 스테이플링을 활성화하십시오. (8.3)
- SSL Labs로 자신의 서버를 측정하십시오. 등급과 지적 사항을 확인하고 하나씩 해결하십시오. (8.4)
- 흔한 함정을 점검하십시오. 인증서 사슬, 오리진 암호화, 혼합 콘텐츠를 확인하십시오. (8.5)
- 정기적으로 다시 측정하십시오. A+는 유지해야 하는 상태입니다. (8.4, 10장)
다음 장: 9장 — HSTS와 보안 헤더. A+의 마지막 열쇠, 그리고 한 줄씩 설정하는 방어 헤더들.