HTTPS 통신의 원리는 무엇입니까?

HTTPS 통신 원칙은 다음과 같습니다. HTTPS는 "SSL/TLS를 통한 HTTP"입니다. HTTPS에는 HTTP에 비해 추가 "SSL/TLS" 계층이 있습니다. HTTPS는 데이터를 전송하기 전에 클라이언트와 서버 간의 핸드셰이크를 요구합니다. 이 프로세스를 통해 전송된 데이터를 암호화하기 위해 양 당사자가 사용하는 암호화 정보가 설정됩니다.

소개:

HTTP 프로토콜(HyperText Transfer Protocol, Hypertext Transfer Protocol): 클라이언트 브라우저나 다른 프로그램과 웹 서버 간의 애플리케이션 계층 통신 프로토콜입니다. HTTPS(전체 이름: HyperText Transfer Protocol over Secure Socket Layer)는 HTTP+SSL/TLS로 이해될 수 있습니다. 즉, HTTP에 SSL 레이어가 추가된 것입니다. HTTPS의 보안 기반은 SSL이므로 암호화 세부 사항에는 SSL이 필요합니다. 안전한 HTTP 데이터 전송.

HTTPS와 HTTP의 차이점:

a. https 프로토콜을 사용하려면 CA에서 인증서를 신청해야 합니다. 일반적으로 무료 인증서가 거의 없으며 수수료를 지불해야 합니다.

b. http는 하이퍼텍스트 전송 프로토콜이며 정보는 일반 텍스트로 전송됩니다. https는 안전한 SSL 암호화 전송 프로토콜입니다.

c. http와 https는 완전히 다른 연결 방법을 사용하고 다른 포트를 사용합니다. 전자는 80이고 후자는 443입니다.

d. http 연결은 매우 간단하고 상태가 없습니다. HTTPS 프로토콜은 암호화된 전송 및 ID 인증을 수행할 수 있는 SSL+HTTP 프로토콜로 구축된 네트워크 프로토콜이며 http 프로토콜보다 더 안전합니다.

HTTPS의 역할

주요 역할은 두 가지로 나눌 수 있습니다. 하나는 정보 보안 채널을 구축하여 데이터 전송의 보안을 보장하는 것이고, 다른 하나는 웹사이트의 신뢰성을 확인하는 것입니다.

　 ㅇ. 일반적인 의미에서 https는 서버에 인증서가 있음을 의미합니다. 주요 목적은 서버가 자신이 주장하는 서버인지 확인하는 것입니다. 이는 서버와 클라이언트 간의 모든 통신이 암호화된다는 점입니다.

b. 구체적으로 클라이언트는 대칭 키를 생성하고 서버의 인증서를 통해 키를 교환하는데 이는 일반적인 의미의 핸드셰이크 프로세스입니다. 이 부분은 아래에서 자세히 소개하겠습니다.

　 c. 이후의 모든 정보 교환은 암호화됩니다. 제3자가 가로채더라도 그 사람은 열쇠가 없기 때문에 의미가 없고, 당연히 함부로 조작할 이유도 없습니다.

　d． 클라이언트에 대한 요구 사항이 있는 경우에는 클라이언트에도 인증서가 있어야 합니다.

HTTPS 프로토콜이 필요한 이유:

HTTP 프로토콜은 암호화되지 않은 일반 텍스트 전송 프로토콜입니다. 클라이언트(APP, 브라우저)가 HTTP를 사용하여 데이터를 전송하는 경우 전송 내용이 유출되어 탈취될 수 있습니다. 중개인과 수정된 콘텐츠. 아래 그림과 같이 일반적인 APP HTTP 통신은 운영자에 의해 하이재킹 및 수정되며 광고가 삽입됩니다. 비즈니스 이익을 확보하고 공격 표면을 줄이려면 통신 채널의 보안을 보장하기 위해 개발하기 쉬운 HTTPS를 사용하는 것이 좋습니다.

HTTPS 통신 원리

HTTPS는 SSL/TLS를 통한 HTTP이고, HTTP는 애플리케이션 계층 프로토콜이고, TCP는 전송 계층 프로토콜이며, 애플리케이션 계층과 전송 계층 사이에 보안 소켓 계층 SSL/TLS가 추가됩니다.

위 그림과 같이 HTTPS에는 HTTP에 비해 SSL/TLS라는 추가 계층이 있습니다. SSL/TLS 계층은 암호화 및 복호화 알고리즘 협상, 키 교환, 통신 설정을 담당합니다. 클라이언트와 서버 간의 연결.

