HTTPS는 어떻게 웹 보안을 보장하나요? (코드 예)

이 기사의 내용은 HTTPS가 웹 보안을 어떻게 보장하는지에 관한 것입니다. (코드 샘플)에는 특정 참조 값이 있습니다. 도움이 필요한 친구가 참조할 수 있기를 바랍니다.

HTTPS(전체 이름: HyperText Transfer Protocol over Secure Socket Layer)는 클라이언트와 서버 간의 데이터 전송 보안을 보장하기 위한 것입니다. 지난 2년 동안 구글, 바이두, 페이스북 등 거대 인터넷 기업들이 HTTPS를 적극적으로 홍보하기 시작했으며, 국내외 많은 대형 인터넷 기업들도 풀사이트 HTTPS를 활성화하고 있다. 이는 향후 인터넷 발전 추세이기도 하다. 프론트엔드 엔지니어에게는 HTTPS의 원리를 이해하는 것도 필수 과정입니다.
2019년은 전체 네트워크에서 HTTPS를 사용할 날이 머지 않았습니다. 다음은 HTTPS 사용을 권장하기 위해 주요 인터넷 회사가 제시한 몇 가지 요구 사항입니다.
1. Google의 검색 엔진 알고리즘은 HTTPS를 사용하는 웹사이트의 순위를 높일 수 있습니다.
2. Apple은 App Store의 모든 애플리케이션이 HTTPS 암호화 연결을 사용해야 함을 요구합니다.
3. WeChat 애플릿도 HTTPS 프로토콜을 사용해야 합니다. HTTPS
5. Chrome의 새 버전은 HTTP 프로토콜 웹사이트를
unsafe

숨겨진 위험: HTTP에 S를 추가하는 이유는 무엇입니까?

HTTP 프로토콜은 탄생부터 매우 훌륭하고 편리합니다. 그러나 HTTP는 좋은 면만 있는 것은 아닙니다. 모든 면에서 단점도 분명합니다.

• 통신은 일반 텍스트 전송을 사용하며 내용은 다음과 같습니다. 도청됩니다

• 통신 당사자의 신원이 확인되지 않아 가장할 수 있습니다

• 메시지의 무결성을 입증할 수 없으므로 변조되었을 수 있습니다

또한 HTTP 자체 많은 단점이 있습니다. 또한, 특정 특정 웹 서버 및 특정 웹 브라우저의 실제 애플리케이션에는 결함(취약성 또는 보안 허점이라고도 할 수 있음)이 있을 수 있습니다. 또한, Java 및 PHP와 같은 프로그래밍 언어로 개발된 웹 애플리케이션도 있을 수 있습니다. 보안상 취약할 수도 있습니다.

1. 일반 텍스트를 사용한 통신은 도청될 수 있습니다

HTTP 자체에는 암호화 기능이 없으므로 전체 통신(HTTP 프로토콜을 사용하여 전달되는 요청 및 응답 내용)을 암호화하는 것은 불가능합니다. 따라서 HTTP 메시지는 일반 텍스트로 전송됩니다. 통신을 암호화하지 않는 것이 단점인 이유를 묻는다면 TCP/IP 프로토콜 제품군의 작동 메커니즘에 따라 통신 내용이 모든 통신 회선에서 엿볼 수 있기 때문입니다.

소위 인터넷은 전 세계 어디에서나 서버가 클라이언트와 통신할 수 있는 네트워크로 구성되어 있으며, 이 통신 회선에서는 특정 네트워크 장비, 광케이블, 컴퓨터 등이 연결될 수 없습니다. 개인에게만 공개되므로 특정 링크에서 악의적인 엿보기가 발생할 가능성도 배제할 수 없습니다.
통신이 암호화되어 있어도 통신 내용은 엿볼 수 있으며 이는 암호화되지 않은 통신과 동일합니다. 이는 통신이 암호화되면 메시지 정보의 의미를 해독하는 것이 불가능할 수 있지만 암호화된 메시지 자체는 계속 볼 수 있다는 의미입니다.
같은 구간의 통신을 도청하는 것은 어렵지 않습니다. 인터넷에 흐르는 데이터 패킷을 수집하면 됩니다. 수집된 데이터 패킷의 분석은 패킷 캡처 또는 스니핑 도구에 맡길 수 있습니다.

