VPN을 통한 첫 번째 요청으로 HTTPS를 만드는 방법

http://를 먼저 입력하고 리디렉션 후 https://에 도달하는 브라우저는 이미 하나의 요청을 일반 형식으로 보냈으며 VPN은 이를 변경하지 않습니다. 터널은 클라이언트에서 출구 노드까지의 다리를 보호합니다, 전송 계층 위의 어떤 것도 암호화하지 않으므로 출구와 원본 사이의 관찰자는 여전히 일반 텍스트 홉을 볼 수 있습니다. HTTPS를 첫 번째 요청으로 만드는 것은 실제 HTTPS 주소, 브라우저의 업그레이드 모드 및 사이트 자체 정책의 세 부분으로 구성된 클라이언트 측 변경입니다. 아래 단계는 제가 사용하는 순서이며, 각 단계에는 소요 여부를 알려주는 확인 표시가 있습니다.

1단계: 첫 번째 요청이 실제로 무엇인지 확인

변경하기 전에 브라우저가 보내는 내용을 살펴보세요. 콜드 캐시에서 다시 로드된 페이지로 네트워크 패널을 열고 첫 번째 행을 읽습니다, 구성표가 http이고 상태가 301 또는 308인 경우 해당 행 이후의 모든 것은 두 번째 요청입니다. curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' http://example.com은 브라우저 외부에서 동일한 시퀀스를 재현하고 최종적으로 도달한 URL을 인쇄합니다.

두 가지 결과가 가능하며 서로 다른 수정이 필요합니다. 사이트가 동일한 호스트에서 HTTPS를 제공하는 경우 수정 사항은 HTTP 양식 게시를 중지하는 것입니다, 즉, 북마크, Wiki 링크, 바탕 화면 바로 가기 및 사람들이 클릭하는 이메일 템플릿을 업데이트하는 것입니다. 사이트가 HTTPS를 전혀 제공하지 않으면 어떤 브라우저 설정도 생성하지 않으며 솔직한 대답은 대상이 문제라는 것입니다. 계정 페이지의 인증서 예외는 전송 문제를 자격 증명 문제로 변환하므로 예외가 있는 두 번째 사례를 덮어 두지 마십시오. 설정을 터치하기 전에 어떤 경우에 해당하는지 적어보세요.

2단계: 브라우저의 HTTPS 전용 모드 켜기

업그레이드 모드는 두 번째 부분으로, 모드는 호환되지 않습니다. 활성화하기 전에 자동으로 업그레이드하거나, 경고와 함께 업그레이드하거나, 로드를 거부하는 등 귀하의 기능이 무엇인지 확인하세요.

Firefox에서 제어 기능은 about:config 뒤에 있고 개인 정보 보호 설정 페이지에 있으며 dom.security.https_only_mode을 스위치로 사용하고 사이트별 예외는 자물쇠 메뉴에서 관리합니다. Chrome과 Edge에서는 항상 보안 연결 사용이라는 라벨이 붙은 설정, 개인 정보 보호 및 보안, 보안 아래에 동일한 아이디어가 있습니다. 레이블이 무엇이든 포트 80에서만 응답하는 호스트에 대해 동작을 확인하십시오, 업그레이드한 다음 자동으로 폴백하는 모드는 활성화했다고 생각하는 보호가 아니기 때문입니다. Firefox HTTPS 전용 문서에는 해당 브라우저의 업그레이드, 경고 및 예외 동작이 자세히 설명되어 있습니다.

3단계: 주소 표시줄뿐만 아니라 리소스 수정

업그레이드에 실패하면 주소 표시줄 대신 정확한 오류를 읽어보세요. HTTPS 리스너가 없는 호스트, 인증서와 일치하지 않는 호스트 이름 및 만료된 체인은 다른 메시지를 생성하고 다른 소유자에 속합니다. 첫 번째는 서버측 격차입니다, 두 번째는 일반적으로 업데이트되지 않은 북마크입니다, 세 번째는 VPN 연결과 무관한 갱신 문제입니다.

VPN이 켜져 있으므로 계정 사이트에 인증서 예외를 추가하지 마세요. 예외는 VPN이 방지해야 하는 가로채기를 정확하게 포착하는 검사를 비활성화합니다.

