http를 https로 리디렉션하지 않고 https 전체 사이트 강제 실행


14

전체 사이트를 https로 만드는 방법을 연구하는 동안 많은 토론이있었습니다. 대부분의 답변은 http를 https (.htaccess 파일)로 리디렉션하는 것이 었습니다. 이는 동일한 작업을 두 번 (요청 2 회)하는 것이 좋지 않기 때문에 좋지 않습니다. 또한 "중간자"는 먼저 http를 사용하며 내 사이트가 https로 직접 이동하기를 원합니다. 전체 사이트를 https로 만드는 다른 방법이 있습니까? 예를 들어, example.com에 사용자가 입력하면 example.com은 http 또는 다른 것으로부터 먼저 리디렉션하지 않고 자동으로 https로 이동합니까?


사람들이 https로 리디렉션되는 것을 원하지 않으면 대신 어떻게 하시겠습니까?
Michael Hampton

@MichaelHampton 어쩌면 초보자 질문을하고 있지만 http를 실제로 "삭제"하고 싶습니다. 존재하는 유일한 것은 https입니다. 또는 이것이 가능하지 않은 경우 보안에 충분하다면 리디렉션을 사용할 수 있습니다. http-> https 리디렉션이 여전히 http이므로 리디렉션 중에 트래픽을 가로 챌 수 있기 때문에 리디렉션이 좋지 않다고 들었습니다.
Marko Tamburic

HTTP 301 영구 리디렉션은 친구입니다. 만료를 설정하는 것을 잊지 마십시오.
Marcel

http를 제거하면됩니다. 그러나 사용자가 https : //를 입력하지 않으면 연결 거부 메시지가 나타납니다. 일부 사이트의 경우 보안이 높기 때문에 더 좋습니다. 사용 가능한 http 버전이 있으면 첫 번째 요청이 암호화되지 않은 상태로 쿠키가 전송 될 수 있습니다. 회사 메일 시스템 https 만 + 사용자 교육은 괜찮습니다. 일반 사이트의 경우 많은 방문자가 손실 될 수 있습니다.
Josef는 Reinstate Monica

Afaik은 HTTP2로 가능해졌지만 여전히 SSL 스트라이핑 공격을 피하지는 않습니다 (아래 답변에 설명되어 있음).
peterh-Reinstate Monica

답변:



22

http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security를 통해 서버는 HTTPS를 통해서만 도메인에 액세스해야 함을 나타낼 수 있습니다. 이는 후속 요청에만 적용되므로 초기 HTTP로드가 있지만, 누군가 명시 적으로 HTTP를 입력하더라도 향후 요청은 HTTPS를로드합니다.

IE는 아직 지원하지 않지만 다른 모든 전공은 지원합니다.


여전히 첫 번째 요청으로부터 보호되지 않습니다.
Jenny D

3
@JennyD 나는 내 대답에서 이미 정확히 말했다.
ceejayoz

@JennyD "보호하다"는 무슨 뜻입니까? MiM은 로컬 DNS / 라우팅을 엉망으로 만들고 전체 도메인을 위조하지 않는 한 http-> https 리디렉션에 대해 아무것도 수행 할 수 없습니다. 이 경우 서버에 액세스하지 않으므로 실제로 수행하는 작업은 중요하지 않습니다.
적색 경보

2
@JennyD 글쎄, HSTS는 정말로 당신의 게시물보다 더 나은 솔루션입니다. 언제든지 리디렉션을 MITM 할 수 있습니다. HSTS를 통한 리디렉션은 사용자 + 브라우저 당 1 년에 한 번 (또는 만료 시간이 헤더에있을 때마다) MITM으로 만 가능합니다.
ceejayoz 2013

1
@MarkoTamburic 두 가지를 결합 할 수없는 이유는 없습니다.
ceejayoz

7