2. 통신 당사자의 신원을 확인하지 못하면 스푸핑이 발생할 수 있습니다

HTTP 프로토콜의 요청과 응답은 통신 당사자를 확인하지 않습니다. 즉, "서버가 실제로 요청의 URI로 지정된 호스트인지, 반환된 응답이 실제로 요청을 한 클라이언트에 실제로 반환되는지 여부"와 같은 유사한 문제가 있습니다.

HTTP 프로토콜 통신 중에는 통신 당사자를 확인하는 처리 단계가 없기 때문에 서버가 요청을 수신하는 한 보낸 사람의 IP 주소와 포트 번호만 있으면 누구나 동시에 요청을 보낼 수 있습니다. 웹 서버에 의해 제한되지 않으므로 상대방이 누구인지에 관계없이 응답이 반환되므로 다양한 숨겨진 위험이 있습니다.

• 웹 서버가 요청은 실제 의도에 따라 응답을 반환하는 서버로 위장된 웹 서버일 수 있습니다.

• 응답으로 반환된 클라이언트가 실제 의도에 따라 응답을 받은 클라이언트인지 여부는 확인이 불가능합니다.

• 통신 중인 상대방에게 접근 권한이 있는지 확인할 수 없습니다. 일부 웹 서버는 특정 사용자에게 전송되는 통신에 대한 권한을 가리키는 중요한 정보를 저장하기 때문입니다.

• 요청이 어디서 왔는지, 누가 요청했는지 파악하는 것은 불가능합니다.

• 시기적절하고 의미없는 요청은 전액 수락됩니다. 대규모 요청 시 DoS 공격(서비스 거부, 서비스 거부 공격)을 방지할 수 없습니다.

3. 메시지의 무결성을 입증할 수 없으며 변조되었을 수 있습니다

소위 완전성이란 정보의 정확성을 의미합니다. 완전성을 입증하지 못한다는 것은 일반적으로 정보가 정확한지 판단할 수 없다는 것을 의미합니다.
따라서, 요청 또는 응답이 전송된 후 상대방이 이를 수신한 것으로 알려진 기간 동안 해당 요청 또는 해당 내용이 변조되었더라도 이를 알 수 있는 방법이 없습니다.
즉, 보낸 요청 및 응답이 받은 요청 및 응답과 동일한지 확인할 방법이 없습니다. 전송 중에 파일 내용이 다른 내용으로 변경되었을 수 있습니다. 이 경우 전송 중에 공격자가 요청이나 응답을 가로채서 내용을 변조하는 공격을 중간자 공격(MITM)이라고 합니다. ).

해결책: HTTP + 암호화 + 인증 + 무결성 보호 = HTTPS

위에서 언급한 HTTP의 많은 단점으로 인해 당연히 HTTPS에서 이를 해결해야 합니다. HTTPS가 데이터 전송의 보안을 어떻게 보장하는지 살펴보겠습니다. .

1. HTTPS는 실제로 SSL 셸에서 HTTP입니다.

HTTPS는 애플리케이션 계층의 새로운 프로토콜이 아닙니다. HTTP 통신 인터페이스 부분은 SSL(Secure Socket Layer) 및 TLS(Transport Layer Security) 프로토콜로 대체됩니다.
일반적으로 HTTP는 TCP와 직접 통신합니다. SSL을 사용하면 먼저 SSL과 통신하게 되고, 그 다음 SSL이 TCP와 통신하게 됩니다. 간단히 말해서 SSL과 함께 사용되는 HTTP를 HTTPS(HTTP Secure, Hypertext Transfer Security Protocol) 또는 SSL을 통한 HTTP라고 합니다.
SSL을 채택한 후 HTTP는 HTTPS의 암호화, 인증서 및 무결성 보호 기능을 갖습니다. SSL은 HTTP와 독립적인 프로토콜이므로 HTTP 프로토콜뿐만 아니라 응용 프로그램 계층에서 실행되는 SMTP, Telnet과 같은 다른 프로토콜도 SSL 프로토콜과 함께 사용할 수 있습니다. SSL은 오늘날 세계에서 가장 널리 사용되는 네트워크 보안 기술이라고 할 수 있습니다.

