HTTPS가 HTTP보다 더 안전한 이유는 무엇입니까?

머리말

최근 몇 년 동안 인터넷은 엄청난 변화를 겪었습니다. 특히 우리가 익숙했던 HTTP 프로토콜은 점차 브라우저, 검색 엔진으로 대체되고 있습니다. , CA 기관, 대형 인터넷 회사의 공동 추진으로 인터넷은 "HTTPS 암호화 시대"를 열었습니다. HTTPS는 HTTP를 완전히 대체하고 향후 몇 년 내에 주류 전송 프로토콜이 될 것입니다.

이 기사를 읽고 나면 다음 내용을 이해할 수 있기를 바랍니다.

HTTP 통신의 문제점은 무엇입니까?

HTTP는 HTTP를 어떻게 개선합니까?

HTTPS는 어떻게 작동합니까? 1. HTTPS란

HTTPS는 HTTP에 SSL 암호화 계층이 구축되어 전송되는 데이터가 암호화되는 HTTP 프로토콜의 보안 버전입니다. 이제 거래 결제와 같이 World Wide Web에서 보안에 민감한 통신에 널리 사용됩니다.

HTTPS의 주요 기능은 다음과 같습니다.

(1) 데이터를 암호화하고 정보 보안 채널을 설정하여 전송 중 데이터 보안을 보장합니다.

(2) 웹사이트 서버에서 실제 신원 인증을 수행합니다.

우리는 웹 로그인 페이지와 쇼핑 결제 인터페이스에서 HTTPS 통신을 자주 사용합니다. HTTPS 통신을 사용하는 경우 http://는 더 이상 사용되지 않지만 대신 https://가 사용됩니다. 또한, 브라우저가 유효한 HTTPS 통신을 통해 웹사이트에 접속하면 브라우저의 주소 표시줄에 잠긴 표시가 나타납니다. HTTPS가 표시되는 방식은 브라우저에 따라 다릅니다.

2. HTTPS가 필요한 이유

HTTP 프로토콜에는 정보 도용이나 신원 위장 등의 보안 문제가 있을 수 있습니다. HTTPS 통신 메커니즘을 사용하면 이러한 문제를 효과적으로 방지할 수 있습니다. 다음으로 먼저 HTTP 프로토콜의 문제점을 이해해 보겠습니다.

통신은 암호화되지 않은 일반 텍스트를 사용하므로 내용이 도청될 수 있습니다.

HTTP 자체에는 암호화가 없습니다. 기능이므로 전체 통신(HTTP 프로토콜을 사용하여 전달되는 요청 및 응답 내용)을 암호화하는 것은 불가능합니다. 즉, HTTP 메시지는 일반 텍스트(암호화되지 않은 메시지 참조)로 전송됩니다.

HTTP 일반 텍스트 프로토콜의 결함은 데이터 유출, 데이터 변조, 트래픽 하이재킹, 피싱 공격 등의 보안 문제의 중요한 원인입니다. HTTP 프로토콜은 데이터를 암호화할 수 없으며 모든 통신 데이터는 네트워크에서 일반 텍스트로 "알몸으로 실행"됩니다. 네트워크 스니핑 장비와 일부 기술적 수단을 통해 HTTP 메시지의 내용을 복원할 수 있습니다.

메시지의 무결성은 입증할 수 없으므로 변조될 수 있습니다.

무결성이란 정보의 정확성을 의미합니다. 완전성을 입증하지 못한다는 것은 일반적으로 정보가 정확한지 판단할 수 없다는 것을 의미합니다. HTTP 프로토콜은 통신 메시지의 무결성을 증명할 수 없기 때문에 요청 또는 응답을 보낸 후 상대방이 이를 수신할 때까지 해당 요청 또는 응답의 내용이 변조되었는지 알 수 없습니다. . 즉, 보낸 요청/응답과 받은 요청/응답이 동일한지 확인할 방법이 없습니다.

통신 당사자의 신원을 확인하지 않으므로 위장이 발생할 수 있습니다.

