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

왜 모든 것에 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 배나 많은 데이터라고 말했다. 나는 이것을 직접 확인하지 않았으며 매우 높게 들리지만 각 페이지에 헤더가 추가되어 있고 대부분의 페이지에 적은 양의 내용이 있으면 그다지 멀지 않을 수 있습니다.

That said, the hassle of going back and forth between http and https and keeping track of which pages are which seems like too much effort to me. I only once tried to build a site that mixed them and we ended up abandoning the plan when we got tripped up by complex things like pop-up windows created by Javascript getting the wrong protocol attached to them and that sort of thing. We ended up just making the whole site https as less trouble. I guess in simple cases where you just have a login screen and a payment screen that need to be protected and they're simple pages, it wouldn't be a big deal to mix-and-match.

I wouldn't worry much about the burden on the client to decrypt. Normally the client is going to be spending a lot more time waiting for data to come over the wire than it takes to process it. Until users routinely have gigabit/sec internet connections, client processing power is probably pretty irrelevant. The CPU power requried by the server to encrypt pages is a different issue. There might well be issues of it not being able to keep up with hundreds or thousands of users.

---

One other small point (maybe someone can verify), If a user types data into a form item such as a text box and then for some reason refreshes the page or the server crashes out for a second, the data the user entered is lost using HTTPS but is preserved using HTTP.

Note: I'm not sure if this is browser specific but it certainly happens with my Firefox browser.

---

windows Server 2012 with IIS 8.0 now offers SNI which is Server Name Indication which allows multiple SSL Web Applications in IIS to be hosted on one IP Address.

---

The HTTPS is HTTP that is secured with SSL. You may need to register a paid certificate to make your site maintain and trust.

HTTPS is needed when your site needs to exchange information with the user and you want to keep information secured by encryption.

If not, HTTPS is not necessary but you still can use it if you want.

참고URL : https://stackoverflow.com/questions/2746047/why-not-use-https-for-everything