http를 https로 리디렉션하는 것이 좋지 않습니까?

방금 서버에 SSL 인증서를 설치했습니다.

그런 다음 포트 80에서 도메인의 모든 트래픽에 대한 리디렉션을 설정하여 포트 443으로 리디렉션합니다.

즉, 모든 http://example.com트래픽이 이제 해당 https://example.com버전의 페이지로 리디렉션됩니다 .

리디렉션은 다음과 같이 Apache Virtual Hosts 파일에서 수행됩니다.

RewriteEngine on
ReWriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R,L] 

내 질문은 SSL을 사용하는 데 단점이 있습니까?

이것은 301 리디렉션이 아니므로 https? 로 전환하면 검색 엔진에서 링크 주스 / 순위가 사라집니다 .

도움을 주셔서 감사합니다. 나는 항상 서버에서 SSL을 설정하고 싶었고, 오늘 밤에 그것을하기로 결정했습니다. 지금까지는 잘 작동하는 것 같지만 모든 페이지에서 이것을 사용하는 것이 좋은지 확실하지 않습니다. 내 사이트는 전자 상거래가 아니며 민감한 데이터를 처리하지 않습니다. 그것은 주로 외모와 학습을 위해 그것을 설치하는 스릴을위한 것입니다.

업데이트 된 문제

Strangely Bing은 이제 모든 곳에서 HTTPS를 사용하고 있으므로 내 사이트에서이 스크린 샷을 만듭니다 ...

[R]자체에 플래그가입니다 302리디렉션 ( Moved Temporarily). 사람들이 사이트의 HTTPS 버전을 사용하도록하려면 (힌트 : 사용) [R=301]영구적 인 리디렉션 을 사용해야합니다 .

RewriteEngine on
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R=301,L] 

A는 301당신이 구글-FU와 힘들게 번 pageranks 모두 유지 그대로 . mod_rewrite활성화되어 있는지 확인하십시오 .

a2enmod rewrite

정확한 질문에 대답하려면 :

http를 https로 리디렉션하는 것이 좋지 않습니까?

지옥 아니 아주 좋습니다.

SSL 전용 사이트라는 아이디어를 지원하지만 사이트 디자인에 따라 한 가지 단점이 오버 헤드라고 말합니다. 예를 들어 img 태그로 많은 개별 이미지를 제공하는 경우 사이트가 훨씬 느려질 수 있습니다. SSL 전용 서버를 사용하는 모든 사람에게 다음 작업을 수행하도록 권장합니다.

1. 내부 링크가 있는지 전체 사이트를 확인하고 링크에 고유 한 도메인 이름을 지정한 경우 모두 HTTPS를 사용하고 있는지 확인하십시오. 따라서 고유 한 리디렉션이 발생하지 않습니다.
2. <meta property="og:url"https 버전의 도메인을 사용하도록 업데이트하십시오 .
3. 당신이 사용하는 경우 <base href=다시 HTTPS를 사용하도록 업데이트합니다.
4. 가능하면 SPDY 프로토콜 설치
5. 요청 수를 줄이기 위해 가능하면 CSS 이미지 스프라이트를 사용하십시오.
6. https가 표시되도록 사이트 맵을 업데이트하여 시간이 지남에 따라 스파이더가이 변경 사항을 학습하십시오.
7. HTTPS를 선호하도록 Google 웹 마스터 도구와 같은 검색 엔진 환경 설정 변경
8. 가능한 경우, 모든 stactic 미디어를 HTTPS CDN 서버로 오프로드하십시오.

위의 사항을 해결하면 많은 문제가 발생할 것입니다.

https를 설정하면 사이트의 모든 곳에서 사용해야합니다. 혼합 컨텐츠 문제의 위험을 피하고 필요한 도구가 준비되어 있으면 전체 사이트를 안전하게 보호해야하는 이유는 무엇입니까?