HTTP 프로토콜의 요청 및 응답은 통신 당사자를 확인하지 않습니다. HTTP 프로토콜 통신 중에는 통신 당사자를 확인하는 처리 단계가 없으므로 누구나 요청을 시작할 수 있습니다. 또한 서버가 요청을 수신하는 한 상대방이 누구인지에 관계없이 응답을 반환합니다(단, 보낸 사람의 IP 주소와 포트 번호가 웹 서버에 의해 제한되지 않는 경우에만 해당)

HTTP 프로토콜 통신 당사자의 신원을 확인할 수 없습니다. 누구나 가짜 서버를 위조하여 사용자를 속이고 사용자가 이를 감지할 수 없는 상태에서 "피싱 사기"를 당할 수 있습니다.

반대로, HTTPS 프로토콜은 HTTP 프로토콜에 비해 다음과 같은 장점이 있습니다(아래에 자세히 설명).

데이터 개인 정보 보호: 콘텐츠는 대칭적으로 암호화되며 각 연결은 고유한 암호화 키를 생성합니다.

데이터 무결성: 콘텐츠 전송은 무결성 확인을 거칩니다.

신원 인증: 제3자는 서버(클라이언트)의 신원을 위조할 수 없습니다

3. HTTPS는 위의 HTTP 문제를 어떻게 해결합니까?

HTTPS는 애플리케이션 계층의 새로운 프로토콜이 아닙니다. HTTP 통신 인터페이스 부분만 SSL 및 TLS 프로토콜로 대체됩니다.

일반적으로 HTTP는 TCP와 직접 통신합니다. SSL을 사용하게 되면 먼저 SSL과 통신하고, 그 다음 SSL이 TCP와 통신하도록 진화합니다. 즉, 소위 HTTPS는 실제로 SSL 프로토콜의 셸에 HTTP로 포장된 것입니다.

SSL을 채택한 후 HTTP는 HTTPS의 암호화, 인증서 및 무결성 보호 기능을 갖게 됩니다. 즉, HTTP에 암호화 처리, 인증, 무결성 보호를 더한 것이 HTTPS입니다.

HTTPS 프로토콜의 주요 기능은 기본적으로 TLS/SSL 프로토콜에 의존합니다. TLS/SSL의 기능 구현은 주로 해시 함수, 대칭 암호화 및 비대칭 암호화의 세 가지 유형에 의존합니다. 이는 신원을 달성하기 위해 비대칭 암호화를 사용합니다. 인증 및 키 협상, 대칭 암호화 알고리즘은 협상된 키를 사용하여 데이터를 암호화하고 해시 함수를 기반으로 정보의 무결성을 확인합니다.

1. 콘텐츠가 도청될 수 있는 문제 해결 - 암호화

방법 1. 대칭 암호화

이 방법은 암호화와 복호화에 동일한 키를 사용합니다. 키는 암호화 및 복호화에 사용됩니다. 비밀번호는 키 없이는 복호화할 수 없으며, 반대로 키가 있는 사람은 누구나 비밀번호를 복호화할 수 있습니다.

대칭 암호화를 사용하여 암호화하는 경우 키를 상대방에게도 전송해야 합니다. 그런데 어떻게 안전하게 옮길 수 있을까요? 키가 인터넷을 통해 전달될 때 통신이 도청되면 키가 공격자의 손에 넘어갈 수 있으며 암호화 목적이 상실됩니다. 또한, 받은 키를 안전하게 보관할 수 있는 방법도 찾아야 합니다.

방법 2. 비대칭 암호화

공개키 암호화는 한 쌍의 비대칭 키를 사용합니다. 하나는 개인 키라고 하고 다른 하나는 공개 키라고 합니다. 이름에서 알 수 있듯이 개인 키는 다른 사람에게 알 수 없지만 공개 키는 누구나 자유롭게 공개하고 사용할 수 있습니다.

공개 키 암호화를 사용하면 암호문을 보내는 당사자는 상대방의 공개 키를 사용하여 암호화합니다. 상대방은 암호화된 정보를 받은 후 자신의 개인 키를 사용하여 해독합니다. 이렇게 하면 복호화에 사용되는 개인 키를 보낼 필요가 없고, 공격자가 키를 도청하거나 도난당할 염려도 없습니다.

