HTTPS가 광범위적으로 적용됨에 따라 Google Chrome은 HTTP를 통한 '안전하지 않은' 다운로드를 차단하는 기능을 준비중입니다.
예전에는 은행과 같이 개인 정보에 민감한 웹사이트만 HTTPS 암호화로 보호해야 했지만 요즘에는 특히 더 많은 웹사이트에서 데이터를 처리함에 따라 HTTPS 암호화가 사실상 기본값이 되었습니다.
지난 몇 년 동안 Google은 Chrome에 새로운 보호 기능을 추가하여 가능할 때마다 HTTPS 연결 사용을 권장했습니다.
특히 브라우저는 주소 표시줄에서 이전 HTTP 웹사이트를 "안전하지 않음"으로 표시합니다. 또한 Chrome은 기본적으로 보안 웹사이트에서 안전하지 않은 웹 양식 을 사용 하거나 안전하지 않은 다운로드 를 제공하지 못하도록 차단 합니다.
이러한 보안 및 비보안 요소의 조합을 "혼합 콘텐츠"라고 합니다.
더 나아가 최근 Google은 Chrome의 보안 설정에서 "항상 보안 연결 사용" 으로 전환하는 토글을 만들었습니다. 이 기능을 사용하면 실수로 안전하지 않은 버전으로 이동하는 경우 Chrome이 웹사이트의 HTTPS 버전으로 '업그레이드'를 시도합니다. 만약 HTTPS 버전을 사용할 수 없는 경우 계속할 것인지 묻는 화면 경고가 표시됩니다.
하지만 이젠 아예 HTTP 자체를 차단하는 것을 준비중입니다.
Block insecure downloads
Enables insecure download blocking. This shows a ‘blocked’ message if the user attempts to download a file over an insecure transport (e.g. HTTP) either directly or via an insecure redirect.
#block-insecure-downloads
이 기능은 이제 막 개발되고 있기 때문에 2023년 3월에 출시될 예정인 Chrome 111까지 광범위한 테스트를 위해 출시되지 않을 가능성이 높습니다.
https://9to5google.com/2022/12/28/chrome-block-insecure-http-downloads/
단순하게 일방적인 정보게시만 하는 웹페이지들을 위해서 html 접속도 남겨뒀으면 좋겠는데 ...
다만... https RSA 핑퐁 이후 cipher로 인한 웹서버 오버헤드는 어마무시할거 같네요...
해당 오버헤드를 줄이자고..
일단 제가 개인적으로 돌리는 서버가 apache2인지라 HTTP/3는 아직 적용 못했네요 ㅠ
저도 자세한 원리를 수박겉핥기로만 알고 있지만...quic으로하더라도 암호키로 암호화해서 보내는 payload 데이터 교환은 웹서버 부하로 작용할거 같습니다.
사실 이게 DNS 위변조가 된다는 가정하에 그에 따른 보안 사고를 막기 위해 꼭 필요한 과정인건 맞긴합니다.