HTTPS의 암호화 원칙

현대 암호화 알고리즘에서 암호화 알고리즘은 공개되고 키는 기밀입니다. 이러한 방식으로 암호화 방법의 보안이 유지됩니다.

암호화 및 복호화에는 키가 필요합니다. 키가 없으면 비밀번호를 복호화할 방법이 없습니다. 즉, 키를 가진 사람은 누구나 암호문을 해독할 수 있습니다.

HTTPS는 암호화 과정에서 비대칭 암호화 기술과 대칭 암호화 기술을 사용합니다.

대칭 암호화 알고리즘

은 단일 키 암호화 시스템의 암호화 방법을 채택합니다. 이 암호화 방법을 대칭 암호화라고 하며 단일 키 암호화라고도 합니다.

대칭 암호화 알고리즘을 이하에서는 공유키 암호화 알고리즘이라 부르겠습니다.

이제 SSL이 통신 프로세스 중에 대칭 암호화 알고리즘을 사용한다고 가정해 보겠습니다. 이는 클라이언트와 서버가 동시에 키를 공유한다는 의미입니다.

그러므로 공유키로 암호화하려면 상대방에게 키를 보내야 합니다. 이때 통신과정을 감시하여 공격자가 키를 획득하게 되면 이때 암호화의 의미는 상실된다.

그럼 이 문제를 해결할 수 있는 방법은 없을까요? 대답은 '예'입니다. 즉, 두 개의 키를 사용합니다.

먼저 두 개의 키를 사용하는 비대칭 암호화 알고리즘을 살펴보겠습니다.

비대칭 암호화 알고리즘

대칭 암호화 알고리즘과 달리 비대칭 암호화 알고리즘은 암호화 및 복호화에 두 개의 키, 즉 공개 키(공개 키)와 개인 키(개인 키)가 필요합니다.

일반적으로 공개 키는 공개할 수 있으며 주로 일반 텍스트를 암호화하는 데 사용됩니다. 따라서 개인 키는 공개할 수 없으며 공개 키로 암호화된 암호문을 해독하는 데 사용됩니다.

공개 키로 암호화된 암호문은 해당 개인 키로만 복호화할 수 있는 반면, 개인 키로 암호화된 암호문은 해당 공개 키로 복호화할 수 있다는 점에 유의할 필요가 있습니다.

위에서 암호화에는 공개키 암호화와 개인키 복호화가 사용되고, 서명에는 개인키 암호화와 공개키 복호화가 사용됩니다. 관련 용도는 나중에 다루겠습니다.

비대칭 암호화 알고리즘을 이하에서는 공개키 암호화 알고리즘이라 칭하겠습니다.

이제 서버가 공개 키와 비밀 키 쌍을 생성한다고 가정합니다.

클라이언트가 처음으로 서버에 협상을 요청하면 서버는 공개 키와 개인 키 쌍을 생성합니다.

그런 다음 서버는 공개 키를 클라이언트에 보냅니다(일반 텍스트, 암호화 필요 없음). 이를 받은 후 클라이언트는 무작위로 키를 생성하고 암호화를 위해 서버에서 보낸 공개 키를 사용합니다.

그런 다음 클라이언트는 공개 키로 암호화된 키를 서버로 보냅니다. 서버는 이를 수신한 후 페어링된 개인 키를 사용하여 이를 해독하고 클라이언트가 무작위로 생성한 키를 얻습니다.

이때 클라이언트와 서버가 보유한 키는 동일합니다. 이 시점에서 키 교환 프로세스가 완료됩니다.

그래서 통신이 시작되면 위에서 설명한 공유키 암호화 방법을 사용하여 암호화할 수 있습니다.

