왜 모든 것에 HTTPS를 사용하지 않습니까?

서버를 설정하고 SSL 인증서를 보유한 경우 구매 / 로그인 대신 전체 사이트에 HTTPS를 사용하지 않는 이유는 무엇입니까? 전체 사이트를 암호화하고 사용자를 완전히 보호하는 것이 더 합리적이라고 생각합니다. 모든 것이 안전하기 때문에 무엇을 보호해야할지 결정하는 등의 문제를 방지 할 수 있으며 사용자에게는 불편하지 않습니다.

사이트의 일부에 이미 HTTPS를 사용하고 있었다면 전체 사이트에 HTTPS를 사용하고 싶지 않은 이유는 무엇입니까?

이것은 관련 질문입니다. 왜 https가 로그인에만 사용됩니까? 답변이 만족스럽지 않습니다. 답변에 따르면 전체 사이트에 https를 적용 할 수 없습니다.

몇 가지 이유를 생각할 수 있습니다.

• 일부 브라우저는 SSL을 지원하지 않을 수 있습니다.
• SSL은 성능을 다소 떨어 뜨릴 수 있습니다. 사용자가 큰 공개 파일을 다운로드하는 경우 매번 이러한 파일을 암호화해야하는 시스템 부담이있을 수 있습니다.

다른 이유 (특히 성능 관련) 외에도 HTTPS를 사용할 때 IP 주소 당 하나의 도메인 * 만 호스팅 할 수 있습니다.

서버 HTTP 헤더는 서버가 응답 할 도메인을 서버에 알리기 때문에 단일 서버는 HTTP에서 여러 도메인을 지원할 수 있습니다 .

HTTPS를 사용하면 서버는 초기 TLS 핸드 셰이크 중 (HTTP가 시작되기 전에) 클라이언트에 인증서를 제공해야합니다. 이는 서버 헤더가 아직 전송되지 않았기 때문에 서버가 요청중인 도메인과 응답 할 인증서 (www.foo.com 또는 www.bar.com)를 알 수있는 방법이 없습니다.

* 각주 : 기술적으로 여러 도메인을 다른 포트에서 호스팅하는 경우 여러 도메인을 호스팅 할 수 있지만 일반적으로 옵션은 아닙니다. SSL 인증서에 와일드 카드가있는 경우 여러 도메인을 호스트 할 수도 있습니다. 예를 들어 인증서 * .example.com을 사용하여 foo.example.com과 bar.example.com을 모두 호스팅 할 수 있습니다.

SSL / TLS는 거의 자주 사용되지 않습니다. 전체 세션에 HTTPS를 사용해야합니다 . HTTP를 통해 세션 ID를 보낼 수 없습니다. 로그인에 https 만 사용하는 경우 2010 년 "A3 : 인증 및 세션 관리 손상"에 대한 OWASP Top 10을 명백히 위반 한 것입니다 .

등록 된 우편을 통해 모든 달팽이 우편 게시물을 변조 방지용 불투명 봉투에 보내지 않겠습니까? 우체국의 누군가는 항상 개인적으로 양육권을 가지므로 아무도 메일을 스누핑하지 않도록 확신 할 수 있습니다. 대답은 일부 메일은 비용이 들지만 대부분의 메일은 그렇지 않다는 것입니다. 누군가 "내가 감옥에서 나왔다"라고 읽는 사람은 신경 쓰지 않습니다. 삼촌 조에게 엽서.

암호화는 무료가 아니며 항상 도움이되는 것은 아닙니다.

쇼핑, 뱅킹 등과 같은 세션이 HTTPS를 사용하여 종료되는 경우 전체 세션을 가능한 빨리 HTTPS로 만들지 않을 이유가 없습니다.

내 의견은 HTTPS는 요청 또는 응답이 중간 스누핑으로부터 보호되어야하기 때문에 불가피하게 필요할 때만 사용해야한다는 것입니다. 예를 들어 Yahoo! 홈페이지. 로그인 한 경우에도 대부분의 상호 작용은 HTTP를 통해 이루어집니다. HTTPS를 통해 인증하고 신원을 증명하는 쿠키를 얻으므로 뉴스 기사를 읽는 데 HTTPS가 필요하지 않습니다.

