TLS 제대로 설정하기: TLS 1.2 이상만 허용하고 SSL Labs A+ 받는 실전 가이드

브라우저 주소창에 자물쇠가 떴다고 안심하셨나요? 그 자물쇠가 종이로 만든 것인지 강철로 만든 것인지는 아무도 알려주지 않습니다. HTTPS를 "켰다"는 사실과 HTTPS를 "제대로 설정했다"는 사실 사이에는 생각보다 큰 골짜기가 있습니다.

웹 트래픽을 가로채려는 공격자에게 가장 매력적인 표적은 암호화를 아예 하지 않은 사이트가 아닙니다. 그런 사이트는 이제 거의 없으니까요. 진짜 노림수는 암호화를 켜 두었지만 10년 전 설정을 그대로 방치한 서버입니다. TLS 1.0이 여전히 열려 있고, 약한 암호 알고리즘이 협상 목록에 남아 있으며, 인증서 체인이 군데군데 끊겨 있는 그런 서버 말입니다. 자물쇠 아이콘은 똑같이 떠 있지만, 그 뒤는 비어 있습니다.

이 글은 그 골짜기를 건너는 방법을 다룹니다. 어떤 TLS 버전을 살려 두고 어떤 것을 죽여야 하는지, 암호 스위트는 무엇을 기준으로 고르는지, 인증서를 사람 손 안 타게 굴리는 법, 그리고 무엇보다 — 내가 한 설정이 정말 안전한지를 측정해서 확인하고 SSL Labs에서 A+ 등급을 받아내는 실전 절차까지. "했다고 믿는 것"과 "측정해서 확인한 것"은 완전히 다른 이야기입니다.

TLS가 실제로 보장하는 세 가지

먼저 용어부터 정리하겠습니다. TLS(Transport Layer Security)는 인터넷 위를 오가는 데이터를 암호화하는 표준 프로토콜입니다. 주소가 http가 아니라 https로 시작하고 브라우저에 자물쇠가 보이는 것이 바로 TLS가 일하고 있다는 신호죠. TLS가 통신에 부여하는 보장은 정확히 세 가지입니다.

이 세 가지가 왜 필수인지는 공공 와이파이를 떠올리면 바로 와닿습니다. 카페 무선망에서 암호화 없이 로그인하면, 같은 망에 앉아 있는 누군가가 그 아이디와 비밀번호를 그대로 주워 갈 수 있습니다. 그래서 오늘날 모든 웹 통신의 암호화는 선택지가 아니라 출발선입니다. 여기까지는 논쟁의 여지가 없습니다.

문제는 그 다음입니다. 암호화를 "켜는 것"은 시작일 뿐이고, 이 글이 진짜로 하고 싶은 이야기는 그 설정을 단단하게 만드는 방법입니다.

낡은 TLS 버전을 그냥 두면 안 되는 이유

TLS에는 여러 버전이 있고, 세월을 거치며 발전해 왔습니다. 운영 원칙은 한 문장으로 끝납니다. 오래된 버전은 꺼 버리고, 충분히 현대적인 버전만 남겨라. 구체적으로는 TLS 1.2와 1.3만 허용하고 그 이전 버전(SSL 포함)은 전부 차단하는 것입니다.

약점은 이론이 아니라 실제 공격이다

초기 TLS와 그 전신인 SSL에서는 시간이 지나며 심각한 결함이 줄줄이 발견됐습니다. 이건 학술적인 흠집이 아니라, 실제로 통신을 복호화하거나 변조할 수 있는 공격으로 이어진 결함들입니다. 암호 기술의 숙명이 그렇습니다. 연구자들이 약점을 찾아내고, 하드웨어 연산력이 올라가고, 새로운 공격 기법이 등장하면서 — 한때 멀쩡했던 것이 어느새 뚫리게 됩니다.

그러니 낡은 버전을 계속 받아 준다는 건, 약점이 알려진 문을 일부러 열어 둔 채 사는 것과 같습니다. 여기서 한 가지 함정을 짚어야 합니다. "최신 버전도 지원하니까 괜찮지 않나?"라는 착각입니다. 최신과 구버전을 동시에 허용하면 오히려 위험합니다. 공격자가 협상 과정에 끼어들어 양쪽이 약한 버전으로 합의하도록 끌어내리는 수법, 즉 다운그레이드 공격이 가능해지기 때문이죠. 그래서 낡은 버전은 "쓰지 않는다"가 아니라 명시적으로 비활성화해야 합니다. 단순히 안 쓰는 것과 협상 목록에서 빼 버리는 것은 보안상 전혀 다른 상태입니다.

