본문 바로가기
MAKESITE
무료 스캔 문의하기 로그인

점검 항목 · 보안

HTTPS 미적용 · http 접속 허용

인증서를 달았는데도 이 항목에 걸리는 경우가 대부분입니다. 문제는 https 가 없는 것이 아니라 http 가 아직 살아 있는 것입니다.

심각도 치명 보안 무료 스캔 판정 항목 /check/https-force

01DEFINITION

한 줄로 말하면

주소창에 http:// 로 들어가도 사이트가 그대로 열린다면, 그 요청은 암호화되지 않은 채 공유기와 통신사 장비를 지나갑니다. 로그인 폼 하나만 있어도 아이디와 비밀번호가 평문으로 흘러갑니다. 인증서를 달아 두고 http 를 https 로 넘기는 설정만 빠뜨린 경우가 의외로 많은데, 이러면 인증서 값은 다 내고 효과는 절반입니다.

02RISK

없으면 무슨 일이 생기나

공용 와이파이에 붙어 있는 방문자를 떠올리시면 됩니다. 같은 공유기에 있는 누군가가 오가는 요청을 그대로 볼 수 있고, 그 요청이 http 라면 로그인 폼에 친 아이디와 비밀번호가 글자 그대로 지나갑니다. 게시판 관리자 계정으로 로그인하는 순간이 특히 위험한데, 하필 그 계정이 사이트 전체를 고칠 수 있는 계정이기 때문입니다.

보는 것에서 끝나지 않습니다. 중간에서 응답을 바꿔치기하면 방문자 브라우저에 원래 없던 스크립트를 끼워 넣을 수 있습니다. 통신사 장비가 광고를 삽입하던 사례가 실제로 있었고, 그게 가능했던 이유가 바로 http 였습니다. 우리 서버는 아무 잘못이 없는데 방문자 화면에는 우리 사이트 주소로 이상한 것이 뜹니다.

검색 쪽 손해도 같이 옵니다. 같은 페이지가 http 와 https 두 주소로 열리면 검색엔진에게는 서로 다른 페이지 둘입니다. 평가가 반으로 갈리고, 크롬은 http 페이지 주소창에 주의 표시를 띄웁니다. 방문자가 그것을 보고 돌아가는 비율은 생각보다 높습니다.

03CHECK IT YOURSELF

직접 확인하는 방법

아래는 저희를 거치지 않고 지금 해 보실 수 있는 방법입니다. 결과를 저희에게 보내실 필요도 없습니다.

  1. 01
    주소창에 http:// 를 직접 쳐 본다

    브라우저는 주소를 칠 때 https 를 먼저 시도하므로, 앞에 http:// 를 붙여 명시적으로 요청해야 합니다. 주소창이 https 로 바뀌면 통과입니다. http 인 채로 페이지가 그려지면 이 항목에 걸립니다.

  2. 02
    응답 코드를 직접 본다

    터미널에서 http 로 요청해 첫 응답만 확인합니다. 301 이나 308 과 함께 Location 이 https 주소를 가리키면 정상입니다. 200 이 돌아오면 그 페이지는 암호화 없이 그대로 나가고 있는 것입니다.

    $ curl -sI http://example.com/ | head -n 3
    HTTP/1.1 301 Moved Permanently
    Location: https://example.com/
  3. 03
    홈만 보지 말고 안쪽 주소도 본다

    홈에만 리다이렉트를 걸어 두고 하위 경로는 빠뜨린 설정이 흔합니다. 로그인 페이지, 관리자 주소, 이미지 경로를 각각 http 로 요청해 보십시오. 로그인 페이지 하나만 http 로 열려도 이 항목의 위험은 그대로입니다.

    $ curl -sI http://example.com/bbs/login.php | head -n 2

04HOW TO FIX

고치는 방법

서버 환경에 따라 적을 자리가 다릅니다. 아래는 가장 흔한 구성 기준이고, 적용 전에 현재 설정을 백업하십시오.

Apache — .htaccess 에 리다이렉트를 건다