시스템로드 외에 가장 큰 이유는 이름 기반 가상 호스팅을 중단하기 때문입니다. SSL을 사용하면 하나의 사이트-하나의 IP 주소입니다. 이것은 꽤 비싸고 관리하기가 어렵습니다.

대기 시간이 긴 링크의 경우 초기 TLS 핸드 셰이크는 인증서 체인 (중간 인증서 전송 포함)의 유효성을 검사하고 암호 제품군에 동의하며 세션을 설정하기 위해 추가 왕복이 필요합니다. 세션이 설정되면 후속 요청은 왕복 횟수를 줄이기 위해 세션 캐싱을 사용할 수 있지만이 경우에도 일반 HTTP 연결에 필요한 것보다 더 많은 왕복이 있습니다. 암호화 작업이 무료 왕복 이었음에도 불구하고 특히 사이트가 http 파이프 라이닝을 활용하지 않는 경우 느린 네트워크 링크에서는 눈에 띄지 않을 수 있습니다. 네트워크의 잘 연결된 세그먼트 내의 광대역 사용자에게는 이것이 문제가되지 않습니다. 국제적으로 비즈니스를 수행하는 경우 https가 눈에 띄게 지연 될 수 있습니다.

잠재적으로 훨씬 더 많은 메모리가 필요한 세션 상태의 서버 유지 관리 및 데이터 암호화 작업과 같은 추가 고려 사항이 있습니다. 모든 소규모 사이트는 실제 서버 성능과 오늘날의 하드웨어 비용에 대해 걱정할 필요가 없습니다. 모든 대규모 사이트는 비슷한 기능을 제공하기 위해 CPU / w AES 오프로드 또는 애드온 카드를 쉽게 제공 할 수 있습니다.

시간이 지남에 따라 하드웨어와 네트워크의 기능이 향상됨에 따라 이러한 모든 문제가 점점 더 문제가되지 않고 있습니다. 대부분의 경우 오늘날 나는 실질적인 차이가 의심됩니다.

https 트래픽 (중간 콘텐츠 필터 등)에 대한 관리 제한과 같은 운영상의 고려 사항이있을 수 있으며 일부 회사 또는 정부 규정이있을 수 있습니다. 일부 회사 환경에서는 정보 유출을 방지하기 위해 경계에서 데이터 암호 해독이 필요합니다. https 트랜잭션에서 메시지를 주입 할 수없는 핫스팟 및 유사한 웹 기반 액세스 시스템과의 간섭. 하루가 끝나면 기본적으로 https를 사용하지 않는 이유는 매우 작을 것입니다.

https는 일반적인 http보다 리소스가 부족합니다.

서버와 클라이언트 모두에서 더 많은 것을 요구합니다.

전체 세션이 암호화되면 프록시 수준 (예 : ISP)에서 이미지 및 js와 같은 정적 리소스에 대해 캐싱을 사용할 수 없습니다.

어디에서나 HTTPS를 사용해야하지만 다음과 같은 내용이 손실됩니다.

1. BREACH 및 CRIME 공격으로 인해 SSL을 통한 SSL 압축 또는 SSL을 통한 HTTP 압축을 사용해서는 안됩니다. 응답에 세션 또는 csrf 식별자가 포함 된 경우 압축이 없습니다. 쿠키없는 도메인에 정적 리소스 (이미지, js, css)를 넣고 압축을 사용하여이를 완화 할 수 있습니다. HTML 축소를 사용할 수도 있습니다.

2. SNI를 사용하지 않는 한 SSL 인증서 1 개, IP 주소 1 개 (일부 Android, 블랙 베리 6 등)는 모든 브라우저에서 작동하지 않습니다.

3. SSL을 통해 제공되지 않는 외부 콘텐츠를 페이지에 호스팅해서는 안됩니다.

4. 브라우저가 HTTP 페이지로 이동하면 아웃 바운드 HTTP Referer 헤더를 잃게되는데 이는 문제가 될 수도 있고 아닐 수도 있습니다.

