HTTPS를 사용하는 이유는 무엇입니까?

HTTP와 HTTPS의 차이점은?

HTTPS는 TLS 암호화를 갖춘 HTTP입니다. HTTPS는 TLS(SSL)를 사용하여 일반 HTTP 요청과 응답을 암호화하므로 더 안전하고 보안이 강화됩니다. HTTPS를 사용하는 웹 사이트의 URL 앞에는 http:// 대신 https://(예: https://www.cloudflare.com)가 있습니다.

그렇다면 웹 사이트에서는 왜 HTTPS를 사용해야 할까요?

이유 1: HTTPS를 사용하는 웹 사이트는 사용자가 더 신뢰할 수 있습니다.

HTTPS를 사용하는 웹 사이트는 지역 식품 안전 검사관으로부터 "합격"을 받았음을 게시하는 식당과 같습니다. 잠재 고객은 큰 부작용 없이 해당 업체를 이용할 수 있다는 것을 신뢰할 수 있습니다. 요즘 같은 시대에 HTTP를 사용하는 것은 식품 안전 검사 "불합격" 표시를 게시하는 것과 같습니다. 고객에게 뭔가 안 좋은 일이 발생하지 않는다는 보장이 없습니다.

HTTPS는 SSL/TLS 프로토콜을 사용하여 통신을 암호화하므로 공격자가 데이터를 탈취할 수 없습니다. 또한 SSL/TLS는 웹 사이트 서버가 실제 서버임을 확인하므로 사칭이 방지됩니다. 이는 식품 안전이 질병을 예방하는 것과 마찬가지로 여러 종류의 사이버 공격을 차단합니다.

일부 사용자는 SSL/TLS의 이점을 인식하지 못할 수도 있지만, 최신 브라우저에서는 어떤 경우에도 웹 사이트의 신뢰성을 인식하도록 하고 있습니다.

Chrome 등의 브라우저에서는 모든 HTTP 웹 사이트를 "안전하지 않음"으로 표시합니다.

Google에서는 여러 해에 걸쳐 점진적으로 조치를 취하여 웹 사이트에 HTTPS를 도입하도록 했습니다.Google 또한 검색 결과를 반환하는 방식에서 품질 요소로 HTTPS를 사용하며, 웹 사이트의 보안 수준이 높을수록 방문자가 Google이 제공한 링크를 클릭함으로써 실수할 가능성이 낮아집니다.

2018년 7월 Chrome 68 출시와 함께 보호되지 않은 모든 HTTP 트래픽은 URL 표시줄에 '안전하지 않음'이라고 표시됩니다. 이 알림은 유효한 SSL 인증서가 없는 모든 웹 사이트에 표시됩니다. 다른 브라우저도 그 뒤를 따랐습니다.

이유 2: 사용자와 웹 사이트 소유자 모두에게 HTTPS가 더 안전합니다.

HTTPS를 사용하면 원본 서버로 전송되는 데이터와 원본 서버에서 수신되는 데이터의 양방향 전송이 모두 암호화됩니다.프로토콜은 악의적인 당사자가 전송되는 데이터를 관찰할 수 없도록 통신을 안전하게 유지합니다.따라서 사용자가 양식에 사용자 이름과 비밀번호를 입력할 때 이들 정보가 전송 중에 도난당하지 않습니다.웹 사이트나 웹 애플리케이션에서 사용자에게 중요한 데이터나 개인 데이터(예: 은행 계좌 정보)를 전송해야 하는 경우, 암호화를 통해 해당 데이터도 보호될 수 있습니다.

이유 3: HTTPS에서는 웹 사이트가 인증됩니다.

Uber나 Lyft와 같은 차량 공유 앱의 사용자는 운전자가 픽업하러 왔다고 말한다고 해서 낯선 차에 무작정 올라탈 필요가 없습니다. 대신 앱에 운전자의 이름과 외모, 운전하는 차량의 종류, 차량 번호 등 운전자에 대한 정보가 표시됩니다. 공유 차량이 모두 다르고 운전자를 한 번도 본 적이 없더라도 사용자는 이러한 사항을 확인해서 올바른 차량에 탑승하게 되는지 확인할 수 있습니다.