"닫을 수 있었는데 열려 있던 문"이라는 패턴

이 "패치도 대안도 있는데 옛 설정을 방치해서 당하는" 패턴은 비단 TLS만의 이야기가 아닙니다. 대표적인 사례가 Citrix Bleed(CVE-2023-4966)입니다. 고칠 방법이 분명히 있었음에도 적용하지 않은 조직들이 대규모로 침해당했죠. 2026년 현재까지도 공격자들이 가장 즐겨 노리는 건 화려한 0-day가 아니라, 이렇게 "닫을 수 있었는데 그냥 열려 있는 문"입니다. 낡은 TLS 버전을 끄지 않은 서버가 바로 그런 문 하나입니다.

호환성 핑계는 대부분 핑계다

"구버전을 끄면 옛날 클라이언트가 못 들어오지 않나요?"라는 걱정이 빠지지 않습니다. 결론부터 말하면, 현실에서는 거의 문제가 안 됩니다. 요즘 쓰이는 사실상 모든 브라우저와 클라이언트는 TLS 1.2 이상을 지원합니다. TLS 1.1 이하만 말할 줄 아는 클라이언트는 극단적으로 낡은 것이고, 그런 클라이언트를 받겠다고 전체 보안을 깎는 건 손해 보는 거래입니다. 게다가 그렇게 오래된 클라이언트라면 TLS 말고도 다른 구멍을 잔뜩 안고 있을 가능성이 높습니다. 대부분의 서비스는 TLS 1.2 이상만 열어 둬도 호환성 사고가 나지 않습니다.

암호 스위트: 무엇으로 잠글 것인가

버전을 정했으면 다음은 실제 암호화에 쓸 알고리즘 조합 — 암호 스위트(cipher suite) — 차례입니다.

하나의 TLS 연결은 여러 알고리즘이 손을 잡아 보호됩니다. 키를 교환하는 방식, 데이터를 암호화하는 방식, 무결성을 검증하는 방식 등이 한 묶음으로 결합된 것이 암호 스위트입니다. 연결을 맺을 때 서버와 클라이언트는 둘 다 지원하는 스위트 중 하나를 골라 씁니다. 그런데 버전과 마찬가지로, 알고리즘에도 강한 것과 약한 것이 섞여 있습니다. 약한 스위트를 허용해 두면 통신이 그 약한 방식으로 보호되어 그대로 노출됩니다.

설정 원칙은 두 가지로 압축됩니다.

• 약한 것을 배제한다. 알려진 약점이 있는 알고리즘, 더는 안전하지 않은 것으로 판명된 것들을 협상 목록에서 뺍니다. 낡은 암호화 방식, 허약한 키 교환, 취약한 해시가 여기 해당합니다.
• 강한 것을 우선한다. 안전한 스위트가 여럿이라면 더 강하고 효율적인 쪽이 먼저 선택되도록 순서를 잡습니다.

여기서 꼭 챙겨야 할 속성이 순방향 비밀성(Forward Secrecy)입니다. 이건 설령 서버의 개인 키가 미래에 유출되더라도, 과거에 오간 통신은 복호화할 수 없게 만드는 성질입니다. 공격자가 지금 암호화된 트래픽을 몰래 저장해 두었다가 나중에 키를 손에 넣어 한꺼번에 까 보는 시나리오 — 순방향 비밀성이 있으면 이게 막힙니다. 키 유출의 피해가 과거로 소급되지 않게 가두는 셈이죠. 침해를 항상 가정하는 보안 사고방식의 암호학적 적용이라 할 수 있습니다.

목록을 외우지 말고 생성기를 쓰라

여기서 아주 실용적인 조언 하나. 어떤 암호 스위트가 안전한지는 시간이 지나면 바뀝니다. 오늘의 권장 목록이 2~3년 뒤엔 갱신될 수 있다는 뜻이죠. 그래서 특정 목록을 머릿속이나 문서에 박제하는 것보다, 믿을 만한 출처가 주기적으로 갱신하는 최신 권장 설정을 그대로 가져다 쓰는 편이 훨씬 안전합니다.

다행히 주요 서버 소프트웨어용 안전한 TLS 설정을 자동으로 찍어 주는 도구가 있습니다. 바로 Mozilla SSL Configuration Generator입니다. 사용법은 단순합니다.

