HTTPS(Hypertext Transfer Protocol over Secure Socket Layer, Hypertext Transfer Protocol based on Secure Socket Layer)는 보안을 목표로 하는 HTTP 채널로, 간단히 말하면 HTTP의 보안 버전입니다. 즉, HTTP에 SSL 레이어를 추가한 것이며, HTTPS의 보안 기반은 SSL이며, SSL 인증서를 통해 서버의 신원을 확인하고 브라우저와 서버 간의 통신을 암호화합니다. 사용되는 포트 번호는 443입니다.
SSL 및 TLS
SSL: SSL(Secure Socket Layer)은 주로 웹용으로 Netscape에서 설계한 보안 전송 프로토콜입니다. 이 프로토콜은 웹에서 널리 사용되었습니다. 인증서 인증은 클라이언트와 웹사이트 서버 간의 통신 데이터가 암호화되고 안전함을 보장합니다.
SSL 프로토콜은 TCP/IP 프로토콜과 다양한 애플리케이션 계층 프로토콜 사이에 위치하여 데이터 통신에 대한 보안 지원을 제공합니다. SSL 프로토콜은 두 가지 계층으로 나눌 수 있습니다. SSL 레코드 프로토콜: 신뢰할 수 있는 전송 프로토콜(예: TCP)을 기반으로 구축되었으며 상위 수준 프로토콜을 위한 데이터 캡슐화, 압축 및 암호화와 같은 기본 기능을 지원합니다. SSL 핸드셰이크 프로토콜: SSL 레코드 프로토콜을 기반으로 하며 실제 데이터 전송이 시작되기 전에 통신 당사자가 신원을 인증하고, 암호화 알고리즘을 협상하고, 암호화 키를 교환하는 데 사용됩니다.
TLS: TLS(전송 계층 보안, 전송 계층 보안 프로토콜)는 두 애플리케이션 간의 기밀성과 데이터 무결성을 제공하는 데 사용됩니다.
SSL이 v3으로 개발되면서 매우 우수한 보안 통신 프로토콜임이 입증되었기 때문에 1999년 인터넷 엔지니어링 그룹 IETF에서 이름을 TLS(Transport Layer Security)로 바꾸고 공식적으로 표준화했으며, 버전 번호도 1.0에서 변경되었습니다. 이므로 TLS1.0은 실제로 SSLv3.1입니다. TLS 1.0은 IETF(Internet Engineering Task Force, Internet Engineering Task Force)에서 개발한 새로운 프로토콜로, SSL 3.0 프로토콜 사양을 기반으로 하며 SSL 3.0의 후속 버전으로, SSL 3.1로 이해될 수 있습니다. 단순히 다른 단계에서 동일한 것에 대한 다른 이름으로 이해됩니다. 프로토콜은 TLS 레코드와 TLS 핸드셰이크의 두 계층으로 구성됩니다. 하위 계층은 신뢰할 수 있는 전송 프로토콜(예: TCP) 위에 위치하는 TLS 레코드 프로토콜입니다. TLS의 주요 목표는 SSL을 더욱 안전하게 만들고 프로토콜 사양을 더욱 정확하고 완전하게 만드는 것입니다.
TLS는 2006년 1.1, 2008년 1.2, 2018년 1.3의 세 가지 버전을 개발했습니다. 각각의 새로운 버전은 암호화 기술의 발전과 인터넷의 현재 상태를 밀접하게 따르고 보안과 성능을 지속적으로 강화하며 정보 보안 분야에서 권위 있는 표준이 되었습니다.
현재 가장 널리 사용되는 TLS는 1.2이며, 이전 프로토콜(TLS1.1/1.0, SSLv3/v2)은 안전하지 않은 것으로 간주되었습니다.
HTTPS를 사용하는 이유
HTTPS 프로토콜은 주로 HTTP 프로토콜의 보안 문제를 해결하기 위한 것이며 전송에 HTTP 프로토콜을 사용하는 것은 다음과 같은 위험이 있습니다:
(1) 도청 위험, 예를 들어 통신 링크에서 통신 내용을 획득하여 사용자를 도용할 수 있습니다. 계정.
(2) 스팸광고를 강제로 심는 등의 변조로 인한 시각적 오염의 위험이 있습니다.
(3) 다른 사람의 신원을 사칭하여 구매하는 등의 사칭 위험으로 인해 사용자는 금전적 손실을 입을 수 있습니다.
HTTPS 원칙
HTTPS는 애플리케이션 계층과 네트워크 계층에서 SSL/TSL을 보완합니다. HTTP 요청/응답은 일반적으로 6단계로 나눌 수 있습니다: (1) TCP 연결 설정, (2) HTTP 요청 전송, (3) 서버가 요청 처리, (4) HTTP 응답 반환, (5) HTTP 요청 해제 TCP 연결, (6) 브라우저는 반환된 리소스와 데이터를 구문 분석합니다. 그러나 HTTPS는 TCP 연결 수립을 완료한 후 SSL 연결 수립 과정을 추가하며, 안전한 연결 수립 후 HTTP 요청 및 기타 후속 사항을 전송합니다. 다음으로 SSL(여기서는 TLS 1.2)을 통해 연결을 설정하는 프로세스에 중점을 두겠습니다.
(1) TCP 연결이 설정된 후 브라우저는 먼저 서버에 "인사"하는 "클라이언트 안녕하세요" 메시지를 보냅니다. 여기에는 클라이언트 버전 번호, 지원되는 암호화 제품군 및 후속 세션 키 생성을 위한 난수(클라이언트 무작위) 일반 텍스트가 포함되어 있습니다 .
(2) 서버는 "Client Hello"를 수신한 후 "Server Hello" 메시지를 반환합니다. 버전 번호를 확인하고 난수(Server Random) 일반 텍스트를 지정한 다음 클라이언트가 제공한 암호 모음 목록에서 이 통신에 사용되는 암호 모음 (예: ECDHE 알고리즘)을 선택합니다. 동시에 서버는 자신의 신원을 증명하기 위해 인증서(서버 인증서)도 클라이언트에게 보냅니다. 서버가 암호 모음을 선택했기 때문에 인증서 뒤에 "서버 키 교환" 메시지를 보냅니다. 여기에는 키 교환 알고리즘을 구현하기 위한 공개 키(서버 매개변수)와 자체 개인 키 서명 인증이 포함됩니다.
이어서 "인사말이 완료되었습니다"라는 의미의 "Server Hello Done" 메시지가 나옵니다. 이로써 첫 번째 메시지 왕복(2개의 TCP 패킷)이 완료되고 그 결과 클라이언트와 서버가 세 가지 정보(클라이언트 무작위, 서버 무작위 및 서버 매개변수)를 일반 텍스트로 공유하게 됩니다.
(3) 브라우저는 서버의 인증서를 획득한 후 인증서의 진위 여부를 확인하기 시작하고 인증서의 공개 키를 사용하여 서명을 확인합니다. 서버의 신원을 확인한 후 브라우저는 선택한 암호 제품군을 기반으로 공개 키(클라이언트 매개변수)를 생성한 다음 "클라이언트 키 교환" 메시지를 사용하여 이를 서버로 보냅니다. 이제 브라우저와 서버에는 키 교환 알고리즘의 두 가지 매개변수(클라이언트 매개변수, 서버 매개변수)가 있으며 암호 제품군 알고리즘을 사용하여 "사전 마스터"를 계산합니다. 이제 브라우저와 서버에는 Client Random, Server Random 및 Pre-Master라는 세 가지 임의의 숫자가 있습니다. 이 세 가지를 원료로 사용하면 "마스터 시크릿"이라는 세션을 암호화하는 데 사용되는 마스터 키를 생성할 수 있습니다. 그리고 해커가 "프리마스터"를 얻을 수 없기 때문에 마스터키도 얻을 수 없습니다.
클라이언트 랜덤, 서버 랜덤, 사전 마스터라는 세 가지 난수가 필요한 이유는 무엇입니까? 이는 주로 TLS 프로토콜이 브라우저나 서버의 의사 난수에 대한 신뢰성을 신뢰하지 않기 때문입니다. 정말 "완전히 무작위"이고 "예측할 수 없음"을 보장하기 위해 신뢰할 수 없는 세 개의 난수를 혼합하므로 "임의"입니다. 수준이 높아져 보안이 더욱 보장됩니다.
마스터 키와 이를 기반으로 파생된 세션 비밀을 사용하면 핸드셰이크가 거의 끝나갑니다. 브라우저는 "Change Cipher Spec" 메시지를 보낸 다음 "Finished" 메시지를 보내 이전에 보낸 모든 데이터를 요약하고 암호화한 후 서버에서 이를 확인하도록 합니다.
(4) 서버는 브라우저의 확인 요청을 받은 후 동일한 단계를 거쳐 각각 "Change Cipher Spec"과 "Finished" 메시지를 보냅니다.
(5) 위의 작업이 완료되면 TSL 연결이 설정되고 다음 단계는 암호화된 방식으로 HTTP 요청과 응답을 보내는 것입니다.
인증서를 사용하는 이유
간단히 말해서, 인증서 + 디지털 서명 방법은 인증서 내용이 변조되지 않도록 보장하고 "중간자 공격"을 방지할 수 있습니다. 이는 브라우저에 서버의 신원을 확인하는 방법을 알려주는 것과 같습니다. , 단방향 인증.
단방향 인증과 양방향 인증
단방향 인증은 클라이언트가 서버를 인증해야 함을 의미합니다.
양방향 인증과 단방향 인증의 원칙은 기본적으로 동일하지만 주요 차이점은 클라이언트가 서버를 인증해야 하는 것 외에 서버도 클라이언트를 인증해야 한다는 것입니다. 어떤 시나리오에서 클라이언트를 확인해야 합니까? 예를 들어 일부 은행 서비스에서는 은행이 고객에게 발급한 USB 쉴드를 컴퓨터에 삽입하거나 일부 제어 장치를 설치하도록 요구하는데 이는 클라이언트 인증서의 개념과 유사하며 인증서가 없는 사람은 제공되는 서비스를 사용할 수 없습니다. 은행으로.
HTTPS 요청을 할 때마다 키를 전송하기 위해 SSL/TLS 계층에서 핸드셰이크를 수행해야 합니까?
각 요청에 대해 키 전송 프로세스를 진행하는 데 시간이 많이 소요됩니다. 그렇다면 어떻게 단 한 번의 전송만 달성할 수 있을까요? 서버는 TLS 핸드셰이크 단계에서 브라우저별로 세션 ID를 유지하고 이를 브라우저에 전달하며, 브라우저가 키를 생성하여 서버에 전달한 후 서버는 해당 세션 ID에 키를 저장합니다. 브라우저는 각 요청에 세션 ID를 전달하며, 서버는 세션 ID를 기반으로 해당 키를 찾고 해독 및 암호화 작업을 수행하므로 매번 키를 다시 생성하고 전송할 필요가 없습니다.
HTTPS는 대칭 암호화를 사용합니까, 아니면 비대칭 암호화를 사용합니까?
이 질문에 대답하려면 HTTPS의 원칙을 검토해야 합니다. HTTPS 원칙은 위를 참조하세요.
HTTPS의 원리를 소개하고 나면 HTTPS는 비대칭 암호화를 사용하여 대칭 키를 전송하므로 서버와 브라우저 모두 이를 알 수 있음을 알 수 있습니다. 그런 다음 양 당사자는 이 대칭 키를 사용하여 전송 및 수신된 데이터를 암호화하고 해독합니다. 전송키 K는 비대칭 암호화를 사용하기 때문에 해독이 어렵고 더욱 안전합니다. 특정 전송 데이터는 대칭 암호화를 사용하여 전송 속도를 높입니다. 두 세계의 최고.
클라우드 서비스가 HTTPS를 구현하는 방법
클라우드 서비스의 경우 모든 마이크로서비스에 HTTPS를 구현할 필요는 없으며 인터넷에는 Spring Boot용 HTTPS 구현에 대한 기사가 많이 있는데 이는 오해의 소지가 있습니다. 클라우드 서비스의 경우 서비스 입구에서만 구현하면 되며, 두 가지 일반적인 구현 시나리오가 있는데, 하나는 정적 리소스 지향 CDN이고 다른 하나는 서비스 지향 LB입니다. 물론 방화벽과 같은 다른 상황도 포함될 수 있습니다. 자세한 내용은 다음 두 WIKI를 참조하세요. 한 기사는 Alibaba Cloud 및 Tencent Cloud의 전체 사이트 HTTPS 솔루션 의 HTTPS 구성을 이해하는 데 도움이 됩니다 .
개발자와 아키텍트의 경우 HTTPS의 원리만 이해하면 되며, HTTPS를 구현해야 할 경우 기존 설계에 따라 해당 구성요소에 HTTPS 구성을 구현해야 하며 이 구성은 일반적으로 클라우드 플랫폼에 의존합니다.
HTTPS의 단점
HTTPS 프로토콜에는 다음과 같은 단점이 있습니다.
(1) HTTPS 프로토콜에는 여러 핸드셰이크가 있어 페이지 로딩 시간이 거의 50% 증가합니다.
(2) HTTPS 연결 캐싱은 HTTP만큼 효율적이지 않으며 데이터 오버헤드와 전력 소비를 증가시킵니다.
(3) SSL 인증서를 신청하려면 비용이 들고, 인증서가 강력할수록 비용도 높아집니다.
(4) SSL에 포함된 보안 알고리즘은 CPU 자원을 소모하며 서버 자원도 많이 소모합니다.
HTTP와 HTTPS의 차이점
HTTP는 하이퍼텍스트 전송 프로토콜이며 정보는 일반 텍스트로 전송되므로 보안 위험이 있습니다. HTTPS는 HTTP의 불안정한 단점을 해결하고 TCP와 HTTP 네트워크 계층 사이에 SSL/TLS 보안 프로토콜을 추가하여 메시지를 암호화하고 전송할 수 있습니다.
HTTP 연결 설정은 비교적 간단하며 TCP 3방향 핸드셰이크 후에 HTTP 메시지 전송이 수행될 수 있습니다. TCP의 3방향 핸드셰이크 이후에도 HTTPS는 암호화된 메시지 전송에 들어가기 전에 SSL/TLS 핸드셰이크 프로세스를 수행해야 합니다.
HTTP의 포트 번호는 80이고, HTTPS의 포트 번호는 443입니다.
HTTPS 프로토콜에서는 서버의 ID를 신뢰할 수 있는지 확인하기 위해 CA(인증 기관)의 디지털 인증서를 신청해야 합니다.
참고
https://blog.csdn.net/hguisu/article/details/8680808 HTTPS 구현 원칙
https://zhuanlan.zhihu.com/p/466239718 인터뷰 필수사항: 컴퓨터 네트워크에서 자주 묻는 62가지 질문
https:/ /zhuanlan .zhihu.com/p/27395037 HTTPS 시리즈 건조 정보(1): HTTPS 원리에 대한 자세한 설명
https://www.zhihu.com/tardis/zm/art/72616216 10분 안에 HTTP 및 HTTPS 프로토콜을 이해하는 방법은 무엇입니까?
https://www.rfc-editor.org/rfc/rfc8446 TLS 1.3
https://developer.mozilla.org/zh-CN/docs/Web/Security/Transport_Layer_Security 전송 계층 보안
https://www.cnblogs.com /huansky /p/13977181.html HTTPS를 간단하게(상세판)
https://zhuanlan.zhihu.com/p/43789231 HTTPS 암호화 원리를 철저하게 이해하기
https://zhuanlan.zhihu.com/p/96494976 아시다시피, HTTPS는 대칭 암호화를 사용합니까, 아니면 비대칭 암호화를 사용합니까?
https://www.jianshu.com/p/918d9f517749 https의 대칭 암호화 및 비대칭 암호화
https://zhuanlan.zhihu.com/p/162082184 대칭 또는 비대칭 - https에서 무엇이 사용됩니까?
https://cloud.tencent.com/document/product/400/6813Tencent Cloud는 전체 사이트 HTTPS 솔루션을 구현합니다
https://help.aliyun.com/practice_detail/444367 이 기사는 Alibaba Cloud의 HTTPS 구성을 이해하는 데 도움이 될 것입니다.