http에서 https 로의 리디렉션과 관련하여 대답은 간단하지 않습니다.

리디렉션은 사용자가 훨씬 쉽게 사용할 수 있도록 할뿐입니다. 단지 whateversite.com을 입력하면 https로 리디렉션됩니다.

그러나. 사용자가 때때로 안전하지 않은 네트워크에 있거나 Troy Hunt와 Pineapple에 가까운 경우 어떻게해야 합니까? 그런 다음 사용자는 http://whateversite.com 을 오래된 습관으로 요청 합니다. http입니다. 타협 될 수 있습니다. 리디렉션은 https://whateversite.com.some.infrastructure.long.strange.url.hacker.org를 가리킬 수 있습니다 . 일반 사용자에게는 꽤 합법적입니다. 그러나 트래픽을 가로 챌 수 있습니다.

따라서 여기에는 두 가지 경쟁 요구 사항이 있습니다. 사용자 친화적이고 안전해야합니다. 다행히도 HSTS 헤더 라는 해결책이 있습니다. 그것으로 당신은 리디렉션을 활성화 할 수 있습니다. 브라우저는 보안 사이트로 이동하지만 HSTS 헤더 덕분에이를 기억하십시오. 사용자가 해당 비보안 네트워크에 앉아 whateversite.com을 입력하면 브라우저는 http를 통한 리디렉션을 거치지 않고 즉시 https로 이동합니다. 매우 민감한 데이터를 다루지 않는 한 대부분의 사이트에서 보안과 유용성간에 공정한 균형을 유지한다고 생각합니다. (최근에 의료 기록을 처리하는 응용 프로그램을 설정할 때 리디렉션없이 모두 https로갔습니다). 불행히도 Internet Explorer는 HSTS를 지원하지 않습니다 ( 소스), 타겟 고객이 주로 IE를 사용하고 있고 데이터가 민감한 경우 리디렉션을 사용 중지 할 수 있습니다.

따라서 IE 사용자를 타겟팅하지 않는 경우 리디렉션을 사용하고 HSTS 헤더도 활성화하십시오.

이이 아무 문제가 없다, 사실은 (사이트에 대한 가장 좋은 방법입니다 해야 보안 연결을 통해 제공 될이). 실제로, 당신이하고있는 일은 내가 사용하는 구성과 매우 유사합니다.

<VirtualHost 10.2.3.40:80>
  ServerAdmin me@example.com
  ServerName secure.example.com
  RedirectMatch 301 (.*) https://secure.example.com$1
</VirtualHost>

# Insert 10.2.3.40:443 virtual host here :)

301상태 코드는 표시 영구 (예 : 북마크를 업데이트) 미래의 연결에 대한 보안 URL을 사용할 수있는 클라이언트를 지시, 리디렉션.

TLS / SSL을 통해서만 사이트를 제공하는 경우 보안 가상 호스트 에서 HSTS ( HTTP Strict Transport Security) 를 활성화하기위한 추가 지침을 권장 합니다.

<IfModule mod_headers.c>
  Header set Strict-Transport-Security "max-age=1234; includeSubdomains"
</IfModule>

이 헤더는 유능한 클라이언트에게 (현재 대부분의 경우) 제공된 도메인 ( 이 경우) 과 함께 HTTPS 를 secure.example.com다음 1234초 동안 만 사용해야 한다고 지시합니다 . 이 ; includeSubdomains부분은 선택 사항 이며 지시문이 현재 도메인뿐만 아니라 그 아래 도메인에도 적용됨을 나타냅니다 alpha.secure.example.com. HSTS 헤더는 SSL / TLS 연결을 통해 제공 될 때 브라우저 에서만 허용됩니다!

현행 베스트 프랙티스에 대해 서버 구성을 테스트하려면 Qualys의 SSL 서버 테스트 서비스를 무료로 사용하십시오. 나는 적어도 A-를 득점하는 것을 목표로하고 있습니다 (타원 곡선 암호화에 대한 지원이 없기 때문에 Apache 2.2보다 더 많은 것을 얻을 수는 없습니다).