HTTPS는 데이터를 전송하기 전에 클라이언트(브라우저)와 서버(웹사이트) 간의 핸드셰이크가 필요합니다. 핸드셰이크 과정에서 전송된 데이터를 암호화하기 위한 양측의 비밀번호 정보가 설정됩니다. TLS/SSL 프로토콜은 암호화된 전송 프로토콜 집합일 뿐만 아니라 아티스트가 세심하게 설계한 예술 작품이기도 합니다. TLS/SSL은 비대칭 암호화, 대칭 암호화 및 HASH 알고리즘을 사용합니다. 핸드셰이크 프로세스는 다음과 같습니다.

(1).client_hello

클라이언트는 요청을 시작하고 버전 정보, 암호 제품군 후보 목록, 압축 알고리즘 후보 목록, 난수를 포함한 요청 정보를 일반 텍스트로 전송합니다. , 확장 필드 및 기타 정보, 관련 정보는 다음과 같습니다.

• 지원되는 가장 높은 TSL 프로토콜 버전은 낮은 것부터 높은 것까지 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2는 현재 TLSv1보다 낮은 버전은 기본적으로 없습니다.

• 지원되는 암호화 제품군의 클라이언트 목록 각 암호화 제품군은 이전 TLS 원칙의 네 가지 기능 조합에 해당합니다: 인증 알고리즘 Au(신원 확인), 키 교환 알고리즘 KeyExchange(키 계약), 대칭 암호화 알고리즘 Enc(정보 암호화) 및 정보 다이제스트 Mac(무결성 확인)

• 후속 정보 압축 전송에 사용되는 압축 방법 목록

• 후속 키에 사용되는 난수 random_C 생성 ;

• 프로토콜 및 알고리즘의 관련 매개변수와 기타 보조 정보 등을 지원하는 확장 필드 확장. 공통 SNI는 확장 필드이며 이 필드의 역할은 나중에 별도로 논의됩니다.

(2).server_hello+server_certificate+sever_hello_done

• server_hello, 서버는 선택한 프로토콜 버전 버전, 선택한 암호 제품군, 선택한 압축 알고리즘 압축 방법, 난수random_S를 포함한 협상 정보 결과를 반환합니다. 등, 이후 키 협상에 임의의 숫자가 사용됩니다.

• server_certificates, 서버는 신원 확인 및 키 교환을 위해 해당 인증서 체인을 구성합니다.

• server_hello_done, 클라이언트에 server_hello 메시지 전송이 종료되었음을 알립니다. ;

(3).인증서 검증

인증이 통과되면 후속 통신이 수행됩니다. 그렇지 않으면 오류 상황에 따라 메시지가 표시됩니다. . 적법성 확인에는 다음이 포함됩니다.

• [인증서 체인]의 신뢰할 수 있는 인증서 경로, 방법은 위에서 언급한 것과 같습니다.

• 인증서 취소 여부에 관계없이 오프라인 CRL과 온라인 OCSP의 두 가지 방법이 있습니다. 클라이언트마다 다르게 작동합니다.

• 인증서가 유효 기간 내에 있는지 여부; • 도메인 이름 도메인, 인증서 도메인 이름이 현재 액세스 도메인 이름과 일치하는지 확인하고 일치 규칙에 대한 후속 분석

(4).client_key_exchange+change_cipher_spec+encrypted_handshake_message

(a) client_key_exchange, 이후; 적법성 검증이 통과되면 클라이언트는 난수를 계산하고 생성합니다. 사전 마스터를 사용하여 인증서 공개 키로 암호화한 후 서버로 보냅니다.

(b) 이때 클라이언트는 계산에 필요한 모든 정보를 얻었습니다. 협상 키: 두 개의 일반 텍스트 난수 random_C 및 random_S와 자체적으로 계산된 숫자 Pre-master, 협상된 키 계산

enc_key=Fuc(random_C, random_S, Pre-Master)

(c)change_cipher_spec , 클라이언트는 후속 통신이 암호화된 통신을 위해 협상된 통신 키와 암호화 알고리즘을 사용할 것임을 서버에 알립니다.

(d) crypto_handshake_message는 모든 이전 통신 매개변수의 해시 값과 기타 관련 정보를 결합하여 데이터 조각을 생성합니다. , 협상된 키 세션 비밀 및 알고리즘을 사용하여 암호화한 다음 데이터 및 핸드셰이크 확인을 위해 서버로 보냅니다.

(5).change_cipher_spec+encrypted_handshake_message

(a) 서버는 개인 키를 사용하여 다음을 수행합니다. 암호화된 사전 마스터 데이터를 해독하고 이전에 교환된 두 개의 일반 텍스트 난수 Random_C 및 Random_S를 기반으로 협상된 비밀을 계산합니다. 키: enc_key=Fuc(random_C, random_S, Pre-Master);

(b) 이전에 수신한 모든 메시지의 해시 값을 해시한 다음 클라이언트가 보낸 암호화된_handshake_message를 해독하여 데이터와 키의 정확성을 확인합니다.

