전체 사이트에 대한 HTTPS

10

등록 된 사용자를위한 공개 컨텐츠와 개인 / 사용자 정의 컨텐츠가 포함 된 상당히 표준적인 웹 사이트에서 작업하고 있습니다. 사용자가 로그인하거나 신용 카드 정보를 보낼 때 HTTPS를 사용해야한다는 것을 알고 있습니다. 전체 사이트에 HTTPS 만 사용해서는 안되는 이유가 있습니까?

https

— BenV
소스

12

예, 전체 사이트에 사용해서는 안되는 이유가 있습니다. 브랜드 및 버전에 따라 일부 브라우저는 HTTPS 요청의 콘텐츠를 디스크로 캐시하지 않으므로 모든 페이지 요청 (스타일 시트, 자바 스크립트, 헤더 이미지 등)과 함께 정적 자산이로드되므로 사용자의 탐색 환경이 심각하게 느려질 수 있습니다. . 예를 들어, Mozilla는 다음과 같이 말합니다.

"디스크 캐싱은 다운로드 한 파일의 사본을 하드 드라이브에 저장하므로 다시 표시하기 위해 다운로드 할 필요가 없습니다.이 페이지는 캐시 폴더에 대한 권한이있는 모든 사람이 볼 수 있습니다. SSL 암호화로 전송 된 페이지에는 종종 중요한 정보가 포함되어 있습니다. 이 페이지를 디스크에 캐싱하면 개인 정보가 위험해질 수 있습니다.이 기본 설정은 SSL 암호화로 전송 된 디스크 페이지에 캐시할지 여부를 제어합니다. "

개별 브라우저가 HTTPS를 캐시하는 방법은 다소 논쟁의 여지가 있지만 여전히 많은 사용자가 HTTPS 요청에 대해 디스크 캐싱을 사용하지 않을 가능성이 높습니다.

둘째, HTTPS에는 모든 요청에 대해 " 핸드 셰이크 " 가 필요하며 이로 인해 약간의 오버 헤드가 발생하여 성능에 영향을 미치고 요청을 더 크게 만듭니다 (일반적으로 몇 KB 만 가능하지만 모든 요청에 해당하며 추가). HTTP KeepAlive 는이를 제한 할 수 있지만 여전히 비보안 컨텐츠에는 필요하지 않은 오버 헤드입니다.

— 댄 디플로
소스

2

여기의 모든 것이 사실입니다. 그러나 현재 약 5 년 동안 전체 SSL 웹 사이트를 운영하고 있으며 사용자로부터 불만을 제기 한 적이 없습니다. 대부분은 IE6 및 IE7에서 기업이므로 요즘 Firefox에서는 몇 가지가 있습니다. 캐싱은 잘 작동하는 것처럼 보였지만 많은 이미지에 명시적인 내용 만료 규칙이 설정되어 있었지만 차이가 있는지 모르겠습니다.

— Mark Henderson

5

추측하지 마십시오 : 테스트 :-). 캐싱이 작동하는지 확인하는 간단한 방법 (거칠고 완전하지는 않지만) 중 하나는 서버 로그에서 사용자 요청을 확인하는 것입니다. 모든 이미지 / 파일 또는 캐시되지 않은 콘텐츠 만 요청합니까? 개별 사용자는 대기 시간을 잘못 판단하지만 집계 할 때 밀리 초를 볼 수 있으므로 속도가 실제로 수용 가능한지 확인해야합니다.

— 존 뮬러

10

전체 SSL을 실행하려는 경우 사용중인 호스팅 된 타사 서비스 (광고 서버, 분석, 공유 도구 등)에 SSL 버전이 있는지 확인하십시오. 그렇지 않으면 일부 브라우저에서 혼합 된 내용 경고가 표시됩니다.

— 제이슨 버치
소스

5

또 다른 문제는 모든 페이지 에서 제공 하는 모든 것이 실제로 타사 리소스를 포함하여 SSL을 통해 이동해야한다는 것입니다. 예를 들어 YouTube와 같은 문제가 실제로 발견되었습니다. 구글은 SSL을 통해 YouTube 동영상을 사용할 수 있도록하지 않기 때문에, 그것은 당신이 어떤 YouTube 동영상을 의미 할 귀하의 사이트의 페이지에 포함시킬는 경고 "이 페이지는 보안 및 비보안 내용을 포함"의 원인이됩니다. 이것은 대부분의 브라우저에서 미묘하지만 IE의 거대한 대화 상자이며 일부 사용자가 사이트를 매우 빨리 포기하여 데이터를 가슴에 쥐게 만들 수 있습니다.