세 번째 부분은 페이지 내부에 있는데, 사람들이 그리워하는 부분입니다. HTTPS를 통해 로드되는 페이지는 여전히 http URL에서 이미지, 글꼴 또는 스크립트를 가져올 수 있으며, 브라우저는 이를 차단하거나 전체 페이지에 대한 보안 표시기를 다운그레이드합니다. 주소 표시줄이 모든 요청을 설명한다고 가정하는 대신 네트워크 패널에서 실패한 요청을 검사하고 소유자의 리소스 참조를 수정합니다. 실행하는 사이트에서 이는 브라우저에서 URL을 다시 작성하는 대신 CMS 또는 템플릿에 저장된 URL을 수정하는 것을 의미합니다. 소스를 변경할 수 없는 경우 혼합된 콘텐츠를 알려진 간격으로 기록하세요, 일반 텍스트 리소스를 가져오는 페이지 위에 있는 자물쇠는 잘못된 신호이기 때문입니다.

4단계: HSTS가 추가하는 것과 추가하지 않는 것

HSTS는 브라우저 기본 설정이 아닌 사이트 정책이며, 새로운 프로필에 입력된 http://를 유지하는 유일한 메커니즘입니다. 브라우저가 호스트에 대한 Strict-Transport-Security 헤더를 확인한 후에는 나중에 요청을 보내기 전에 https에 다시 작성합니다, 이는 정확히 원하는 속성입니다. 브라우저가 한 번도 방문한 적이 없는 호스트에 대해서는 아무 작업도 수행하지 않으며 동일한 애플리케이션을 제공하는 다른 호스트 이름에 대해서는 아무 작업도 수행하지 않습니다.

원본이 curl -sSI https://example.com | grep -i strict-transport-security으로 보내는 내용을 확인하세요. 누락된 헤더는 서버 변경이며 클라이언트가 설치할 수 있는 것이 아닙니다. 존재하는 경우 max-age을 읽고 includeSubDomains이 설정되어 있는지 확인하십시오, 방문 사이에 짧은 최대 수명이 만료되고 includeSubDomains가 누락되어 모든 하위 도메인이 보호되지 않기 때문입니다. RFC 6797은 사용자 에이전트가 정책을 적용하는 방법과 무시할 수 있는 사항을 정의합니다. 사전 로드는 별도의 약속이므로 다른 사람에게 도메인이 목록에 있다고 약속하기 전에 hstspreload.org API를 통해 상태를 확인하세요.

확인 및 롤백

클라이언트 설정에서는 롤백이 저렴하고 HSTS에서는 비용이 많이 듭니다. HTTPS 전용 모드를 끄면 이전 동작이 즉시 복원됩니다, 긴 최대 수명은 그렇지 않으며 이미 이를 받은 방문자는 만료될 때까지 계속 업그레이드됩니다.

따라서 완료라고 부르기 전에 순서대로 확인하세요. 콜드 캐시에서 다시 로드하고 네트워크 패널의 첫 번째 요청이 이전 리디렉션이 없는 https인지 확인합니다, 그런 다음 하위 도메인을 확인하십시오. 왜냐하면 includeSubDomains는 이러한 정책이 일반적으로 가정한 것보다 더 좁은 것으로 판명되기 때문입니다. 그런 다음 서드파티 자산을 가져오는 페이지 하나를 확인하세요, 혼합 콘텐츠는 다른 모든 수정 사항에도 살아남는 실패이기 때문입니다.

이 모든 후에도 첫 번째 요청이 여전히 http라면 클라이언트는 더 이상 변수가 아닙니다, 사람들이 클릭하는 링크는 변수입니다. 호스트 이름의 http 형식을 제어하는 위치를 검색하고 업데이트한 다음 동일한 콜드 캐시 다시 로드로 다시 테스트하세요. 터널은 요청을 볼 수 있는 사람을 변경하고 요청 암호화 여부는 절대 변경하지 않으므로 VPN 질문은 전체적으로 별도로 유지하세요. 티켓에 넣을 줄은 첫 번째 요청이 중요한 요청이고 리디렉션은 이미 전송된 요청에 대한 영수증일 뿐이라는 것입니다.