동시에

를 사용할 수 있습니다. 어떤 친구들은 왜 비대칭 암호화를 사용하고 공유 키 암호화 통신을 위해 동일한 키를 얻으려고 애쓰나요?

공개키 암호화는 공유키 암호화보다 처리가 복잡하기 때문에 통신 중 공개키 암호화를 사용하는 효율성은 매우 낮습니다.

그래서 키 공유 과정에서는 키의 보안을 보장하기 위해 비대칭 암호화를 사용하고, 통신 과정에서는 대칭 암호화 알고리즘을 사용하는 것이 보안을 보장하면서 가장 합리적인 설계 방법입니다. 동시에.

따라서 HTTPS는 공유 키 암호화와 공개 키 암호화를 모두 사용하는 하이브리드 암호화 메커니즘을 사용합니다. 공개키 암호화는 키 교환 단계에서 사용되며, 공유키 암호화는 이후의 통신 메시지 교환 단계에서 사용됩니다.

위는 아마도 대칭암호화와 비대칭암호화를 사용하는 과정일 겁니다. 프로세스는 완벽해 보이지만 실제로는 여전히 문제가 있습니다. 서버가 전달한 공개 키의 정확성을 어떻게 보장할 것인가입니다. 즉, 가로채거나 변조할 수 없도록 하기 위한 것입니다.

인증서를 사용하여 공개 키의 정확성을 보장하세요

지금 공개 키 암호화를 사용하여 서버와의 통신 설정을 준비하고 있다면 클라이언트가 받은 공개 키가 원래 예상했던 방식으로 발급되었는지 증명하는 방법 서버는 어떻습니까? 공개 키는 어떻습니까? 아마도 공개 키를 전송하는 동안 공격자가 실제 공개 키를 대체했을 수도 있습니다.

이 문제를 해결하려면 디지털 인증 기관 및 관련 기관에서 발급한 공개 키 인증서를 사용할 수 있습니다.

다음은 디지털 인증서 인증 기관(CA)의 업무 프로세스를 설명합니다.

먼저 서버 운영자가 디지털 인증서 기관에 공개 키를 신청합니다. 전자인증서 인증기관은 신청자의 신원을 확인한 후 신청한 공개키에 전자서명을 한 후, 서명된 공개키를 배포하고, 공개키 인증서에 공개키를 넣어 투게더에 바인딩한다.

위 단락을 현지어로 번역해 보겠습니다.
먼저 CA는 신청자에게 인증서를 발급합니다. 이 인증서의 내용에는 발급자, 인증서의 목적, 서버 애플리케이션에 첨부된 공개 키 및 서버 암호화, 사용된 HASH 알고리즘, 인증서 만료 시간 등
다음으로 위에서 언급한 콘텐츠에 대해 HASH 평가를 수행하여 HASH 값을 얻습니다.

그런 다음 CA의 개인 키를 사용하여 암호화하면 디지털 서명이 완료됩니다. CA의 개인 키로 암호화하면 사람의 지문과 유사한 서명이 생성됩니다. 인증서를 변조하려는 시도는 디지털 서명을 통해 감지됩니다.
마지막으로 디지털 인증서 끝에 디지털 서명을 첨부하여 서버로 다시 전송합니다.
다음으로, 서버는 디지털 인증서 인증기관에서 발급한 공개키 인증서를 클라이언트에게 보냅니다. 이때 클라이언트는 디지털 인증기관의 공개키를 이용하여 이를 검증할 수 있다. 확인이 성공하면 클라이언트는 공개 키가 신뢰할 수 있는지 확인할 수 있습니다.

언어로 번역해 보겠습니다.
클라이언트가 이 디지털 인증서를 받은 후 CA 개인 키에 해당하는 공개 키를 사용하여 디지털 인증서 끝에 있는 디지털 서명을 해독하고 원본 HASH 값을 얻을 수 있습니다.
다음으로 클라이언트는 인증서의 HASH 알고리즘에 따라 인증서 내용에 대한 HASH 값을 계산합니다. CA 공개키로 복호화된 HASH 값이 계산을 통해 얻은 HASH 값과 동일하면 인증에 성공하고, 그렇지 않으면 실패합니다.
인증에 성공하면 서버의 공개키를 획득할 수 있습니다.