(c)change_cipher_spec, 확인을 통과한 후 서버도 클라이언트는 후속 통신에서 암호화된 통신을 위해 협상된 키와 알고리즘을 사용합니다.

(d) encrypted_handshake_message, 서버는 또한 모든 현재 통신 매개변수를 결합합니다. 메시지는 데이터 조각을 생성하고 협상된 키 enc_key 및 알고리즘을 사용하여 암호화합니다.

(6) 핸드셰이크가 종료됩니다

클라이언트는 수신된 모든 메시지의 해시 값을 계산하고 협상된 키를 사용하여 암호화된_handshake_message를 해독하고, 서버에서 보낸 데이터와 키를 확인합니다. 확인이 통과되면 핸드셰이크가 완료됩니다.

(7) 암호화된 통신

암호화된 통신을 위해 협상된 키와 알고리즘을 사용하여 시작하세요. 타이밍 다이어그램은 다음과 같습니다:

인증서 확인

(3) 인증서 확인에서는 서버에서 보낸 인증서를 클라이언트가 확인합니다. 이 프로세스에서 수행되는 작업을 자세히 살펴보겠습니다.

1.

2. 신뢰 목록에 있는지 확인

2. 적법성 확인

인증서 검증 시 클라이언트는 인증서에 포함된 관련 일반 텍스트 정보를 읽고 동일한 해시를 사용하여 그런 다음 해당 CA의 공개 키(로컬에서 검색)를 사용하여 서명 데이터를 해독하고 인증서의 정보 다이제스트를 비교하여 일치하면 인증서의 적법성, 즉 공개를 확인할 수 있습니다. 키가 합법적입니다.

인증서 내용:

신청자의 공개 키, 신청자의 조직 정보 및 개인 정보, 발급 기관 CA 정보, 유효 시간, 인증서 일련 번호 및 기타 정보가 일반 텍스트로 포함되어 있으며 서명도 포함되어 있습니다.

서명 생성: 해시 함수를 사용하여 공개 일반 텍스트 정보의 정보 다이제스트를 계산한 다음 CA의 개인 키를 사용하여 정보 다이제스트를 암호화하며 암호문이 서명입니다.

Tips;

1. 클라이언트는 서버에서 보낸 공개 키를 사용하여 데이터를 암호화하고 암호화된 데이터를 서버로 보냅니다. 개인 키를 사용하여 해독할 수 있습니다. 대칭 암호화

2. 클라이언트와 서버가 모두 협상 키enc_key를 마스터하면 양측이 이 키를 사용하여 암호화하고 해독합니다. 암호화 알고리즘 개요

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

1. 대칭 암호화

에는 스트리밍과 그룹화의 두 가지 유형이 있습니다. 암호화와 복호화에 동일한 키가 사용됩니다.

예: DES, AES-GCM, ChaCha20-Poly1305 등

2. 비대칭 암호화

암호화에 사용되는 키와 복호화에 사용되는 키는 각각 공개 키와 개인 키라고 합니다. . 비대칭 암호화 알고리즘은 성능은 낮지만 보안성은 매우 높습니다. 암호화 특성으로 인해 비대칭 암호화 알고리즘으로 암호화할 수 있는 데이터의 길이도 제한됩니다.

예: RSA, DSA, ECDSA, DH, ECDHE

3. 해시 알고리즘

모든 길이의 정보를 더 짧은 고정 길이 값으로 변환합니다. 일반적으로 해당 길이는 정보보다 작습니다. 더 많으며 알고리즘은 되돌릴 수 없습니다.

예: MD5, SHA-1, SHA-2, SHA-256 등

4. 디지털 서명

서명은 정보(값) 뒤에 콘텐츠를 추가하는 것입니다. 해싱 후의 정보)를 통해 해당 정보가 수정되지 않았음을 증명할 수 있습니다. 해시 값은 일반적으로 암호화(서명)된 다음 메시지와 함께 전송되어 해시 값이 수정되지 않도록 합니다.

양방향 인증:

서버는 클라이언트에게 인증을 요청할 수도 있습니다. 즉, 양방향 인증은 2번 과정에서 client_certificate_request 정보를 보낼 수 있습니다. 클라이언트는 먼저 client_certificate 및 Certificate_verify_message 정보를 보냅니다. 4. 인증서 검증 방법은 기본입니다. 마찬가지로,certificate_verify_message는 클라이언트의 개인 키로 암호화된 협상된 통신 정보를 기반으로 하는 데이터 조각입니다. 서버는 해당 공개 키를 사용하여 이를 복호화하고 검증할 수 있습니다.

위 내용은 HTTPS 통신의 원리는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!