1. 서버 소프트웨어(Nginx, Apache 등)와 버전을 고른다.
2. 보안 수준 프로파일(Modern / Intermediate / Old)을 고른다.
3. 화면에 찍혀 나오는 설정 — 허용 TLS 버전과 암호 스위트 목록을 포함한 — 을 그대로 복사해 붙인다.

이렇게 생성된 설정을 쓰면 직접 스위트를 하나하나 나열하는 것보다 안전하고, 최신 상태로 유지하기도 쉽습니다. 그리고 이걸 정기적으로 다시 확인해 갱신하는 습관이, 보안을 "한 번의 작업"이 아니라 "이어지는 과정"으로 다루는 자세입니다.

어느 프로파일을 고를까? 대부분의 운영 환경에는 Intermediate(중간)가 정답입니다. 현대의 거의 모든 브라우저·클라이언트와 호환되면서도 충분히 안전하거든요. Old(구형)는 정말 오래된 클라이언트까지 받아야 하는 특수한 상황에서만 손대고, 평소 기본값으로 삼아선 안 됩니다 — Old를 고르는 순간, 방금 끄라고 그렇게 강조한 낡은 프로토콜이 슬그머니 다시 켜지니까요. 손으로 스위트를 나열하던 시절엔 오타 하나로 약한 스위트가 끼어드는 사고가 잦았는데, 생성기를 쓰기 시작한 뒤로는 그런 일이 사라졌습니다.

인증서: 신뢰의 토대

TLS의 세 가지 보장 중 "인증" — 접속한 상대가 진짜 그 서버가 맞는지 확인하는 일 — 은 인증서(certificate)에 기댑니다.

인증서는 "이 도메인은 진짜로 이 서버의 것"임을 신뢰할 수 있는 제3자, 즉 인증 기관(CA)이 보증해 주는 전자 문서입니다. 브라우저는 이 인증서를 검증해 접속한 서버가 사칭이 아닌지 가립니다. 인증서가 없거나 유효하지 않으면 브라우저는 큼지막한 경고를 띄우죠. 이 검증 절차가 없으면, 공격자가 중간에서 서버인 척 끼어들어 통신을 통째로 가로채는 중간자 공격(MITM)이 가능해집니다.

무료 인증서 + 자동 갱신이 표준이다

옛날엔 인증서 발급에 돈과 품이 들었지만, 지금은 Let's Encrypt 같은 무료 CA 덕분에 누구나 비용 없이 신뢰받는 인증서를 받을 수 있습니다. HTTPS가 이렇게 보편화된 결정적 이유 중 하나죠. 발급과 갱신을 자동화하는 표준 프로토콜인 ACME를 통해 전 과정을 기계가 처리하니, 사람이 끼어들 일이 거의 없습니다.

다만 이런 무료 인증서는 유효 기간이 짧은 편입니다. 이건 불편이 아니라 의도된 보안 설계입니다. 자주 갱신될수록 키가 유출돼도 그 영향이 미치는 기간이 짧아지니까요. 짧은 유효 기간의 유일한 단점인 "자주 갱신해야 하는 번거로움"은 자동화로 깔끔하게 해결합니다.

핵심 규칙을 한 번 더 강조합니다. 인증서 갱신은 반드시 자동화하세요. certbot 같은 ACME 지원 도구를 쓰면 발급과 갱신이 자동으로 굴러갑니다. 자동 갱신을 걸어 두면 사람이 신경 쓰지 않아도 만료 전에 알아서 새 인증서로 교체됩니다. 반대로 이걸 안 해 두면, 어느 날 갑자기 인증서가 만료되어 접속하는 모든 사용자에게 보안 경고가 뜨는 사고가 터집니다. 정말 흔한 운영 사고이고, 자동화 하나로 완전히 예방됩니다.

# certbot으로 인증서 발급 (Nginx 예시)
sudo certbot --nginx -d example.com -d www.example.com

# 자동 갱신 타이머가 잘 동작하는지 미리 점검 (대개 타이머가 자동 등록됨)
sudo certbot renew --dry-run

--dry-run을 빠뜨리지 마세요. "자동 갱신을 설정했다"는 것과 "자동 갱신이 실제로 작동한다"는 것은 다른 이야기이고, 이 한 줄이 그 차이를 메워 줍니다.

Cloudflare 같은 프록시를 쓴다면

CDN/프록시로 Cloudflare를 앞단에 두는 경우, 인증서 관리를 Cloudflare가 대신해 줘서 이 부분이 한결 단순해집니다. 단, 반드시 챙겨야 할 함정이 하나 있습니다. Cloudflare와 오리진(원본) 서버 사이 구간도 암호화되도록 설정해야 한다는 점입니다.

