웹 사이트에서 HTTPS를 시행하지 않는 이유가 있습니까?

내가 자주 사용하는 웹 사이트는 마침내 서버에 TLS를 활성화하기로 결정했지만 많은 웹 사이트처럼 TLS를 명령하지 않았습니다. 관리자는 TLS 가 선택 사항 이어야 한다고 주장합니다 . 왜?

내 웹 사이트에서 오랫동안 위임 된 TLS 및 HSTS를 오랫동안 설정했으며 더 약한 암호 제품군이 비활성화되었습니다. TLS로 보호되는 버전에 대한 HTTP 301을 통해 일반 텍스트 액세스가 차단됩니다. 이것이 내 웹 사이트에 부정적인 영향을 줍니까?

TLS를 사용하는 데는 몇 가지 이유가 있습니다

(그리고 그렇게하지 않는 몇 가지 사소한 이유).

• 사이트에 인증이있는 경우 HTTP를 사용하여 세션 및 비밀번호를 도용합니다.

• 정적 인 정보 사이트 일지라도 TLS를 사용하면 아무도 데이터를 무단 변경하지 못합니다.

• Google I / O 2014 이후 Google 은 모든 사이트에서 HTTPS를 사용하도록 권장하기 위해 몇 가지 단계를 수행했습니다.

  • Google은 웹 마스터 가 서버를보다 안전하게 구성 할 수 있도록 돕고 있지만 순위 신호로 HTTPS를 사용했습니다 .
  • 최근 구글 크롬이 시작되었습니다 비보안 같은 HTTP 사이트를 표시 , 안전하지 않은 모든 HTTP 사이트를 표시하는 장기 계획의 일환으로 .
  • Chrome 개발자 팀의 Mythbusting HTTPS 강의는 자세를 명확하게 보여줍니다.

• 모질라 보안 블로그도의 발표했다 비난하는 비보안 HTTP 하여 웹 사이트 확보에만 모든 새로운 기능을 사용할 수 와 점차 브라우저에 대한 액세스 권한을 단계적으로는 안전하지 않은 웹 사이트, 사용자의 보안 및 개인 정보 보호에 대한 위험을 제기 특히 기능을 제공합니다 .

TLS를 시행해야하는 몇 가지 이유도 있습니다

이미 널리 신뢰되는 인증서가 있다면 항상 사용하지 않는 이유는 무엇입니까? 실제로 모든 현재 브라우저는 TLS를 지원하며 루트 인증서가 설치되어 있습니다. 실제로 몇 년 동안 내가 본 유일한 호환성 문제는 Android 기기였으며 Android가 루트 CA 만 직접 신뢰하기 때문에 중간 인증 기관이 누락되었습니다 . 인증서 체인을 루트 CA로 다시 보내도록 서버를 구성하면 쉽게 방지 할 수 있습니다.

관리자가 여전히 직접 연결하지 않고 HTTP 연결을 허용하려는 경우 (예 301 Moved Permanently: 일부 오래된 브라우저 또는 모바일 장치에서 액세스를 보장 하기 위해) 브라우저가 HTTPS를 구성했음을 알 수있는 방법이 없습니다 . 또한 다음 없이 HTTP Strict Transport Security (HSTS) 를 배포해서는 안됩니다 301 Moved Permanently.

7.2.  HTTP Request Type

   If an HSTS Host receives a HTTP request message over a non-secure
   transport, it SHOULD send a HTTP response message containing a status
   code indicating a permanent redirect, such as status code 301
   (Section 10.3.2 of [RFC2616]), and a Location header field value
   containing either the HTTP request's original Effective Request URI
   (see Section 9 "Constructing an Effective Request URI") altered as
   necessary to have a URI scheme of "https", or a URI generated
   according to local policy with a URI scheme of "https").

두 프로토콜 모두에 대해 구성된 다양한 사이트의 문제점은 Tor 프로젝트 와 Electronic Frontier Foundation 에서 인식되며 멀티 브라우저 HTTPS Everywhere 확장을 통해 해결됩니다 .