비대칭 암호화는 일대다 정보 전송이 특징입니다. 서버는 여러 클라이언트와 암호화된 통신을 위해 하나의 개인 키만 유지하면 됩니다.

이 방법에는 다음과 같은 단점이 있습니다.

공개 키는 공개되어 있으므로 개인 키로 암호화된 정보를 가로채면 해커가 공개 키를 사용하여 콘텐츠를 해독하고 얻을 수 있습니다. 서버의 정보는 비대칭 암호화 알고리즘을 사용하여 서버 신원의 정당성을 보장할 수 없으며, 서버가 클라이언트에 전송한 공개 키를 중간자 공격의 위험이 있습니다.

비대칭 암호화를 사용하려면 데이터 암호화 및 복호화 과정에서 비대칭 암호화를 사용해야 하며 일정 시간이 소요되고 데이터 전송 효율성이 떨어집니다.

방법 3. 대칭 암호화 + 비대칭 암호화 (HTTPS는 이 방식을 사용함)

대칭키를 사용하면 복호화가 빠르다는 장점이 있고, 비대칭키를 사용하면 전송되는 내용을 해독할 수 없다는 장점이 있습니다. 해당 개인 키 없이 콘텐츠를 크랙합니다. 예를 들어, 금고를 잡았지만 금고의 열쇠 없이는 금고를 열 수 없습니다. 그런 다음 대칭 암호화와 비대칭 암호화를 결합하여 각각의 장점을 최대한 활용하고 키 교환 단계에서 비대칭 암호화를 사용하고 후속 통신 및 메시지 교환 단계에서 대칭 암호화를 사용합니다.

구체적인 방법은 다음과 같습니다. 암호문을 보내는 당사자는 상대방의 공개 키를 사용하여 "대칭 키"를 암호화하고, 상대방은 자신의 개인 키를 사용하여 "대칭 키"를 해독하고 획득하여 교환을 보장합니다. 키 보안을 전제로 통신에는 대칭 암호화가 사용됩니다. 따라서 HTTPS는 대칭 암호화와 비대칭 암호화를 모두 사용하는 하이브리드 암호화 메커니즘을 사용합니다.

2. 메시지 변조 가능성 문제 해결 - 디지털 서명

네트워크 전송 과정에서 데이터가 해독될 수는 없지만 변조될 수 있으므로 이를 확인하는 방법은 무엇입니까? 데이터의 무결성? ----디지털 서명을 확인합니다.

디지털 서명에는 두 가지 기능이 있습니다.

다른 사람이 보낸 사람의 서명을 위조할 수 없기 때문에 메시지가 보낸 사람이 실제로 서명하고 보낸 것인지 확인할 수 있습니다.

디지털 서명은 메시지의 무결성을 확인하고 데이터가 변조되지 않았는지 여부를 증명할 수 있습니다.

디지털 서명을 생성하는 방법:

해시 함수를 사용하여 텍스트 조각의 메시지 다이제스트를 생성한 다음 보낸 사람의 개인 키로 암호화하여 디지털 서명을 생성하고 수신자에게 함께 보냅니다. 원본 텍스트와 함께. 다음 단계는 수신자가 디지털 서명을 확인하는 과정입니다.

전자 서명 확인 과정:

수신자는 보낸 사람의 공개 키를 사용하여 암호화된 요약 정보를 해독할 수 있으며, 그런 다음 HASH 기능을 사용하여 수신된 원본 텍스트에 대한 요약 정보를 생성할 수 있습니다. 이전 단계에서 얻은 요약 정보 비교. 동일하다면 수신된 정보가 완전하고 전송 과정에서 수정되지 않았음을 의미하며, 그렇지 않으면 정보가 수정되었으므로 디지털 서명을 통해 정보의 무결성을 확인할 수 있습니다.

Kobe와 James 사이에 메시지 전달이 발생한다고 가정합니다. James는 디지털 서명과 함께 메시지를 Kobe에 보냅니다. Kobe는 메시지를 받은 후 디지털 서명을 확인하여 수신된 메시지가 James가 보낸 것인지 확인할 수 있습니다. 물론 이 프로세스의 전제는 Kobe가 James의 공개 키를 알고 있다는 것입니다. 문제의 핵심은 메시지 자체와 마찬가지로 공개 키가 보안되지 않은 네트워크를 통해 Kobe에 직접 전송될 수 없거나 획득한 공개 키가 James의 것임을 증명하는 방법입니다.

