HTTPS 구성 감사

사이트의 응답 헤더를 붙여넣고 — 있다면 인증서, 페이지 소스 조각, 호스트 이름도 — 이 페이지가 HTTPS 쪽 구성을 보고합니다. HSTS가 설정되었는지와 얼마나, 콘텐츠 보안 정책이 안전하지 않은 요청을 승격하는지, 쿠키에 Secure와 SameSite가 표시되었는지, 서버 배너가 버전을 노출하는지, 그리고 프록시 헤더가 응용프로그램이 실제로 본 요청에 대해 무엇을 말하는지. 인증서는 같은 보고서에서 감사되고, 일반 http:// 서브리소스는 페이지 소스에서 세어지며, 핸드셰이크를 볼 수 있는 명령들이 직접 실행하도록 나열됩니다. 모든 것이 브라우저에서 실행되고 페이지는 자체 요청을 하지 않습니다.
1. 응답 헤더
상태 줄을 포함한 응답 헤더 블록 전체. 가장 쉬운 출처: 터미널의 curl -sI https://example.com/, 또는 브라우저 개발자 도구의 네트워크 탭 헤더 패널을 파일 위에서부터 복사. 여분의 헤더는 읽히고 무시되며, HTTPS 관련 것만 보고됩니다.
2. 인증서 또는 체인 (선택)
여기를 채우면 같은 보고서가 전체 인증서 감사도 실어 나르므로, 구성과 인증서를 함께 읽습니다. PEM, 순수 base64 또는 16진수 본문, PKCS#7 .p7b가 모두 됩니다. 인증서 검사기가 인증서만을 더 깊게 들어갑니다.
3. 페이지 소스 조각 (선택)
페이지 소스(URL이 있는 태그만이라도)를 붙여넣으면 모든 일반 http:// 주소가 나열됩니다. HTTP로 로드되는 서브리소스는 자물쇠를 깨뜨리고, 페이지 자체가 HTTPS로 도착했더라도 전송 중에 바뀔 수 있기 때문입니다. 사이트 자체 호스트로의 주소는 상대 URL이 고쳐줄 것들이므로 별도로 불려집니다.
4. 호스트 이름 (선택)
여기에 호스트 이름을 넣으면 감사가 브라우저처럼 주체 대체 이름을 검사합니다. 와일드카드 규칙을 포함하며 일반 http:// 주소를 그것과 대조합니다.
아직 감사된 것이 없습니다
샘플은 의도적으로 불완전하여, 보고서의 모든 부분에 내용이 있습니다. HSTS와 콘텐츠 보안 정책이 있는 헤더 블록(preload는 없고 쿠키 하나에 SameSite 없음), 두 인증서의 체인, 일반 http://로 스크립트를 로드하고 같은 방식으로 사이트 자체 호스트에 이미지를 가리키는 페이지 조각. 샘플에서 F를 예상하고, 아래 판정을 읽어 각각이 무엇을 의미하는지 보세요.
검사되는 것. 헤더 블록에서: HSTS와 그 max-age, includeSubDomains, preload. 안전하지 않은 요청을 승격하는 콘텐츠 보안 정책. 모든 Set-Cookie의 Secure, HttpOnly, SameSite 플래그. 제품과 버전을 이름 짓는 서버 배너. 응용프로그램이 요청을 HTTPS로 보았는지 말해 주는 포워딩 헤더. 인증서 블록에서: 체인의 각 링크가 실제로 다음 것에 서명했는지까지의 완전한 인증서 감사. 페이지 소스에서: 일반 http:// 서브리소스. 셋은 따로 보고된 뒤 함께 요약됩니다. 깨진 자물쇠는 보통 셋 중 하나이고 다른 둘이 아니기 때문입니다. 보안 응답 헤더의 전체 OWASP 목록 — X-Content-Type-Options, 프레임 보호, Referrer-Policy, Permissions-Policy, COOP, COEP, CORP와 등급 점수 — 에는 같은 헤더 블록을 보안 헤더 검사 페이지에 붙여넣으세요. 두 페이지는 TLS 계층과 헤더 계층으로 일을 나눕니다.