웹상의 많은 사이트는 HTTPS를 통한 암호화 지원을 제한적으로 제공하지만 사용하기가 어렵습니다. 예를 들어, 기본적으로 암호화되지 않은 HTTP로 설정되거나 암호화되지 않은 사이트로 돌아가는 링크로 암호화 된 페이지를 채울 수 있습니다.

비보안 HTTP 연결을 통해로드 된 JavaScript 또는 CSS를 수정하여 HTTPS 사이트에 대한 XSS 공격으로 인해 혼합 컨텐츠 도 큰 문제가되었습니다. 따라서 오늘날 모든 주류 브라우저는 사용자에게 혼합 컨텐츠가 포함 된 페이지에 대해 경고하고 자동으로로드하지 않습니다. 이로 인해301 HTTP 에서 리디렉션 없이 사이트를 유지 관리하기가 어렵습니다 . 모든 HTTP 페이지는 HTTP 연결 (CSS, JS, 이미지 등) 만로드하고 모든 HTTPS 페이지는 HTTPS 컨텐츠 만로드해야합니다. 둘 다 동일한 내용으로 달성하기는 매우 어렵습니다.

요즘 TLS + HSTS는 자신이하는 일을 신뢰할 수있는 전문가가 사이트를 관리한다는 표시입니다. 구글이 신뢰할 수있는 새로운 표준으로 자리 잡았다.

다른 한편으로는 최대 호환성입니다. 특히 미국, 유럽 또는 중국이 아닌 일부 지역에는 여전히 오래된 고객이 있습니다. 일반 HTTP는 항상 작동하지만 항상 잘 작동하는 것은 아니며 다른 이야기입니다.

TLS + HSTS : 검색 엔진 순위 최적화
일반 HTTP : 호환성 최적화

당신에게 더 중요한 것에 달려 있습니다.

HTTPS를 사용하지 않는 단순 읽기 전용 웹 사이트 에는 한 가지 이유 가 있습니다.

• 웹 캐시는 HTTPS를 통해 전송 된 이미지를 캐시 할 수 없습니다.
• 세계의 일부 지역은 국제 통신 속도가 매우 느리므로 캐시에 따라 다릅니다.
• 다른 도메인의 이미지를 호스팅하면 소규모 읽기 전용 웹 사이트 운영자 가 가질 수없는 기술이 필요합니다 .

관리자는 TLS가 선택 사항이어야한다고 주장합니다. 왜?

이 질문에 대한 답을 진정으로 알기 위해서는 반드시 질문해야합니다. 그러나 우리는 몇 가지 추측을 할 수 있습니다.

회사 환경에서는 IT 부서에서 맬웨어가 들어오는 트래픽과 나가는 트래픽, 의심스러운 CnC와 유사한 활동, 업무에 부적합한 콘텐츠 (예 : 포르노) 등을 검사하는 방화벽을 설치하는 것이 일반적입니다. 트래픽이 암호화되면 훨씬 어려워집니다. 본질적으로 세 가지 가능한 응답이 있습니다.

1. 이 트래픽 모니터링을 포기하십시오.
2. MitM 암호 해독 및 검사를 수행 할 수 있도록 사용자 컴퓨터에 루트 CA를 설치하십시오.
3. 암호화 된 트래픽을 도매로 차단합니다.

관련 sysadmin의 경우 이러한 옵션 중 어느 것도 특히 매력적인 것은 아닙니다. 회사 네트워크를 공격하는 많은 위협이 있으며 회사를 위협으로부터 보호해야합니다. 그러나 많은 사이트를 차단하면 사용자의 분노가 커지고 루트 CA를 설치하면 사용자에 대한 개인 정보 보호 및 보안 고려 사항이 도입되기 때문에 다소 번거로울 수 있습니다. HSTS를 처음 켰을 때 sysadmin 청원 reddit을 보았을 때 (미안하지만 스레드를 찾을 수 없음) 기억합니다. 그는 정확히이 상황에 있었기 때문에 비즈니스에 의해 강요 당했기 때문에 모든 reddit을 차단하고 싶지 않았습니다 포르노 중심 하위 구성 요소를 차단합니다.

기술의 바퀴가 계속 앞서 가고 있으며, 이런 종류의 보호는 구식이며 단계적으로 폐지되어야한다고 주장하는 많은 사람들을 보게 될 것입니다. 그러나 여전히 많은 사람들이 그것을 연습하고 있으며 아마도 당신의 신비한 관리자가 관심을 갖는 사람들 일 것입니다.

