사이트를 위험에 빠뜨리는 SSL/TLS 설정 오류

대부분의 방문자에게 HTTPS는 이분법입니다 — 자물쇠가 있거나 없거나. 그러나 공격자에게 TLS는 스펙트럼입니다. 인증서가 유효하고 신뢰되더라도 그 뒤의 설정이 다운그레이드 공격을 허용하거나 서브도메인 간에 유출되거나 다음 달 만료 시 조용히 깨질 수 있습니다. 이 글은 'HTTPS인가' 너머에서 스캔이 무엇을 보는지 다룹니다.

곧 만료되는 인증서

만료는 가장 흔하고 가장 피할 수 있는 TLS 사고입니다. 인증서 수명이 짧아지면서 수동 갱신은 더 이상 현실적이지 않습니다. 발급과 갱신을 자동화하고(ACME/Let's Encrypt 또는 플랫폼의 관리형 인증서), 만료일 당일이 아니라 충분히 이전에 경고하세요. 스캔은 남은 일수를 보여 주어 단명 인증서가 당신을 놀라게 하지 않도록 합니다.

불완전한 인증서 체인

리프 인증서는 보내지만 중간 인증서를 빠뜨리는 서버는 당신의 브라우저에서는 동작합니다 — 이미 중간 인증서를 캐시했기 때문입니다 — 그러나 다른 사람에게는 실패합니다. 전형적인 '내 환경에선 되는데' TLS 버그입니다. 항상 전체 체인을 제공하세요:

openssl s_client -connect example.com:443 -servername example.com -showcerts

출력에 인증서가 하나만 보이면 체인이 불완전한 것입니다.

아직 켜져 있는 약한 프로토콜과 암호

TLS 1.0과 1.1은 더 이상 권장되지 않으며 비활성화해야 합니다. 수출 등급과 RC4 암호도 마찬가지입니다. 최신 지침:

• TLS 1.2와 TLS 1.3만 지원하세요.
• 전방 비밀성을 가진 스위트(ECDHE)를 선호하세요.
• RC4, 3DES 및 EXPORT로 표시된 모든 것을 비활성화하세요.
• 폐기 확인을 빠르게 하도록 OCSP 스테이플링을 켜세요.

HTTPS 페이지의 혼합 콘텐츠

HTTPS 페이지가 http://로 스크립트, 스타일시트, 이미지를 불러오면 안전해야 할 페이지에 공격자의 발판을 줍니다 — 게다가 브라우저는 어차피 능동적 부분을 차단해 UI를 깨뜨립니다. 모든 절대 http:// 참조를 찾아 고치거나 브라우저가 업그레이드하게 하세요:

Content-Security-Policy: upgrade-insecure-requests

HTTP에서 HTTPS로의 리디렉션 없음

http://yoursite.com이 리디렉션 대신 콘텐츠를 제공하면 모든 첫 방문은 평문 요청입니다. 모든 HTTP를 301/308로 HTTPS로 리디렉션한 뒤 HSTS로 강제하여 브라우저가 다시는 HTTP를 시도하지 않게 하세요(보안 헤더 가이드의 실수 #1 참조).

너무 넓게 쓴 와일드카드 인증서

관련 없는 여러 서비스에 *.example.com 인증서 하나를 쓰면 유출된 개인 키 하나가 그 모두를 위태롭게 합니다. 편리하지만 피해 범위를 넓힙니다. 인증서의 범위를 실제로 공유가 필요한 서비스로 한정하세요.

한 번이 아니라 지속적으로 확인하세요

TLS 설정은 흘러갑니다: 새 서브도메인, 로드 밸런서 교체, 잊어버린 갱신. 헤더에 쓰는 것과 같은 주기에 TLS 검사를 넣으세요 — 웹사이트 보안 스캔 보고서 읽는 법이 이 발견 항목들을 주간 계획으로 바꾸는 법을 다루고, 가격 페이지가 정기 예약에 필요한 스캔 한도를 보여 줍니다.