마찬가지로 사용자가 웹 사이트를 탐색할 때 실제로 하는 일은 한 번도 본 적 없는 사람이 관리하는, 잘 알지 못하고 먼 곳에 있는 컴퓨터에 연결하는 것입니다. HTTPS를 활성화하는 SSL 인증서는 차량 공유 앱의 운전자 정보와 같습니다. 이는 신뢰할 수 있는 제3자가 웹 서버가 자칭하는 실체임을 외부에서 검증하는 것을 의미합니다.

이를 통해 공격자가 웹 사이트를 사칭하거나 스푸핑하여 사용자가 실제로는 가짜 사이트에 접속하고 있는데도 의도한 사이트에 접속한 것처럼 보이게 하는 공격이 방지됩니다. 또한 HTTPS 인증은 회사 웹 사이트가 합법적으로 보이도록 하는 데 많은 도움을 주며, 이는 회사에 대한 사용자의 태도에도 영향을 줍니다.

HTTPS에 대하여 오해하는 개념

많은 웹 사이트에서 HTTPS를 채택하는 속도가 느렸습니다. 왜 이런 일이 발생했는지 알아보려면 역사를 살펴볼 필요가 있습니다.

HTTPS가 처음 배포되기 시작했을 때는 제대로 구현하기 어렵고, 느리며, 비용이 많이 들고, 인터넷 요청 속도가 느려지며, 값비싼 인증서 서비스가 필요해서 비용이 증가했습니다. 이러한 장애물은 아직도 존재하지만, 많은 웹 사이트 소유자에게는 여전히 두려움이 남아 있어 더 나은 보안으로 도약하는 데 걸림돌이 되고 있습니다. HTTPS에 대한 몇 가지 잘못된 상식을 살펴보겠습니다.

"웹 사이트에서 중요한 정보를 취급하지 않으므로 HTTPS가 필요하지 않습니다"

웹 사이트에서 보안을 구현하지 않는 일반적인 이유는 보안 수준이 목적에 비해 과하다고 생각하기 때문입니다. 중요한 데이터를 다루지 않는다면 누군가가 스누핑을 하더라도 누가 신경이나 쓸까요? 웹 보안을 지나치게 단순하게 바라보는 데에는 몇 가지 이유가 있습니다. 예를 들어, 일부 인터넷 서비스 공급자는 실제로 HTTP로 제공되는 웹 사이트에 광고를 삽입합니다. 이러한 광고는 웹사이트의 콘텐츠와 방향이 일치하거나 일치하지 않을 수 있으며, 웹사이트 공급자가 창의적인 입력을 하지 않거나 수익을 공유하지 않는다는 사실은 제쳐두더라도, 잠재적으로 공격적일 수 있습니다. 사이트의 보안이 확보되면 이러한 삽입 광고는 더 이상 실행할 수 없습니다.

최신 웹 브라우저에서는 이제 안전하지 않은 사이트에 대하여 기능을 제한합니다. 웹 사이트의 품질을 향상시키는 중요한 기능에는 이제 HTTPS가 필요합니다. 위치 정보, 푸시 알림, 프로그레시브 웹 애플리케이션(PWA)을 실행하는 데 필요한 Service Workers는 모두 강화된 보안을 필요로 합니다. 이는 타당합니다. 사용자의 위치와 같은 데이터는 중요한 정보이며 악의적인 목적으로 사용될 수 있기 때문입니다.

"페이지 로드 시간을 늘려 웹 사이트의 성능을 저하시키고 싶지 않습니다"

성능은 사용자 경험과 Google에서 검색 결과를 표시하는 방식 모두에 있어서 중요한 요소입니다. 당연히 대기 시간이 늘어나는 것은 심각하게 고려해야 할 사항입니다. 다행히도 시간이 지남에 따라 HTTPS가 개선되어 암호화된 연결을 설정하는 데 필요한 성능 오버헤드를 줄일 수 있게 되었습니다.