— 바비 잭
소스

2

또한 성장에 대해서도 생각해야합니다. 웹 서버가 하나 이상인 경우 다음을 결정해야합니다. 각 개별 서버에서 HTTPS를 제공 하시겠습니까? 그렇다면 각 서버마다 동일한 인증서 또는 인증서를 사용하는 것이 좋습니다. 나는 일반적으로 민감한 세부 정보를 처리하는 데만 사용되는 HTTPS 서버가 적고 더 많은 트래픽을 수신하는 경향이 있기 때문에 더 많은 HTTP 서버가있는 더 일반적인 설정을 보았습니다. HTTPS는 각 설정에 조금 더 복잡합니다. 명심해야 할 것.

— 개비.
소스

1

내가 알다시피, 전체 사이트에서 HTTPS를 사용하지 않는 유일한 이유는 서버의 속도가 느리고 방문자가 브라우징 경험이 약간 느리기 때문입니다. 즉, 이점이 있습니다. 구체적으로 특별히:

사이트의 모든 페이지에 안전하게 유지하려는 데이터를 넣는 것에 대해 걱정할 필요가 없습니다. 잊을 수 없습니다.
사용자는 사이트가 완전히 암호화되어 있으며 정보를 제공하는 것이 더 안전하다고 느낄 수 있습니다.
사용자는 귀하의 웹 사이트가 회사의 소유이며 인수되지 않았 음을 알고 있습니다.

개발자가 암호화되지 않은 페이지에 보안 데이터를 표시하는 것에 대해 걱정하지 않아도되는 것 외에도 모든 페이지에서 HTTPS를 사용해야하는 기술적 이유 는 없습니다 . 같은 추론으로 할 이유가 거의 없습니다.

— 벤 호프만
소스

전체 사이트에서 HTTPS를 사용하지 않는 다른 이유는 페이지가 클라이언트 측 (이론적으로) 캐시되지 않기 때문에 더 많은 대역폭이 사용됩니다.

— MrWhite

"사이트의 모든 페이지에 안전하게 유지하려는 데이터를 넣는 것에 대해 걱정할 필요가 없습니다." -이것이 사실인지 잘 모르겠습니다. Google은 기본적으로이 페이지를 _and cache_ (!)합니다. 요청하면 캐시 된 버전을 일반 HTTP로 제공하는 것으로 보입니다.

— MrWhite

0

마지막으로, 몇몇 고용주는 직원이 "암호화 된"https 사이트를 탐색하는 것을 좋아하지 않습니다. 이는 방어 / 보안 회사 및 조직의 경우이므로 "https"웹 사이트가있는 경우 해당 네트워크를 통해 사이트를 탐색 할 수 없기 때문에 이러한 방문자 / 고객 중 일부를 잃을 수 있습니다.

— 라덱
소스

이것에 대한 증거가 있습니까? 이 주장을 뒷받침하는 기사에 링크 할 수 있습니까?

— Andrew Lott

이 주제에 대한 개인적인 경험이 있습니다. 나는 대규모 군사 중심 웹 사이트를 운영하고 HTTPS 설정을 테스트하는 동안 고용주가 네트워크에서 https 서핑을 허용하지 않기 때문에 이것이 사용자의 큰 부분에 문제가 있음을 알았습니다. https는 불가능합니다). Google이 https로 전환하도록 강요 할 때이 문제에 접근하는 방법에 대한 또 다른 스레드를 시작했습니다. 이는 모든 사람이 알고있는 문제는 아니지만 발생하고 사람들이 고려해야 할 수도 있습니다.

— Radek

일부 모니터링 도구는 프록시 사용자 또는 웹 사이트 사이의 "중간자"프록시 또는 패킷의 "콘텐츠"를보고 보안 문제, 비밀 또는 기타 사항을 모니터링하고 SSL 사용 안함을 사용해야한다고 스스로 설명합니다. 그러한 모니터링. 따라서 https는 이러한 회사에서 허용되지 않습니다 (모든 회사에서 말하지는 않지만 분명히 일부 회사에서는 가능합니다)

— Radek