이번에는 인증 기관(CA)을 도입해야 합니다. Kobe 클라이언트에는 신뢰할 수 있는 모든 CA의 인증서가 내장되어 있습니다. CA는 James의 공개 키(및 기타 정보)를 디지털 방식으로 서명한 후 인증서를 생성합니다.

3. 통신 당사자의 신원이 위장될 수 있는 문제 해결 - 디지털 인증서

디지털 인증서 인증 기관은 클라이언트와 서버 모두에게 신뢰할 수 있는 제3자 기관입니다.

전자인증기관의 업무 프로세스를 소개하겠습니다.

서버 운영자는 공개키, 조직 정보, 개인정보(도메인 이름) 및 기타 정보를 제3자 기관 CA에 제출하고 신청합니다.

인증;

CA는 조직의 존재 여부, 해당 기업의 합법성 여부, 도메인 이름 보유 여부 등 온라인, 오프라인 등 다양한 수단을 통해 신청자가 제공한 정보의 진위 여부를 확인합니다.

정보가 다음과 같은 경우; 검토 및 승인을 받은 후 CA는 신청자에게 인증서를 발급합니다. 인증 문서 - 인증서. 인증서에는 신청자의 공개 키, 신청자의 조직 정보 및 개인 정보, 발급 기관 CA 정보, 유효 기간, 인증서 일련 번호 및 기타 정보가 일반 텍스트로 포함되어 있으며 서명도 포함되어 있습니다. 서명 생성 알고리즘: 먼저 해시 함수를 사용하여 공개 일반 텍스트 정보의 정보 다이제스트를 계산한 다음 CA의 개인 키를 사용하여 정보 다이제스트를 암호화하고 암호문이 서명입니다.

클라이언트가 요청을 보낼 때 서버는 인증서 파일을 서버로 반환합니다.

클라이언트는 인증서의 관련 일반 텍스트 정보를 읽고 동일한 해시 함수를 사용하여 정보 요약을 계산한 다음 해당 CA의 공개 키를 사용하여 서명 데이터를 해독합니다. 인증서의 정보 요약을 비교하여 일관성이 있으면 인증서의 적법성, 즉 서버의 공개 키를 신뢰할 수 있음을 확인할 수 있습니다.

클라이언트는 인증서와 관련된 도메인 이름 정보, 유효 기간 및 기타 정보도 확인합니다. CA가 신뢰할 수 없는 경우 해당 CA 인증서가 내장된 신뢰 CA 인증서 정보를 갖게 됩니다. 찾을 수 없으며 인증서도 불법으로 간주됩니다.

4. HTTPS 워크플로

