HTTPS가 완전히 정착되지 않은 지금은 HTTPS를 사용하지 않는 사이트를 심심치 않게 발견할 수 있는데요. Chrome 업데이트로 HTTP 사이트에 '주의요함'이 표시되고 나서야 네이버 등의 대형 포털에서도 HTTPS를 일부에 적용했고, 서비스 전역에 적용하게 된 것은 그리 오래되지 않았습니다. 그만큼 아직 HTTPS로의 전환이 완전히 이루어지지 않는 상황입니다.
오늘의 문제는 여기서 생겼습니다. HTTPS가 적용된 사이트에서 HTTP로 요청을 전송하게 되면, 브라우저단에서 Block를 시킵니다. 즉, 이미 보안이 적용되어 있는데, 보안이 더 낮은 사이트로는 연결해줄 수 없다는 것이죠.
이게 브라우저 에러 메시지로 안 뜨고, 개발자 콘솔에 가야 보이는 것도 에러를 찾는데 좀 시간이 걸리게 만들었습니다. "This request has been blocked; the content must be served over HTTPS."라는 에러가 발생하고 있더라고요.
이는 에러 메시지 처럼 브라우저가 Request 보내는 것을 아예 막아버리는 것이기 때문에 HTTP 요청을 HTTPS로 리다이렉트 하도록 웹 서버가 설정되어 있어도 의미가 없습니다. 웹 서버에 요청이 와야 넘겨주던지 화면을 보여주던지 하는 것이기 때문에...
이번에는 조금 특수한 상황에 빠져서 경우에 따라 해결법을 정리해보고자 합니다.
Web App 개발자의 경우
제일 간단하게 해결할 방법
Web App 개발자의 경우에는 간단하게 요청을 보내는 주소를 HTTPS로 변경하면 됩니다.
좀 더 근본적인 해결 방법
만일, Web App을 Self-hosted로 설치 파일 등을 배포하여 고객들이 다른 서버에도 설치한다면, 요청을 "http://", "https://"로 시작하는 것이 아닌 "//" 으로 시작하면 됩니다. 그럼 자동으로 접속되었던 방식으로 선택되어 넘어갑니다.
예를 들어 현재는 아래와 같았다면...
<a herf="http://cocoblue.me/1234"></a>위 해결 방법을 적용하면 이렇게 변경하면 됩니다.
<a herf="//cocoblue.me/1234"></a>위와 같이하면, Web App을 SSL 없이 테스트 할 때도 자동적으로 http로 연결해주고, Prod 상황에서는 https로 연결해주기 때문에 유연성이 향상됩니다.
어쩔 수 없이 적용할 수 있는 방법
하지만, CORS 등 외부 컨텐츠를 보여줘야하는 경우에는 외부 사이트가 HTTPS를 지원하지 않는 경우를 생각할 수 있는데요. 이 경우에는 HTML의 Head 부분에 아래 내용을 추가해주면 됩니다.
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">HTTP 컨텐츠를 자동으로 업그레이드 해주는 정책을 활성화한다는 의미입니다.
Web App을 만들지 않은 서버 관리자의 경우
저는 이 경우였습니다. 제가 제작하지 않은 Web App이었기 때문에 요청 경로를 "//"로 수정할 수도 없었고, HTML의 Head 부분에 데이터를 추가할 수도 없었습니다.
하지만, HTML 태그의 의미를 힌트로 해결 방법을 찾을 수 있었습니다. meta 태그는 header에 데이터를 추가하는 것으로 "http-equiv"가 KEY, "content"가 value 입니다.
즉, 웹 서버에서 요청을 처리할 때 인터셉트해서 HEADER 데이터를 추가하면 되는 것이죠.
저 같은 경우에는 Nginx를 사용했기 때문에 Nginx의 Config로 소개해드립니다.
server {
listen 443 ssl;
server_name broadcast.cocoblue.me;
ssl_certificate /etc/letsencrypt/live/cocoblue.me/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/cocoblue.me/privkey.pem;
location / {
proxy_pass http://broadcast:8080;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# 추가 부분
add_header Content-Security-Policy "upgrade-insecure-requests";
}
}위와 같이 파일이 있다면, location에 Header 데이터를 추가해주면 됩니다.
수정 후에는 'nginx -t' 명령어로 Config 파일의 문법이 유효한지 체크 후 'nginx -s reload" 명령어로 다시 로드하면 됩니다.
에러 내용을 검색하면 인터넷에는 대부분 그냥 Web App 개발자 입장에서 HTTPS로 바꾸시라고만 되어 있고, 다양한 환경을 고려하지 않았습니다. 그래서 자동으로 치환하는 "//"을 소개해드렸습니다. 개발자 입장에서는 이렇게 하면 예외처리 할 일이 줄어들겠죠?
그리고, 개발자가 아닌 사람의 입장에서도 해결책을 적었습니다. 만일, 개발자인데, 실제 서비스 중인 경우에 긴급 땜질이 필요하다 싶으면 일단 웹 서버단에 적용을 하고, 차후 릴리즈에서 수정하면 되는 일이지요~
도움이 되셨으면 좋겠습니다. 감사합니다.
꿀팁 감사합니다!