Cloudflare 대시보드의 SSL/TLS 암호화 모드를 꼭 Full (Strict)로 두세요. 이걸 Flexible로 두면 사용자Cloudflare 구간만 암호화되고, Cloudflare오리진 구간은 평문으로 오갑니다. 즉 보안 경고는 안 뜨는데 실제로는 절반이 벗겨진 상태가 되는 거죠. 뒤에서 다룰 "오리진 통신 미암호화" 함정에 그대로 빠지는 전형적인 사례입니다.

OCSP 스테이플링도 켜자

인증서 관련 추가 최적화로 OCSP 스테이플링(OCSP Stapling)이 있습니다. 인증서가 폐기되지 않았는지 확인하는 과정을 효율화하는 기술인데, 서버가 인증서의 유효성 증명을 미리 받아 두었다가 연결할 때 함께 건네주는 방식입니다. 덕분에 클라이언트가 별도로 폐기 여부를 조회하는 부담이 줄어 속도와 프라이버시가 동시에 개선됩니다. SSL Labs 평가에서도 긍정적으로 반영되는 항목이고, 대부분의 현대 서버 소프트웨어에서 한두 줄 설정으로 켤 수 있습니다.

SSL Labs로 검증하고 A+ 받기

이제 가장 실전적인 부분입니다. 지금까지의 설정이 정말 의도대로 안전한지 어떻게 확인하고, 어떻게 최고 등급을 받느냐는 거죠.

측정하지 않으면 그냥 희망일 뿐이다

보안의 한 가지 철칙은 "검증 없는 보안은 그저 희망"이라는 것입니다. TLS만큼 이 말이 잘 들어맞는 영역도 드뭅니다. 설정 파일에 무언가를 적어 넣었다고 해서 그게 의도대로 동작하는지는, 실제로 측정하기 전에는 아무도 모릅니다. 오타, 예상 못 한 기본값, 소프트웨어 버전 차이 — 이런 것들 때문에 의도와 현실이 어긋나는 일이 흔합니다.

다행히 TLS 설정을 정밀하게 측정해 주는 훌륭한 무료 도구가 있습니다. SSL Labs의 SSL Server Test입니다. 내 서버에 실제로 접속해서 TLS 설정의 구석구석을 점검하고, A+부터 F까지 등급을 매겨 줍니다. 게다가 등급만 던지는 게 아니라 무엇이 좋고 무엇이 문제인지를 항목별로 친절히 짚어 줍니다.

자기 서버 도메인을 입력하면 잠시 뒤 상세 보고서가 나옵니다. 본인 소유 자산에 대한 점검이므로 합법적이고, 정기적으로 돌릴 만한 가치가 있습니다. 한 가지만 기억하세요 — SSL Labs는 기본적으로 결과를 공개 게시판에 올립니다. 점검 전에 "Do not show the results on the boards" 항목을 체크해 두면, 우리 도메인의 평가 내역이 외부에 노출되지 않습니다.

등급은 무엇으로 갈리나

SSL Labs 등급은 여러 요소를 종합해 산출되는데, 핵심 항목들이 지금까지 다룬 내용과 정확히 일치합니다.

C 이하의 낮은 등급이나 경고가 나오면, 보고서가 원인을 콕 집어 줍니다. 거의 대부분 낡은 프로토콜이 켜져 있거나, 약한 스위트가 허용되어 있거나, 인증서 사슬에 구멍이 난 경우입니다. 보고서의 지적을 하나씩 닫으면 등급이 따라 올라갑니다.

A에서 A+로 — 마지막 한 걸음

기본 설정을 제대로 잡으면 보통 A 등급에 도달합니다. 여기서 A+로 한 단계 더 올라가려면 추가적인 강화가 필요한데, 그 핵심이 HSTS(HTTP Strict Transport Security)입니다.

HSTS는 브라우저에게 "이 사이트는 앞으로 무조건 HTTPS로만 접속해"라고 못 박는 보안 헤더입니다. 응답 헤더 한 줄로 시작할 수 있습니다.

# Nginx 예시 — HSTS 헤더 추가 (의미를 충분히 이해한 뒤 적용할 것)
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