HTTP 연결이 발생할 때는 웹 페이지를 요청하는 클라이언트와 서버 간에 여러 번의 연결이 이루어져야 합니다.HTTPS를 사용하려면 TCP 핸드셰이크(아래 파란색으로 표시)와 관련된 일반적인 대기 시간 외에도 추가 TLS/SSL 핸드셰이크(노란색 표시)가 발생해야 합니다.

TLS 세션 재개 및 TLS 잘못된 시작을 포함하여 연결 생성의 총 대기 시간을 줄이기 위해 TLS에 개선 사항이 구현되었습니다.

세션 재시작을 사용하면 서버가 추가 요청에 대해 동일한 세션을 다시 시작하여 연결을 더 오래 유지할 수 있습니다. 연결을 유지하면 클라이언트가 캐시되지 않은 원본 가져오기를 요구할 때 연결을 다시 협상하는 데 소요되는 시간이 절약되므로 총 RTT가 50% 감소합니다.

암호화된 채널을 생성하는 속도를 개선하는 또 다른 방법은 클라이언트가 인증을 완료하기 전에 암호화된 데이터를 전송하여 대기 시간을 단축하는 TLS 폴스 스타트라는 프로세스를 구현하는 것입니다. 자세히 알아보려면 CDN에서 TLS/SSL이 작동하는 방법을 살펴보세요.

마지막으로, TLS 1.3을 사용하면 성능이 훨씬 더 향상됩니다. TLS 1.3의 TLS 핸드셰이크에는 왕복 1회만 필요하며, 클라이언트가 이전에 연결한 적이 있는 경우, 필요한 왕복 횟수는 0입니다. Cloudflare에 가입하면 웹 자산에 대해 TLS 1.3을 쉽게 활성화할 수 있습니다.

"HTTPS를 구현하려면 비용이 너무 많이 듭니다"

한때는 이것이 사실이었을지 모르지만, 이제는 더 이상 비용이 걱정되지 않습니다. Cloudflare에서는 웹 사이트에 무료로 전송을 암호화하는 기능을 제공합니다. 당사는 최초로 SSL을 무료로 제공했으며, 지금도 계속 제공하고 있습니다. 우리는 인터넷 보안을 전반적으로 개선함으로써 인터넷을 더 안전하고 빠르게 만드는 데 도움을 줄 수 있습니다.

"사이트를 HTTPS로 마이그레이션하는 동안 검색 순위가 떨어질 것입니다"

웹 사이트 마이그레이션에는 위험이 따르며, 부적절하게 마이그레이션하면 SEO에 부정적인 영향이 미칠 수 있습니다. 잠재적인 위험으로는 웹 사이트 다운타임, 크롤링되지 않은 웹 페이지, 두 개의 사이트 복사본이 동시에 존재하는 경우 콘텐츠 중복으로 인한 불이익 등이 있습니다. 하지만 모범 사례를 따르면 웹 사이트를 HTTPS로 안전하게 마이그레이션할 수 있습니다.

가장 중요한 마이그레이션 관행은 두 가지입니다.

1) {301 리디렉션 사용 및 2) 표준 태그의 적절한 배치. HTTP 사이트에서 서버 301 리디렉션을 사용하여 HTTPS 버전을 가리키도록 하면 웹 사이트에서는 모든 검색 및 인덱싱 목적을 위해 새 위치로 이동하도록 Google에 알립니다. HTTPS 사이트에만 표준 태그를 배치하면 Googlebot과 같은 크롤러는 새로운 보안 콘텐츠가 앞으로 표준 콘텐츠로 간주되어야 한다는 것을 알 수 있습니다.

페이지 수가 많아 다시 크롤링하는 데 시간이 너무 오래 걸릴까 걱정된다면 Google에 연락하여 웹 사이트에 얼마나 많은 트래픽을 처리할 것인지 알려주세요. 그러면 네트워크 엔지니어가 크롤링 속도를 높여 사이트를 빠르게 구문 분석하고 색인화하도록 지원합니다.