와 ! HTTP를 HTTPS로 리디렉션하는 것은 매우 좋은 일이며 단점이 없습니다.

브라우저의 인증서에 대한 사용자에게 친숙하지 않은 경고를 피하기 위해 클라이언트에 올바른 CA가 있는지 확인하십시오.

또한 HTTPS로 리디렉션하도록 Apache를 설정 한 방식은 괜찮습니다.

http를 https로 리디렉션하는 것이 좋지 않습니까?

아뇨, 전혀 아닙니다. 실제로, 좋은 일입니다!

리디렉션시 :

다시 쓰기 를 완전히 제거하여 더 효율적일 수 있습니다 . 비슷한 상황에 대한 구성은 다음과 같습니다.

<VirtualHost *:80>
  ServerName domainname.com

  <IfModule mod_alias.c>
    Redirect permanent / https://domainname.com/
  </IfModule>
</VirtualHost>

HTTPS는 완전하지 않습니다. 물론, 일반적으로 HTTPS를 강제하는 것이 좋습니다. 일반 범죄자가 사용자에게 나쁜 일을하는 것을 방지합니다.

그러나 SSLCiphers 설정과 같은 SSL 설정을 확인하십시오. RC4 암호화, SSLv2 및 SSLv3 프로토콜과 같은 기능을 비활성화하십시오. 또한 시스템의 암호화 시스템 라이브러리가 TLS1.2를 지원하는지 여부를 확인해야합니다.

SSL을 켜십시오.

개인적으로 나는 웹에서 연결을 보호하기 위해 SSL을 사용하고 있지만 HTTP 연결이 가능한 모든 장치와 소프트웨어가 SSL을 사용할 수있는 것은 아닙니다. 따라서 사용자가 지원하지 않는 경우 사용자가 피할 수있는 방법을 제공하는 것이 좋습니다. 암호화 기술이 불법 인 일부 국가의 사람들은 귀하의 사이트에 액세스하지 못하게 될 수도 있습니다. 사이트의 안전하지 않은 버전을 강제로 링크하기 위해 링크가없는 암호화되지 않은 방문 페이지를 추가하는 것이 좋습니다. 그러나 사용자가 귀하가 말한대로 구체적으로 선택하지 않은 경우 HTTPS 버전으로 전달하십시오.

광범위한 브러시 스트로크 문제는 다음과 같습니다.

• MITM / SSLSTRIP : 이것은 큰 경고입니다. HTTPS를 통해 사이트를 제공 하려면 사이트에서 HTTP를 비활성화하십시오 . 그렇지 않으면 SSLSTRIP를 포함한 다양한 중간자 (man-in-the-middle) 공격에 사용자를 개방하여 요청을 가로 채고 HTTP를 통해 자동으로 서비스를 제공하여 자체 악성 코드 스크립트를 스트림에 삽입합니다. 사용자가 알지 못하면 실제로 세션이 안전하지 않을 때 세션이 안전 하다고 생각 합니다.

  • 그러나 이것의 문제는 사이트가 공개 사이트이고 실수로 HTTP를 비활성화하면 많은 방문자를 잃을 수 있다는 것입니다. 사이트가 HTTP로로드되지 않으면 HTTPS를 시도하는 것도 아마 일어나지 않을 것입니다 .

• 사이트에 보안 로그인이 필요한 경우 전체 사용자 세션을 보호해야합니다. HTTPS를 통해 인증하지 말고 사용자를 다시 HTTP로 리디렉션하십시오. 다시 말하면 사용자가 MITM 공격에 취약 해집니다. 요즘 인증에 대한 표준 접근 방식은 한 번 인증 한 다음 인증 토큰을 쿠키로주고받는 것입니다. 그러나 HTTPS를 통해 인증 한 다음 HTTP로 리디렉션하면 중간자 (man-in-the-middle)가 해당 쿠키를 가로 채서 보안을 우회하여 마치 인증 된 사용자 인 것처럼 사이트를 사용할 수 있습니다.