이걸 올바르게 설정하면 SSL Labs에서 A+를 받을 수 있습니다. 다만 HSTS는 단순히 점수 올리는 장치가 아니라 그 자체로 중요한 방어 메커니즘이고, 잘못 설정하면 사이트가 한동안 접속 불가가 될 수도 있는 까다로운 면이 있습니다(예컨대 includeSubDomains나 preload를 충분히 검토하지 않고 긴 max-age로 박으면, 서브도메인 중 하나라도 HTTPS 준비가 안 됐을 때 사용자가 그 기간 내내 못 들어옵니다). 그래서 HSTS는 보안 헤더 전반과 함께 별도로 깊이 다룰 가치가 있는 주제입니다.

정리하면, A+로 가는 경로는 이렇습니다.

1. A 등급의 토대 만들기 — 낡은 프로토콜 차단 + 강한 암호 스위트 + 올바른 인증서 + OCSP 스테이플링.
2. A+로 완성하기 — HSTS를 올바르게 적용.

TLS 설정과 보안 헤더는 따로 노는 게 아니라 함께 맞물려 전송 계층 방어를 완성합니다.

A+는 받는 점수가 아니라 유지하는 상태다

한 번 A+를 받았다고 영원히 A+인 건 아닙니다. 시간이 지나면 한때 안전했던 설정이 약해질 수 있고(암호 알고리즘의 노화), 소프트웨어 업데이트로 설정이 슬쩍 바뀔 수도 있습니다. SSL Labs 테스트를 정기적으로 다시 돌려 등급이 유지되는지 확인하세요. 보안을 일회성 이벤트가 아니라 꾸준한 과정으로 다루는 자세입니다.

명령줄·자동화에는 다른 도구가 낫다

SSL Labs는 브라우저로 한 번 돌려 보기엔 더없이 좋지만, 두 가지 상황에선 불편합니다. (1) 내부망 서버처럼 외부에서 닿지 않는 대상, (2) 점검을 스크립트로 자동화하고 싶을 때. 이럴 땐 명령줄 도구가 제격입니다.

testssl.sh는 설치가 필요 없는 셸 스크립트 하나로 TLS 버전·암호 스위트·인증서·알려진 취약점을 한 방에 점검해 줍니다.

# testssl.sh — 한 줄 종합 점검 (반드시 본인이 운영하는 서버에만)
./testssl.sh https://example.com

sslyze는 파이썬 기반의 또 다른 점검 도구로, 결과를 JSON으로 뽑아 줘서 CI 파이프라인이나 정기 작업(cron)에 끼워 넣기 좋습니다. 운영 서버에 이런 점검을 주기 작업으로 걸어 두고, 등급이 떨어지면 알림이 오게 해 두면 — A+를 "유지하는" 체계가 완성됩니다.

자주 밟는 지뢰 6가지

TLS 설정에서 단골로 터지는 실수들을 모았습니다. 미리 알아 두면 같은 함정을 피할 수 있습니다.

• 낡은 버전을 안 껐다. 가장 흔합니다. 최신 버전을 추가하면서 구버전 끄는 걸 깜빡해, 둘 다 허용된 상태로 남깁니다. 다운그레이드 공격의 여지를 남기고 등급도 깎입니다.
• 인증서 사슬이 불완전하다. 인증서는 혼자 서지 못하고 중간 인증서로 이뤄진 신뢰 사슬을 동반합니다. 이 사슬이 끊겨 있으면 일부 클라이언트에서 인증서가 신뢰되지 않거나 경고가 뜹니다. 내 서버에선 멀쩡히 보여도 다른 환경에선 깨질 수 있으니, SSL Labs로 사슬의 완전성을 확인하세요.
• 자동 갱신 미설정으로 인한 만료. 갱신 자동화를 안 해 둬서 인증서가 만료되는 사고가 잦습니다. 갱신을 자동화하고, 그 자동화가 실제로 도는지 --dry-run으로 검증하세요.
• 설정만 하고 검증을 안 했다. 설정 파일을 고친 뒤 측정을 안 해서, 의도와 다른 결과가 그대로 방치됩니다. 항상 SSL Labs로 결과를 확인하세요.
• 오리진 통신을 암호화하지 않았다. Cloudflare 같은 프록시를 쓸 때 사용자프록시 구간만 암호화하고 프록시오리진 구간은 평문으로 두는 실수입니다. 그 구간이 통째로 노출됩니다. 종단 간 암호화(Cloudflare라면 Full (Strict))를 유지하세요.
• 혼합 콘텐츠(mixed content). HTTPS 페이지가 이미지·스크립트 같은 일부 자원을 HTTP로 불러오면, 그 부분이 암호화되지 않아 전체 보안이 약해지고 브라우저 경고가 뜹니다. 모든 자원이 HTTPS로 로드되게 하세요.