모든 것은 보안 요구 사항, 사용자 선택 및 암시 적 다운 그레이드 위험에 따라 결정됩니다. 브라우저는 사용자 경험 / 편의성의 이름으로 클라이언트 측에서 절대적으로 끔찍한 암호로 넘어갈 수 있기 때문에 서버 측에서 오래된 암호를 비활성화하는 것이 필수적입니다. 당신의 확인 아무것도 만들기 없다 따라 사용자에게 보안 채널에하는 것입니다, 물론, 매우 소리가 안전하지 않은 방법으로 도달 할 수 없습니다.

내가 왜 루비보다 파이썬을 더 좋아하는지에 대한 블로그 게시물 (일반적인 예는 아니지만)이 내가 짜증나거나 대중에게 아는 것이 아니라고 생각했을 때 안전하지 않은 HTTP로 명시 적으로 다운 그레이드 할 수 없다 나는 HTTPS가 사소한 것이라고 가정하여 정당한 이유없이 접근하고 있습니다.

오늘날에는 기본적으로 TLS를 사용할 수있는 기능이 없거나 기존 구현에 갇혀있는 시스템이 있습니다 (이것이 끔찍한 것은 좋지만 [insert embed의 고급 사용자] 여기에 기기]를 추가 한 경우가 있습니다.

재미있는 실험이 있습니다 : 충분히 오래된 TLS / SSL 구현으로 HTTPS를 통해 업스트림 OpenBSD 사이트에서 최신 버전의 LibreSSL을 다운로드하십시오. 당신은 할 수 없습니다. 다른 날에는 2012 년부터 오래된 OpenSSL 빌드가있는 장치에서 시도했습니다.이 임베디드 시스템을 소스에서보다 안전하고 새로운 것으로 업그레이드하고 싶었습니다. 사전 빌드 패키지의 고급 스러움이 없습니다. 내가 시도했을 때의 오류 메시지는 정확히 직관적이지 않았지만 이전 OpenSSL이 올바른 것을 지원하지 않았기 때문인 것으로 추정됩니다.

이것은 유일한 HTTPS의 움직임이 실제로 사람들을 해칠 수있는 한 가지 예입니다. 최근 사전 구축 된 패키지가없고 소스를 기반으로 직접 문제를 해결하려는 경우에는 잠겨 있습니다. 고맙게도 LibreSSL의 경우 HTTP를 명시 적으로 요청하는 것으로 넘어갈 수 있습니다. 물론, 이렇게하면 공격자가 이미 트래픽을 다시 작성하여 소스 패키지를 손상된 버전으로 교체하고 사용자가 찾은 웹 페이지에서 다운로드 할 수있는 패키지를 설명하는 HTTP 본문의 모든 체크섬을 다시 작성할 수는 있지만 여전히 유용합니다. 더 일반적인 경우.

우리 대부분은 APT (Advanced Persistent Thread : 국가 정보 기관을위한 보안 전문 용어 및 기타 리소스가 매우 엄격한 사이버 위협)가 소유하고있는 보안되지 않은 다운로드가 아닙니다. 때로는 wget가장 일반적인 암호 제품군을 지원하지 않는 상자에 대한 소스 (예를 들어 GitHub의 작은 유틸리티 / 스크립트)를 신속하게 감사 할 수있는 일반 텍스트 문서 나 작은 프로그램을 원합니다 .

개인적으로 다음과 같이 묻습니다. "공개 지식에 액세스하는 것이 괜찮습니다"라고 합법적으로 결정할 수있는 귀하의 콘텐츠입니까? 비 기술적 인 사람들이 실수로 귀하의 콘텐츠에 대해 HTTP로 다운 그레이드 할 수있는 실질적인 위험이 있습니까? 보안 요구 사항, 사용자에 대한 개인 정보 보호 요구 사항 및 사례별로 정보를 선택하여 위험을 감수 할 위험을 이해하는 사용자의 능력에 대한 암시 적 다운 그레이드 위험에 가중치를 부여하십시오. 귀하의 사이트에 대해 HTTPS를 시행하지 않을 이유가 없다고 말하는 것은 전적으로 합법적입니다. 그러나 여전히 일반 HTTP에 대한 유스 케이스가 여전히 있다고 말할 수 있습니다.