1. 클라이언트는 RFC2818에 따라 HTTPS(예: https://juejin.im/user) 요청을 시작합니다. 443(기본) 포트에 연결해야 합니다. 서버의.

2. 서버는 미리 구성된 공개 키 인증서를 클라이언트에 반환합니다.

3. 클라이언트는 공개 키 인증서를 확인합니다. 예를 들어 유효 기간 내에 있는지, 인증서의 목적이 클라이언트가 요청한 사이트와 일치하는지, CRL 해지 목록에 있는지, 상위 수준인지 여부를 확인합니다. 인증서가 유효하면 이는 루트 인증서(운영 체제에 내장된 루트 인증서 또는 클라이언트에 내장된 루트 인증서)가 확인될 때까지 반복적인 프로세스입니다. 확인이 통과되면 계속 진행하세요. 그렇지 않으면 경고 메시지가 표시됩니다.

4.클라이언트는 의사 난수 생성기를 사용하여 암호화에 사용되는 대칭 키를 생성한 다음 인증서의 공개 키로 대칭 키를 암호화하여 서버로 보냅니다.

5. 서버는 자체 개인 키를 사용하여 메시지를 해독하고 대칭 키를 얻습니다. 이 시점에서 클라이언트와 서버는 모두 동일한 대칭 키를 보유합니다.

6. 서버는 대칭 키를 사용하여 "일반 텍스트 콘텐츠 A"를 암호화하여 클라이언트에 보냅니다.

7.클라이언트는 대칭 키를 사용하여 응답의 암호문을 해독하고 "일반 텍스트 콘텐츠 A"를 얻습니다.

8 클라이언트는 요청된 "일반 텍스트 콘텐츠 B"를 암호화하기 위해 대칭 키를 사용하여 HTTPS 요청을 다시 시작합니다. 그런 다음 서버는 대칭 키를 사용하여 암호 텍스트를 해독하고 "일반 텍스트 콘텐츠 B"를 얻습니다.

5 HTTP와 HTTPS의 차이점

HTTP는 일반 텍스트 전송 프로토콜인 반면, HTTPS 프로토콜은 암호화된 전송 및 신원 인증을 수행할 수 있는 SSL+HTTP 프로토콜로 구축된 네트워크 프로토콜이며 HTTP보다 안전합니다. 규약.

보안과 관련하여 둘 사이의 관계를 설명하는 가장 간단한 비유는 트럭이 상품을 운송한다는 것입니다. HTTP 하의 트럭은 개방형이며 상품이 노출되어 있습니다. 그리고 https는 폐쇄형 컨테이너 트럭이기 때문에 당연히 보안이 많이 향상됩니다.

HTTPS는 HTTP보다 더 안전하고 검색 엔진에 더 적합하며 Google과 Baidu는 HTTPS 웹 페이지 색인을 선호합니다.

HTTPS에는 SSL 인증서가 필요하지만 HTTP에는

HTTPS 표준 포트 443이 없습니다. , HTTP 표준 포트 80;

HTTPS는 전송 계층을 기반으로 하고 HTTP는 애플리케이션 계층을 기반으로 합니다.

HTTPS는 브라우저에 녹색 보안 잠금 장치를 표시하지만 HTTP는 그렇지 않습니다.

6. 웹사이트는 HTTPS를 사용합니다

HTTPS는 매우 안전하고 신뢰할 수 있는데 왜 모든 웹사이트에서는 HTTPS를 사용하지 않는 걸까요?

우선, 아직도 많은 사람들이 HTTPS 구현에 임계값이 있다고 생각합니다. 이 임계값은 권한 있는 CA에서 발급한 SSL 인증서가 필요하기 때문입니다. 인증서 선택부터 구매, 배포까지 기존 모델은 시간이 더 많이 걸리고 노동 집약적입니다.

둘째, 암호화된 통신은 일반 텍스트 통신보다 더 많은 CPU 및 메모리 리소스를 소비하기 때문에 일반적으로 HTTPS는 HTTP보다 성능 소모가 더 높다고 알려져 있습니다. 각 통신을 암호화하면 많은 리소스가 소모되며, 단일 컴퓨터에 분산되면 처리할 수 있는 요청 수가 필연적으로 줄어들게 됩니다. 하지만 그렇지 않습니다. 사용자는 성능을 최적화하고 SLB 또는 CDN에 인증서를 배포하여 이 문제를 해결할 수 있습니다. 실제적인 예를 들면, 'Double Eleven' 기간 동안 Taobao와 Tmall은 전체 사이트에 HTTPS를 사용하여 웹사이트와 모바일 단말기에서 여전히 원활한 액세스, 탐색, 거래 및 기타 운영을 보장했습니다. 테스트를 통해 최적화된 많은 페이지의 성능이 HTTP와 동일하거나 약간 향상되었으므로 실제로 최적화 후에도 HTTPS가 느리지 않은 것으로 나타났습니다.

그리고 인증서 구매 비용을 아끼고 싶은 것도 이유 중 하나입니다. HTTPS 통신을 활성화하려면 인증서가 필수입니다. 사용되는 인증서는 CA(인증 기관)에서 구입해야 합니다.

마지막으로 안전의식입니다. 중국에 비해 외국 인터넷 산업의 보안 인식과 기술 적용은 상대적으로 성숙했으며, HTTPS 배포 추세는 사회, 기업, 정부가 공동으로 추진하고 있습니다.

위 내용은 HTTPS가 HTTP보다 더 안전한 이유는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!