30초 요약

바쁜 분을 위해 핵심만 추립니다.

1. 암호화는 옵션이 아니라 기본값이다. 모든 웹 통신은 TLS로 암호화한다.
2. 켜는 것과 제대로 설정하는 것은 다르다. 자물쇠 아이콘 뒤에 약한 버전·약한 스위트가 숨어 있을 수 있다.
3. 낡은 버전은 명시적으로 비활성화한다. TLS 1.2 이상만 허용하고 이전은 전부 끈다. 다운그레이드 공격을 막으려면 "안 쓰는 것"으론 부족하다.
4. 암호 스위트는 강한 것만, 순방향 비밀성을 우선한다. 목록은 시간에 따라 변하니 Mozilla 생성기의 Intermediate 프로파일을 따르고 정기적으로 갱신한다.
5. 인증서는 자동 갱신한다. Let's Encrypt + ACME(certbot)로 비용과 만료 사고를 동시에 해결하고, OCSP 스테이플링도 켠다. --dry-run으로 검증.
6. 측정하지 않으면 모른다. SSL Labs로 A 등급의 토대를 만들고 HSTS로 A+를 완성한 뒤, 정기적으로 다시 측정한다. A+는 유지하는 상태다.

자주 묻는 질문 (FAQ)

Q. 자물쇠 아이콘이 떠 있으면 안전한 사이트 아닌가요? 자물쇠는 "TLS가 켜져 있다"는 표시일 뿐, "TLS가 안전하게 설정됐다"는 보증이 아닙니다. TLS 1.0 같은 낡은 버전이 열려 있거나 약한 암호 스위트가 허용되어 있어도 자물쇠는 똑같이 표시됩니다. 실제 안전 여부는 SSL Labs 같은 도구로 측정해 봐야 알 수 있습니다.

Q. TLS 1.0이나 1.1을 꺼도 정말 괜찮을까요? 옛날 사용자가 끊기지 않나요? 대부분의 경우 문제없습니다. 현재 쓰이는 사실상 모든 브라우저와 클라이언트가 TLS 1.2 이상을 지원합니다. TLS 1.1 이하만 지원하는 클라이언트는 극단적으로 오래된 것이고, 그런 클라이언트는 TLS 외에도 다른 보안 위험을 안고 있을 가능성이 큽니다. 소수의 구형 클라이언트를 위해 전체 보안을 깎는 건 손해 보는 거래입니다.

Q. 암호 스위트를 직접 골라야 하나요? 직접 나열하지 마세요. 안전한 스위트 목록은 시간에 따라 바뀌고, 손으로 적다 보면 오타로 약한 스위트가 끼어드는 사고가 납니다. Mozilla SSL Configuration Generator에서 서버 종류와 보안 프로파일(대개 Intermediate)을 고르면 최신 권장 설정을 그대로 복사해 쓸 수 있습니다. 그게 가장 안전하고 유지하기도 쉽습니다.

Q. Cloudflare를 쓰면 TLS는 알아서 되는 거 아닌가요? 사용자Cloudflare 구간은 Cloudflare가 처리해 주지만, Cloudflare오리진 서버 구간은 따로 챙겨야 합니다. SSL/TLS 암호화 모드를 반드시 Full (Strict)로 두세요. Flexible로 두면 오리진 구간이 평문으로 오가, 자물쇠는 떠 있는데 실제로는 절반이 벗겨진 상태가 됩니다.

Q. SSL Labs에서 A+를 한 번 받으면 끝인가요? 아닙니다. A+는 받는 점수가 아니라 유지하는 상태입니다. 시간이 지나면 한때 안전했던 암호 알고리즘이 약해지거나, 소프트웨어 업데이트로 설정이 바뀔 수 있습니다. SSL Labs를 정기적으로 다시 돌리거나, testssl.sh·sslyze를 정기 작업으로 걸어 두고 등급이 떨어지면 알림이 오게 해 두는 것을 권장합니다.

원문 출처 및 더 알아보기

이 글은 (주)뎁팀 웹 보안팀이 운영하는 보안 가이드 사이트 SGAEPS(시그앱스)의 가이드를 바탕으로 재구성했습니다. 더 깊은 원문은 SGAEPS 가이드 원문에서 확인하실 수 있습니다.

웹 보안 점검·긴급 대응이 필요하시면 DevTeam의 웹 긴급지원 또는 개발/보안 문의를 이용해 주세요.