• HTTPS의 "성능"문제는 모든 실제적인 목적으로 새 연결 작성과 관련된 핸드 셰이크로 제한됩니다. URL에서 여러 HTTPS 연결의 필요성을 최소화하기 위해 할 수있는 일을하십시오. HTTP를 통해 콘텐츠를 제공하는 경우에도 마찬가지입니다. SPDY를 읽으면 모든 작업이 단일 연결을 통해 단일 URL의 모든 콘텐츠를 제공하려고한다는 것을 알 수 있습니다. 예. HTTPS 사용은 캐싱에 영향을줍니다. 그러나 요즘에는 정적이며 캐시 가능한 콘텐츠 인 웹 사이트는 몇 개입니까? 변경되지 않은 데이터를 반복해서 검색하는 중복 데이터베이스 쿼리를 최소화하고 값 비싼 코드 경로가 필요 이상으로 자주 실행되는 것을 방지하기 위해 웹 서버에서 캐싱을 사용하여 비용을 절감 할 수 있습니다.

이것은 원래 질문에 대한 대답은 아니지만, Chrome 확장 프로그램 HTTPSEverywhere를 사용하는 경우 (다른 브라우저에서도 비슷한 확장 프로그램이 있다고 확신합니다) 확장 프로그램은 HTTP가있는 사이트를 HTTPS가있는 동일한 사이트로 자동 리디렉션합니다. 나는 그것을 잠시 동안 사용 해 왔으며 아무런 문제가 없었습니다 (느린 속도를 제외하고는 테스트하지 않았습니다). HTTPSEverywhere는 서버 측의 특정 규칙에 따라 변경 될 수 있지만 해당 영역에서 많은 작업을 수행하지 않았으므로 정확한 세부 정보가 확실하지 않습니다.

실제 질문으로 돌아가서 HTTPSEverywhere와 같은 것을 사용하면 HTTP 전용을 사용하는 인센티브가 적습니다. 필요할 때 올바른 규칙을 설정하는 것이 어렵다고 생각합니다.

HTTP를 통한 HTTPS의 유일한 기술적 단점은 일반 HTTP보다 HTTPS 요청을 처리하는 데 계산 비용이 많이 든다는 것입니다

그러나 대부분의 최신 서버는 고성능 CPU를 가지고 있기 때문에로드 밸런서를 사용하고있을 가능성이 매우 높은 트래픽 수준에 있지 않으면 이러한 영향은 무시할 수 있습니다.

SSL / TLS가 작동해야하는 SPDY와 같은 프로토콜의 출현으로, 이는 실제로 여러 요청과 관련하여 상당한 성능 향상을 제공하고 자산을 클라이언트에 더 빠르게 전체적으로 제공함으로써 위에서 언급 한 계산 오버 헤드를 방지합니다.

https로 리디렉션하는 것이 좋지만 리디렉션을 구성하는 방법에 따라 다릅니다.

security.stackexchange.com 에 대한 답변에서 제안한 것처럼 들어오는 http 요청을 https 연결로 리디렉션하기위한 전용 가상 서버를 만드는 것은 매우 현명하게 들리며 추가적인 보안 위협을 차단합니다. Apache의 구성은 다음과 같습니다.

# Virtual host for rerouting
<VirtualHost *:80>
    ServerName www.example.com
    Redirect permanent / https://www.example.com/
</VirtualHost>

# Virtual host for secure hosting on https
<VirtualHost *:443>
    ServerName www.example.com
    SSLEngine on
    Header set Strict-Transport-Security "max-age=8640000;includeSubdomains"

    ...site settings...

</VirtualHost>