그렇다면 클라이언트의 CA 공개 키는 어디서 오는 걸까요?
대부분의 브라우저 개발자는 버전을 출시할 때 일반적으로 사용되는 인증 기관의 공개 키를 내부에 미리 내장합니다. 이런 방식으로 클라이언트는 디지털 인증서의 진위 여부를 확인하는 것이 편리합니다.

구체적인 프로세스는 이렇습니다(그림에서는 디지털 서명의 프로세스를 단순화했습니다).

여기에서는 실제로 비대칭 암호화 알고리즘이 사용되지만 이제는 암호화 대신 서명에 이 암호화 알고리즘이 사용됩니다.

개인키 암호화와 공개키 복호화를 이용하여, 개인키로 암호화된 내용이 변조되었는지 여부를 공개키 보유자를 통해 검증하지만, 그 내용을 타인이 획득했는지 여부를 확인하는 데에는 사용되지 않습니다.

공개 키 암호화와 개인 키 복호화를 사용하는 것은 그 반대입니다. 이는 정보가 다른 사람에 의해 가로채어 변조될 수 있다는 것을 보장하지는 않지만 중개자가 정보를 얻을 수 없다는 것을 보장합니다.

클라이언트 인증서

HTTPS에서는 서버 인증서뿐만 아니라 클라이언트 인증서도 사용할 수 있습니다. 클라이언트 인증에는 서버 인증서와 동일한 기능을 가진 클라이언트 인증서를 사용합니다.

클라이언트가 인증서를 얻기 위해서는 클라이언트 인증서를 설치해야 하기 때문에 비용 문제도 발생합니다.

그래서 현재 상황은 보안이 극도로 높은 인증 기관에서는 클라이언트 인증서를 발급할 수 있지만 특수한 목적의 서비스에 대해서만 가능합니다. 예를 들어 클라이언트 인증서 비용을 지원할 수 있는 기업입니다.

예를 들어 은행의 온라인 뱅킹은 고객 인증서를 사용합니다. 온라인뱅킹 로그인 시, 이용자는 ID와 비밀번호 입력 확인을 요구할 뿐만 아니라, 이용자가 특정 단말기에서 온라인뱅킹 접속 여부를 확인하기 위해 이용자의 고객인증서를 요구합니다.

HTTPS의 안전한 통신 메커니즘

HTTPS를 더 잘 이해하기 위해 Xiaosi는 모든 사람이 HTTPS의 통신 단계를 관찰할 수 있도록 다음 그림을 그렸습니다.

1단계: 클라이언트는 Client Hello 메시지를 보내 SSL 통신을 시작합니다. 메시지에는 클라이언트가 지원하는 지정된 SSL 버전과 암호화 구성 요소 목록(사용된 암호화 알고리즘, 키 길이 등)이 포함되어 있습니다.

2단계: 서버가 SSL 통신을 수행할 수 있으면 Server Hello 메시지로 응답합니다. 클라이언트와 마찬가지로 SSL 버전 및 암호화 구성 요소가 메시지에 포함됩니다. 서버의 암호화 구성 요소 내용은 수신된 클라이언트의 암호화 구성 요소에서 필터링됩니다.

3단계: 그런 다음 서버는 인증서 메시지를 보냅니다. 메시지에는 공개 키 인증서가 포함되어 있습니다.

4단계: 마지막으로 서버는 SSL 핸드셰이크 협상의 초기 단계가 끝났음을 클라이언트에 알리기 위해 Server Hello Done 메시지를 보냅니다.

5단계: 첫 번째 SSL 핸드셰이크가 완료된 후 클라이언트는 클라이언트 키 교환 메시지로 응답합니다. 메시지에는 통신 암호화에 사용되는 Pre-master secret이라는 임의의 비밀번호 문자열이 포함되어 있습니다. 메시지는 3단계의 공개 키로 암호화되었습니다.