여기에서 왜 tls가 좋은지에 대한 많은 토론이 있지만 원래 게시물 에서처럼 묻지 않았습니다.

Maxthon은 두 가지 질문을했습니다.

1) 왜 이름이 지정되지 않은 임의의 사이트가 http 및 https를 유지하기로 결정했는지

2) http 요청에 대해 301 응답 만 제공하는 Maxthon에 부정적인 영향이 있습니까?

첫 번째 질문과 관련하여 Google은 왜 공급자가 http 및 https 사이트를 유지하기로 선택했는지 알 수 없습니다. 많은 이유가있을 수 있습니다. 호환성, 분산 캐싱 및 지정 학적 액세스 가능성에 대한 힌트 외에도 컨텐츠 통합에 대한 고려 사항과 컨텐츠가 안전하지 않은 브라우저 메시지를 피하는 것이 좋습니다. Alvaro가 지적했듯이 TLS는 보안과 관련하여 빙산의 일각에 불과합니다.

그러나 두 번째 질문은 대답 할 수 있습니다. 보안 작업을 위해 실제로 https가 필요한 경우 http를 통해 웹 사이트 사이트의 일부를 노출하면 공격에 악용 될 수 있습니다. 그러나 트래픽이 사이트의 포트 80으로 잘못 전달되는 위치를 식별하고 원인을 수정하기 위해이를 유지하는 것이 합리적입니다. 즉, 부정적인 영향과 긍정적 인 영향을 줄 수있는 기회가 있으며, 그 결과는 관리자로서의 업무 수행 여부에 달려 있습니다.

Sysadmin1138에 따르면 https는 SEO 순위에 영향을 미칩니다. Google은 순위에 영향을 미친다고 말했지만, 믿을만한 유일한 연구에 따르면 그 차이는 작습니다. 최상위 사이트는 https가있을 가능성이 높기 때문에 https가 있으면 순위가 향상 된다는 주장을 더 잘 알고 있어야 하는 사람들 에게는 도움이되지 않습니다 .

과거에는 HTTP를 <embed>통해 제공되는 다른 페이지의 페이지를 원했기 때문에 HTTPS 대신 HTTP를 사용해야했지만 다른 방식으로는 작동하지 않습니다.

나쁜 / 깨진 / 안전하지 않은 클라이언트가 있다는 것을 의미 하는 좋은 이유 는 아니지만 기존 http://URL을 통해 리소스에 액세스하는 자동화 된 프로세스가있는 경우 https를 지원하지 않는 경우도 있습니다 (예 : busybox wget). 내부적으로 TLS를 지원하지 않고 openssl 하위 프로세스를 통해 더 최근에 추가했습니다)) 따라갈 수없는 https URL로 리디렉션되면 중단됩니다.

알 수없는 (또는 알려진 레거시) User-Agent 문자열이 리디렉션되는 것을 제외하고 원하는 경우 http를 통해 콘텐츠에 액세스 할 수 있도록 리디렉션 규칙을 작성하여 실제 브라우저가 모두 이익을 얻을 수 있도록 하여이 가능성을 다루고 싶습니다. 강제 https / hsts.

거의가 있습니다 좋은 HTTP를 사용하는 대신 HTTPS의 웹 사이트에 대한 이유는. 귀하의 웹 사이트가 모든 종류의 거래를 처리하거나 모든 종류의 민감한 또는 개인 데이터를 저장하는 경우, 데이터를 안전하게 보호하려면 HTTPS를 반드시 사용해야합니다. HTTPS를 적용하지 않은 것으로 보이는 유일한 이유는 HTTPS가 캐싱과 작동하지 않기 때문에 웹 사이트가 캐싱에 의존하는 경우입니다. 그러나 웹 사이트의 보안을 유지하기 위해 약간의 성능을 희생 할 가치가 있습니다. 클라이언트가 HTTPS를 지원하지 않을 수도 있지만 실제로 2017 년에는 HTTPS를 지원해야 할 수도 있습니다.