다른 사람들이 말했듯이 사용자가 올바른 프로토콜을 선택하도록 강요 할 수는 없습니다. 그러나 사용자가 HTTP를 사용하려고하면 어떻게해야합니까? 사용자와 클라이언트 사이에있는 공격자가 리디렉션을 가로 챌 수 있으므로 클라이언트는이를 보지 못하므로 리디렉션도 불충분합니다. 클라이언트는 계속 일반 HTTP를 전송하며 공격자는 서버에서 SSL 계층을 제거 합니다 ( SSL stripping attack ).

이를 막는 유일한 확실한 방법은 HTTP전혀 제공하지 않는 것 입니다. 포트 80에 대답하지 마십시오, HTTPS 다시 시도하도록 사용자에게 지시 일반 텍스트 페이지를 제공하기 위해 어쩌면 제외시켰다 (그러나 하지 공격자가 조작 할 수있는 링크를 제공한다). 그러면 사용자가 https://브라우저 에 입력 해야하므로 SSL 연결을 시작하고 MITM 공격을 막을 수 있습니다.


3
그러나 대부분의 사용자는을 입력하지 않기 때문에 트레이드 오프 https://입니다. 대신에 그들은 "아, 사이트가 망가졌다"고 말할 것입니다. 가장 좋은 시나리오는 www.example.comHTTP와 HTTPS 모두에 응답하지만 앱 자체는 HTTPS 만있는 것으로 실행되는 것일 수 admin.example.com있습니다.
ceejayoz

동의했다. 실제로, 거의 아무도 이것을하지 않습니다.
앤드류 Schulman

나는 그것이 더 이상 MiM 증거가되는 방법을 실제로 보지 못합니다. 중간에있는 사람이 다른 곳을 가리 키도록 하이퍼 링크를 수정할 수 있으면 사용자의 들어오는 패킷을 제어하고 있음을 의미합니다. 그는 사이트의 모양에 관계없이 자신의 사이트로 쉽게 리디렉션하거나 원하는 하이퍼 링크를 추가 할 수 있습니다.
적색 경보

그러나 이론적으로 클라이언트가 SSL과의 연결을 시작하는 경우는 아닙니다.
Andrew Schulman

3
사실이지만 클라이언트가 SSL로 시작하면 OP에 아무런 문제가 없습니다. 그의 문제는 SSL없이 시작했을 때이며, MiM이 적극적으로 방해하는 경우 SSL로 안정적으로 가져올 수있는 방법이 없습니다.
적색 경보


1

ceejayoz는 여기에 구체적으로 언급 된 공격을 방지하는 가장 좋은 대답을 가지고 있지만 기본적으로 HTTP에 다른 부분이 이미 파악되어 있다는 점에서 많은 사람들이 누락 된 부분을 지적하고 싶습니다. 영구적 인 301 리디렉션을 수행하려고합니다. 이것은 클라이언트에게 새로운 주소에 대한 추가 요청을하도록 지시합니다. 예, 누군가 잘못된 URL을 입력하면 두 번의 요청을하지만 앞으로 좋은 클라이언트는 해당 URL에 대한 요청을 감지하고 더 이상 요청을 낭비하지 않도록 올바른 요청을해야합니다. 문제는 이것이 정확한 URL에만 해당한다는 것입니다. HSTS는 또한 '다음 n 초 동안이 도메인으로부터 비보안 연결을 허용하지 않습니다'라고 말함으로써이 체계를 개선합니다.

안전하지 않은 위치의 민감한 사이트를 방문해서는 안됩니다. 특히 안전하지 않은 지역에서 가입해서는 안됩니다. 이들은 '신뢰할 수없는 출처의 첨부 파일을 열지 마십시오'와 같이 기본 사용자 보안 주체입니다. 방문한 적이없는 사이트에 대한 MiM 공격을 막는 가장 좋은 방법은 무엇입니까?

참고로, 일부 브라우저는 알려진 특정 사이트가 항상 HSTS를 사용한다고 말함으로써이를 개선합니다. 불행히도이 목록에 자신을 쉽게 추가 할 수는 없습니다.

추가 읽기 : http://coderrr.wordpress.com/2010/12/27/canonical-redirect-pitfalls-with-http-strict-transport-security-and-some-solutions/

http://dev.chromium.org/sts

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.