6단계: 그런 다음 클라이언트는 계속해서 Change Cipher Spec 메시지를 보냅니다. 이 메시지는 이 메시지 이후의 통신이 사전 마스터 비밀 키를 사용하여 암호화될 것이라는 메시지를 서버에 표시합니다.

7단계: 클라이언트가 완료 메시지를 보냅니다. 이 메시지에는 지금까지 연결된 모든 메시지의 전체 유효성 검사 값이 포함되어 있습니다. 이 핸드셰이크 협상의 성공 여부는 서버가 메시지를 올바르게 해독할 수 있는지 여부에 따라 달라집니다.

8단계: 서버는 Change Cipher Spec 메시지도 보냅니다.

9단계: 서버도 완료 메시지를 보냅니다.

10단계: 서버와 클라이언트 간에 완료 메시지가 교환되면 SSL 연결이 설정됩니다. 물론 통신은 SSL로 보호됩니다. 여기에서 애플리케이션 계층 프로토콜과의 통신, 즉 HTTP 요청 전송이 시작됩니다.

11단계: 애플리케이션 계층 프로토콜 통신, 즉 HTTP 응답 전송.

12단계: 마침내 클라이언트 연결이 끊어집니다. 연결이 끊어지면 close_notify 메시지가 전송됩니다. 위 그림에서는 일부 생략된 부분이 있습니다. 이 단계 이후에는 TCP와의 통신을 종료하기 위해 TCP FIN 메시지가 전송됩니다.

위 프로세스에서 애플리케이션 계층이 데이터를 보낼 때 MAC(Message Authentication Code)라는 메시지 다이제스트가 추가됩니다. MAC은 메시지가 변조되었는지 여부를 확인하여 메시지의 무결성을 보호할 수 있습니다.

이제 질문이 있습니다. 전체 과정에서 생성된 세 개의 난수는 어디에 사용됩니까? 또한 나중에 HTTP 통신을 수행할 때 암호화에 어떤 키가 사용되는지, 메시지의 무결성을 보장하는 방법은 무엇입니까?

아래 사진을 보세요.

클라이언트의 경우:

사전 마스터 비밀을 생성한 후 원래 A와 B 난수를 결합하고 DH 알고리즘을 사용하여 마스터 비밀을 계산한 다음 이를 기반으로 파생합니다. 마스터 비밀 해시 비밀 및 세션 비밀.

서버의 경우:

사전 마스터 비밀을 해독하고 얻은 후 원래 A와 B 난수를 결합하고 DH 알고리즘을 사용하여 마스터 비밀을 계산한 다음 이를 기반으로 해시 비밀과 세션을 파생합니다. 마스터 시크릿 시크릿.

클라이언트와 서버의 마스터 시크릿은 세 개의 난수를 기반으로 파생됩니다. 이는 네트워크에서 전송되지 않으며, 제3자도 이를 알 수 없습니다. 동시에 클라이언트가 파생한 세션 비밀과 해시 비밀은 서버의 비밀과 정확히 동일합니다.

이제 두 당사자가 대칭 알고리즘 암호화를 사용하여 통신하기 시작하면 어느 것이 공유 키로 사용됩니까? 프로세스는 다음과 같습니다.

양 당사자는 대칭 암호화 알고리즘을 사용하여 암호화하고 해시 비밀을 사용하여 HTTP 메시지에 대한 작업을 수행하여 MAC을 생성하고 이를 HTTP 메시지 뒷면에 첨부한 다음 세션 비밀을 사용합니다. 모든 데이터를 암호화(HTTP+MAC)한 후 전송합니다.

수신자는 먼저 세션 비밀을 사용하여 데이터를 해독한 다음 HTTP+MAC를 얻은 다음 동일한 알고리즘을 사용하여 자체 MAC을 계산합니다. 두 MAC가 동일하면 데이터가 변조되지 않았음을 증명합니다.

이제 전체 과정이 소개되었습니다.

위 내용은 HTTPS는 어떻게 웹 보안을 보장하나요? (코드 예)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!