문서 루트의 .htaccess 맨 위, 다른 재작성 규칙보다 앞에 둡니다. 뒤에 두면 앞선 규칙이 [L] 로 끝내 버려 리다이렉트까지 오지 않습니다.

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
로드밸런서나 CDN 뒤에 있다면 헤더를 본다

앞단에서 https 를 끊고 뒤로는 http 로 보내는 구성에서는 위 조건이 항상 참이 되어 무한 리다이렉트가 납니다. 이때는 앞단이 붙여 주는 X-Forwarded-Proto 를 기준으로 판정합니다.

RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
nginx — 80 포트 서버 블록을 리다이렉트 전용으로 둔다

80 에서 콘텐츠를 서빙하지 말고 통째로 넘깁니다. 이 방식이 경로별로 빠뜨릴 여지를 없애 줍니다.

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}
내부 링크와 이미지 주소도 https 로 바꾼다

https 페이지 안에서 http 리소스를 부르면 브라우저가 그것을 차단하거나 경고를 띄웁니다. 게시판 본문에 절대주소로 박힌 이미지 링크가 대표적인 원인이며, 데이터베이스에서 한 번 치환해야 하는 경우가 많습니다.

주의. 301 은 브라우저가 오래 기억하는 영구 리다이렉트입니다. 설정이 확실해지기 전까지는 302 로 두고 전 경로를 확인한 뒤 301 로 바꾸는 편이 안전합니다. 잘못된 301 을 되돌리려면 방문자 브라우저의 캐시가 만료되기를 기다려야 합니다.

05FAQ

자주 묻는 질문

인증서를 이미 발급받았는데 왜 이 항목에 걸리나요

인증서 발급과 http 차단은 별개의 작업이기 때문입니다. 인증서는 443 포트에서 암호화된 연결을 받을 수 있게 해 주지만, 80 포트는 그대로 살아 있습니다. 리다이렉트를 걸지 않으면 두 문이 다 열려 있는 상태이고, 방문자가 어느 문으로 들어오는지는 우리가 정하지 못합니다.

무료 인증서를 써도 이 항목은 통과하나요

통과합니다. 이 항목이 보는 것은 인증서의 가격이나 발급기관이 아니라 http 요청이 https 로 넘어가는지 하나뿐입니다. 무료 인증서와 유료 인증서는 암호화 강도가 같고, 차이는 보증 범위와 기업 실재 확인 절차에 있습니다.

리다이렉트를 걸었더니 페이지가 무한히 새로고침됩니다

앞단에 로드밸런서나 CDN 이 있는 구성에서 거의 항상 이 증상이 납니다. 앞단이 https 를 처리하고 뒤로는 http 로 전달하기 때문에 웹서버 입장에서는 매번 암호화되지 않은 요청으로 보입니다. X-Forwarded-Proto 헤더를 조건으로 쓰면 해결됩니다.

http 를 아예 막아 버리면 안 되나요

권하지 않습니다. 80 포트를 닫으면 http 로 들어온 방문자는 리다이렉트 대신 연결 실패를 보게 되고, 검색엔진이 갖고 있던 옛 http 주소도 갈 곳을 잃습니다. 닫는 것이 아니라 넘기는 것이 맞습니다.
여기까지는 항목 일반론입니다. 무엇이고 왜 문제이며 어떻게 고치는지는 감출 이유가 없어 그대로 적었습니다. 리포트에 들어가는 것은 귀사 사이트에서 실제로 어떤 값이 나왔는지 — 어느 주소의 어느 응답인지, 그 환경에서 어떤 순서로 적용해야 하는지, 예상 공수가 얼마인지입니다. 이 페이지만 보고 직접 고치셔도 되고, 실제로 그러시라고 적어 두었습니다.

GET STARTED

내 사이트는
이 항목을 통과할까요

주소만 넣으시면 이 항목을 포함해 25가지를 판정해 점수와 실패 개수를 보여 드립니다. 로그인도, 소유 확인도 필요 없습니다 — 전부 밖에서 관찰만 하는 항목이기 때문입니다.