볼 수 없는 것. 이 페이지는 TLS 연결을 절대 열지 않습니다. 브라우저는 핸드셰이크를 페이지에 노출하지 않으므로, 프로토콜 버전, 암호 스위트, 키 교환 그룹, OCSP 스테이플링, 세션 재개, 0-RTT, 실행 중인 서버가 실제로 보내는 인증서 체인, HTTP에서 HTTPS로의 리디렉션이 원본에서 일어나는지 프록시에서 일어나는지는 모두 어느 웹 페이지도 보고할 수 있는 밖에 있습니다. 제3자 사이트에 접근해 헤더를 수집할 수도 없고, 인증서가 신뢰되는지도 말해 줄 수 없습니다. 페이지가 읽을 수 없는 루트 저장소에 달려 있기 때문입니다. 이 페이지 아래쪽의 명령들은 그것들을 볼 수 있으며, 당신이 직접 당신의 기계에서 실행하도록 의도되었습니다.

헤더 블록을 얻는 곳. 터미널에서는 curl -sI https://example.com/이 이 페이지가 원하는 것을 정확히 인쇄합니다. 브라우저에서는 개발자 도구를 열고 네트워크 탭으로 가고, 페이지를 다시 로드하고, 문서 요청을 선택하고 응답 헤더 영역 전체를 복사하거나, 복사 → 응답 헤더 복사를 쓰세요. 리디렉션 검사에는 curl -sI http://example.com/도 실행해 두 블록을 모두 붙여넣으세요. 페이지가 차례로 보고합니다.
감사 보고서
아직 감사된 것이 없습니다. 위에 헤더 블록을 붙여넣고 이 구성 감사를 누르면 전체 보고서가 나옵니다. 인증서, 페이지 소스 조각, 호스트 이름은 선택이며 각각 자기 섹션을 추가합니다.
도달 가능성 탐지 — 이 페이지에서 네트워크에 손을 대는 유일한 부분
페이지는 TLS 연결을 열 수 없지만 일반 요청을 시도할 수는 있습니다. 사이트가 교차 출처 읽기를 허용하면, 응답이 도착하는 URL이 http://가 https://로 리디렉션되었는지 보여 주며, 그것이 여기서 증명할 수 있는 전부입니다. 요청이 실패하면 이 페이지는 호스트가 죽었는지, 당신의 연결이 죽었는지, 사이트가 단순히 교차 출처 읽기를 허용하지 않는지 말해 줄 수 없습니다 — 마지막이 흔한 경우입니다. 대부분의 사이트는 Access-Control-Allow-Origin을 보내지 않기 때문입니다. http:// URL은 어떤 리디렉션보다 먼저 응답되므로, 이것이 브라우저가 평문 연결에서 시도할 유일한 것입니다. 버튼을 누르기 전까지는 아무것도 브라우저를 떠나지 않습니다.
핸드셰이크를 볼 수 있는 명령들
curl -sI https://example.com/ # the header block this page reads curl -sI http://example.com/ # is plain HTTP answered, or redirected? curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' http://example.com/ openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null 2>/dev/null \ | openssl x509 -noout -subject -issuer -dates -ext subjectAltName nmap --script ssl-enum-ciphers -p 443 example.com testssl.sh example.com # or: docker run --rm -ti drwetter/testssl.sh example.com
이 명령들은 당신이 통제하는 기계에서, 검사가 허용된 호스트에 대해 당신이 직접 실행하도록 남겨 둔 것입니다. -showcerts 출력은 인증서 검사기에 그대로 붙여넣을 수 있고, 응답 헤더 출력은 이 페이지로 다시 가져올 수 있습니다.
인증서는 공개 문서입니다. 공개적으로 신뢰되는 모든 인증서는 인증서 투명성(CT) 로그에 게시되므로, 인증서 안의 어떤 호스트 이름이든—공개 인증 기관이 서명한 내부 이름이나 오타가 난 이름까지 포함해—그 로그를 검색하면 찾을 수 있습니다. 인증서는 또한 발급자가 선택한 폐기 주소를 담고 있으며, 이런 주소에 내부 호스트 이름이 적히는 일도 드물지 않습니다. 이것이 CDN 서비스의 인증서가 원본 서버를 설명하지 못하는 이유입니다: 그 안의 이름은 CDN의 것입니다. 감사에서 예상하지 못한 호스트 이름이 나왔다면 그것을 공개된 것으로 간주하고, 그것이 보호하던 것을 교체하세요.

개인정보: 응답 헤더 블록, 인증서, 페이지 소스는 모두 로컬에서 읽고 절대 업로드하지 않으며, 도달 가능성 검사의 버튼을 누르지 않는 한 어떤 요청도 보내지 않습니다. 자체 인증서를 만들려면 자체 서명 인증서 생성기를, 개인 키가 어떤 인증서의 것인지 확인하려면 인증서·키 매처를 사용하세요.