명백한 이유는 성능입니다. 모든 데이터는 전송 전에 서버에 의해 암호화 된 다음 수신시 클라이언트에 의해 해독되어야합니다. 민감한 데이터가없는 경우 시간 낭비입니다. 캐시되는 사이트의 양에도 영향을 줄 수 있습니다.

또한 모든 주소 https://가 익숙하지 않고 사용 하는 경우 최종 사용자에게 혼란을 줄 수 http://있습니다. 또한이 답변을 참조하십시오 :

js 파일을 포함 할 때 항상 https를 사용하지 않는 이유는 무엇입니까?

https는 서버가 클라이언트 요청 및 응답을 암호화하고 해독해야합니다. 서버가 많은 클라이언트를 지원하는 경우 성능에 영향을 미칩니다. 그렇기 때문에 대부분의 최신 https 구현은 비밀번호 인증으로 만 제한됩니다. 그러나 컴퓨팅 성능이 향상됨에 따라 모든 Gmail에서 전체 사이트에 SSL을 사용한 후에 변경 될 수 있습니다.

WhirlWind의 응답 외에도 SSL 인증서의 비용 및 적용 가능성, 액세스 문제 (클라이언트가 SSL 포트를 통해 통신 할 수없는 경우도 있음) 등을 고려해야합니다.

SSL을 사용한다고해서 보안이 보장되는 것은 아닙니다. 이러한 유형의 보호는 마법의 총알에 의존하기보다는 애플리케이션 아키텍처에 내장되어야합니다.

회사의 한 프로젝트에서 SSL 메시지가 차지하는 대역폭이 일반 메시지보다 훨씬 더 크다는 것을 알게되었습니다. 나는 누군가가 그것이 12 배나 많은 데이터라고 말했다. 나는 이것을 직접 확인하지 않았으며 매우 높게 들리지만 각 페이지에 헤더가 추가되어 있고 대부분의 페이지에 적은 양의 내용이 있으면 그다지 멀지 않을 수 있습니다.

즉, http와 https 사이를 오가며 번거롭고 어떤 페이지가 나에게 많은 노력을 기울이고 있는지 추적하는 번거 로움이 있습니다. 나는 단지 한 번만 그것들을 혼합 한 사이트를 만들려고 시도했고 우리는 잘못된 프로토콜을 첨부 한 Javascript로 생성 된 팝업 창과 같은 복잡한 것들과 그와 같은 것들에 의해 넘어 졌을 때 계획을 포기하게되었습니다. 우리는 전체 사이트를 https 덜 문제로 만드는 것으로 끝났습니다. 로그인 화면과 지불 화면이 보호되어야하고 간단한 페이지 인 간단한 경우에는 믹스 앤 매치에 큰 도움이되지 않습니다.

나는 클라이언트가 해독 해야하는 부담에 대해 크게 걱정하지 않을 것입니다. 일반적으로 클라이언트는 데이터 처리에 걸리는 시간보다 데이터가 전송 될 때까지 더 많은 시간을 소비합니다. 사용자가 일상적으로 기가비트 / 초 인터넷 연결을 할 때까지 클라이언트 처리 능력은 관련이 없을 것입니다. 서버가 페이지를 암호화하기 위해 필요한 CPU 전원은 다른 문제입니다. 수백 또는 수천 명의 사용자를 유지하지 못하는 문제가있을 수 있습니다.

다른 작은 점 (아마도 누군가가 확인할 수 있음), 사용자가 텍스트 상자와 같은 양식 항목에 데이터를 입력 한 다음 어떤 이유로 인해 페이지를 새로 고치거나 서버가 잠시 동안 중단되면 사용자가 입력 한 데이터가 손실됩니다. HTTPS이지만 HTTP를 사용하여 유지됩니다.

참고 : 이것이 브라우저마다 고유한지 확실하지 않지만 Firefox 브라우저에서 발생합니다.

IIS 8.0이 포함 된 Windows Server 2012는 이제 IIS의 여러 SSL 웹 응용 프로그램을 하나의 IP 주소에서 호스팅 할 수있는 서버 이름 표시 인 SNI를 제공합니다.