미니 프로그램 개발자는 HTTPS 프로토콜의 심층 분석에 주의를 기울여야 합니다.

WeChat Mini 프로그램 액세스 문제

설날이 다가오고 있으며 WeChat Mini 프로그램이 예정대로 출시될 예정입니다. 개발자는 WeChat Mini 프로그램에 액세스할 때 다음과 같은 문제에 직면하게 됩니다.

미니 프로그램에서는 HTTPS를 통해 서버와의 통신이 완료되어야 하며, 개발자가 직접 HTTPS 서비스를 구축하기로 선택한 경우 https 서비스 구축을 완료하려면 자체 SSL 인증서를 신청하고 배포해야 합니다. 시간이 오래 걸리고 HTTPS의 SSL을 구문 분석해야 하며 CPU에 상당한 오버헤드가 있습니다.

2017년에는 미니 프로그램뿐만 아니라 Apple iOS 플랫폼, Google Android도 점차 개발자에게 HTTPS 액세스를 사용하도록 강요했습니다. HTTPS는 많은 개발자에게 골치 아픈 문제를 야기하는 피할 수 없는 임계값인 것 같습니다.

위 문제에 대응하여 Tencent Cloud의 로드 밸런싱 서비스(클라우드 로드 밸런싱)는 HTTPS 성능을 최적화하고 HTTPS 적용 임계값과 사용 비용을 낮추어 원클릭 SSL 인증서 신청 서비스를 제공하고자 합니다. 개발자는 WeChat 미니 프로그램과 같은 서비스에 빠르게 접근할 수 있습니다. 먼저, HTTP와 HTTPS를 비교하여 미스터리를 하나씩 풀어보겠습니다.

2. HTTPS에 연결해야 하는 이유 - HTTP의 보안 위험

HTTP 프로토콜은 인터넷의 대부분의 주요 애플리케이션은 기본적으로 HTTP를 사용합니다. 1990년대의 성능 및 사용 환경 제한으로 인해 HTTP 프로토콜 자체는 보안을 위해 설계된 프로토콜이 아니며, 가장 문제가 되는 것은 모든 HTTP 콘텐츠가 일반 텍스트로 전송된다는 것입니다.

한편, 인터넷의 발전도 날이 갈수록 변화하고 있으며, 다양한 HTTP 애플리케이션이 사람들의 삶 곳곳에 계속해서 침투하고 있습니다. 소셜 네트워킹, 쇼핑, 금융, 게임, 검색 등 HTTP 서비스는 사람들에게 큰 편리함을 제공하고 삶의 질과 효율성을 향상시킬 수 있습니다.

분명히 HTTP는 사람들의 삶과 경제적 이익과 밀접한 관련이 있지만 안타깝게도 안전하지 않습니다. 이는 여기에 엄청난 안전 위험이 숨겨져 있음을 의미합니다. 이러한 숨겨진 위험은 다음 두 가지 측면에 집중되어 있습니다.

1. 개인 정보 유출

HTTP 자체는 일반 텍스트 전송이므로 사용자와 서버 간의 전송 내용을 볼 수 있습니다. 중개자. 즉, 온라인 검색, 쇼핑, 방문한 웹사이트, 클릭한 페이지 등의 정보를 모두 "중개자"가 얻을 수 있습니다. 대부분의 중국인은 개인정보 보호에 큰 관심을 기울이지 않기 때문에 이곳의 위험은 상대적으로 숨겨져 있고 피해의 결과를 정량적으로 평가하기가 쉽지 않습니다. 더 심각한 것으로 알려진 개인 정보 유출 사례는 다음과 같습니다.

QQ 로그인 상태를 범죄자가 도용한 후 다른 곳에 로그인하여 광고 및 사기 행위를 했습니다.

이용자의 휴대폰번호와 신원정보가 유출되었습니다.

사용자의 온라인 행동 유출. 예를 들어, 병원을 검색하면 곧 누군가 전화해서 홍보합니다(비효과적인 광고).

2. 페이지 하이재킹

개인정보 유출의 위험성은 상대적으로 숨겨져 있어 기본적으로 사용자들은 이를 인지하지 못합니다. 그러나 또 다른 유형의 하이재킹의 영향은 매우 명백하고 직접적입니다. 페이지 하이재킹은 사용자의 검색 페이지를 직접적으로 변조하는 것을 의미합니다. 제3자 광고나 운영자의 트래픽 프롬프트 정보를 직접 삽입하는 매우 간단하고 조잡한 페이지 하이재킹이 많이 있습니다.

하지만 다음과 같은 JD 페이지 하이재킹과 같이 좀 더 미묘한 하이재킹도 있습니다. 위 사진은 HTTP를 사용한 페이지이고, 로 표시된 페이지가 있습니다. 위쪽 화살표 쇼핑 추천은 JD.com이나 브라우저의 공식 도구처럼 매우 현실적입니다.

그런데 HTTPS 접속으로 전환하면 그런 툴페이지도 없고, 당연히 하이재킹됩니다.

3. 하이재킹 경로 및 분류

하이재킹은 어떻게 발생하나요? 기술적으로 말하면 콘텐츠가 전달되는 곳마다 모니터링하고 변조하기만 하면 됩니다. 그러나 전체 하이재킹 산업 체인을 이해하려면 블랙 산업에 깊이 들어가야 하며 이는 더욱 어렵습니다. 한 가지 확실한 점은 대부분의 하이재킹이 "중간자"(MITM)라고도 불리는 중간 네트워크 노드에서 발생한다는 것입니다. 아래 그림과 같이

정보 전송은 위에서 언급한 "중개자 노드"를 거쳐야 하므로 정보를 읽고 쓸 수 있는 권한도 가지고 있습니다. 정보가 암호화되지 않으면 검증이 되지 않습니다. 개인정보를 확인하고 페이지를 조작하려는 경우 "중개자"가 매우 쉽습니다.

하이재킹의 주요 카테고리는 무엇인가요? 하이재킹 경로에 따라 아래 그림과 같이 크게 3가지 카테고리로 나뉩니다.

DNS 하이재킹, 클라이언트 하이재킹, 링크 하이재킹. 불완전한 통계에 따르면 기업에서 발생하는 대부분의 하이재킹(90%)은 링크 하이재킹입니다.

3. HTTPS는 링크 하이재킹을 해결하는 핵무기입니다

HTTPS가 링크 하이재킹을 잘 해결할 수 있는 이유는 무엇인가요? 주로 세 가지 무기:

1. 신원 인증 - 위조 방지, 부인 방지

새 HTTPS 연결이 설정될 때마다 사용자가 액세스하고 있는지 확인하기 위해 신원을 인증해야 합니다. 올바른 목적의 웹사이트.

2. 콘텐츠 암호화 - 도청 방지

콘텐츠 암호화란 모든 엔드투엔드 통신 콘텐츠가 암호문이며, 중개자가 직접 암호화할 수 없음을 의미합니다. 일반 텍스트 보기 HTTPS all 애플리케이션 계층 콘텐츠는 대칭 암호화를 통해 암호화 및 해독됩니다.

3. 일관성 검증 - 변조 방지

중개자가 메시지 내용을 변조하는 것을 방지하고 데이터의 MAC 코드 및 공유 키를 통해 데이터를 보장합니다.

4. HTTPS 대중화의 아픔

사실 HTTPS는 1995년에 탄생한 매우 오래되고 성숙한 프로토콜입니다. 동시에 콘텐츠 하이재킹을 효과적으로 방지하고 사용자 개인정보를 보호할 수 있습니다. 그런데 왜 오늘날까지 대부분의 웹사이트는 여전히 HTTPS를 지원하지 않고 HTTP만 사용하고 있을까요?

HTTPS의 인기에 영향을 미치는 주된 이유는 다음 두 단어로 요약할 수 있습니다. " 그리고 "비싸다".

1. 느림

최적화가 이루어지지 않으면 HTTPS는 사용자의 액세스 속도를 심각하게 저하시킵니다. 주요 요인은 다음과 같습니다.

네트워크 시간이 많이 소요됩니다. 프로토콜 규정으로 인해 네트워크 전송이 수행되어야 합니다. 예를 들어 SSL 전체 핸드셰이크, 302 점프 등이 있습니다. 최악의 시나리오에서는 7개의 RTT가 추가될 수 있습니다.

계산 시간입니다. 클라이언트와 서버 모두 대칭 암호화 및 복호화, 프로토콜 분석, 개인 키 계산, 인증서 확인 및 기타 계산을 수행해야 하므로 계산 시간이 많이 추가됩니다.

2. 비싸다

HTTPS는 주로 다음 세 가지 측면에서 비싸다.

서버 비용. HTTPS의 개인키 계산으로 인해 서버 성능은 HTTP 프로토콜의 10분의 1에도 못 미치는 수준으로 급격하게 저하됩니다. 즉, HTTP의 성능이 10,000cps라면 HTTPS의 성능은 몇 배에 불과할 수 있습니다. 백 cps로 인해 서버 비용이 몇 배 또는 수십 배 증가합니다.

인증서 비용. 인증서 수와 유형에 따라 인증서 비용은 연간 수억에서 수백만까지 다양할 수 있습니다.

개발 및 운영, 유지관리 비용입니다. HTTPS 프로토콜은 상대적으로 복잡하며 openssl의 오픈 소스 구현에서 보안 버그가 자주 발생합니다. 프로토콜 구성, 인증서 업데이트, 만료 모니터링, 클라이언트 호환성 등을 포함한 일련의 문제는 후속 조치 및 처리를 위해 전문적인 배경을 가진 기술 인력이 필요합니다. 그들과 함께.

5. Tencent Cloud Load Balancer HTTPS 성능 최적화

Tencent Cloud Load Balancer는 HTTPS 홍보 및 적용 과정의 문제점에 맞게 최적화되었습니다. . 다음으로 이러한 최적화 솔루션을 자세히 소개합니다.

1. 액세스 속도 최적화

앞서 언급했듯이 HTTPS는 주로 두 가지 수준에서 액세스 속도를 최적화했습니다. 스택, 프런트엔드 및 백엔드 리소스.

전체 링크 프로토콜 스택 최적화

HTTPS는 SSL을 통한 HTTP로 간주될 수 있으며 HTTPS는 전송에 TCP 프로토콜을 사용하므로 전체 프로토콜 스택의 최적화에는 세 가지 수준이 포함됩니다.

TCP 최적화. 혼잡 창 조정, TCP 빠른 열기, 재사용 포트 지원, 최신 BBR 혼잡 제어 알고리즘 지원 등을 포함합니다.

SSL 프로토콜 최적화. 분산 세션 캐시, 세션 티켓, 잘못된 시작, ocsp 스테이플링 파일, 동적 레코드 크기 등

SSL 프로토콜 최적화의 가장 중요한 목표는 단순화된 핸드셰이크의 비율을 높이는 것입니다. Tencent Cloud는 글로벌 세션 캐시와 글로벌 세션 티켓을 구현하여 SSL의 단순화된 핸드셰이크 비율을 향상시켜 사용자 액세스 시간과 컴퓨팅 리소스를 절약합니다.

애플리케이션 계층 프로토콜 최적화. SPDY, HTTP2, HSTS 등도 지원합니다.

HTTP1.X에 비해 HTTP2의 가장 큰 장점은 TCP 연결을 통해 여러 HTTP 요청을 병렬로 보낼 수 있다는 것입니다. HTTP1.X의 직렬 전송과 비교하면 성능은 확실히 A입니다. 많은 개선이 이루어졌습니다.

HTTP2는 SPDY에서 상속 및 개발되었기 때문에 일부 이전 클라이언트는 HTTP2가 아닌 SPDY만 지원합니다. 대부분의 신규 클라이언트는 HTTP2만 지원하고 SPDY는 지원하지 않습니다. 기존 클라이언트와 신규 클라이언트 모두의 성능과 호환되기 위해 Tencent Cloud는 SPDY와 HTTP2를 모두 지원하여 기존 클라이언트와 신규 클라이언트의 성능을 극대화합니다.

프론트엔드와 백엔드 최적화

HTTP2와 SPDY의 가장 큰 특징이자 장점은 하나의 연결을 통해 여러 요청을 병렬로 보낼 수 있는 멀티플렉싱이다. 이 기능은 매우 강력하지만 기존 HTTP 최적화 전략을 계속 사용하는 경우 멀티플렉싱 효과는 매우 제한됩니다. 예를 들어 도메인 이름 샤딩, 파이프라인 등은 멀티플렉싱 효과에 영향을 미칩니다. 그래서 여러 데이터 실험을 통해 백엔드 액세스 전략을 포함한 일부 프런트엔드 리소스를 조정했습니다.

도메인 이름 검색. 페이지 자원 및 성능 분석을 통해 3페이지 이내로 이동하는 등 도메인 이름 검색 계획을 확인합니다.

사전 구축된 연결. STGW는 핫 페이지에서 사용자 행동을 분석하여 사전에 연결을 설정하여 프로토콜 오버헤드가 사용자 경험에 미치는 영향을 줄입니다.

Tencent Cloud의 글로벌 CDN 및 IDC 노드를 통해 HTTPS 오프로드를 완료하세요.

2. 컴퓨팅 성능 최적화

Tencent Cloud는 HTTPS의 컴퓨팅 성능을 주로 다음과 같은 세 가지 수준으로 최적화했습니다.

완전한 핸드셰이크 발생을 최소화합니다. , 단순화된 악수 비율을 개선합니다. 예를 들어 앞서 언급한 전역 세션 캐시 및 세션 티켓이 있습니다.

Tencent Cloud는 프로토콜 스택의 변환과 SSL 하드웨어 가속기 카드의 사용을 통해 RSA 비동기 프록시 컴퓨팅을 구현하여 HTTPS의 컴퓨팅 성능과 공격 방지 기능을 크게 향상시켰습니다. .

대칭 암호화 계산 프로세스도 시나리오에 사용하도록 최적화되었습니다.

자세한 소개는 다음과 같습니다.

RSA 비동기 프록시 계산

Tencent Cloud는 비대칭 키 교환 알고리즘인 HTTPS의 가장 심각한 성능 소비 링크를 대상으로 합니다. 집중된 최적화. 최적화 아이디어는 주로

알고리즘 분리의 세 부분으로 구성됩니다. CPU 자원을 가장 많이 소모하는 알고리즘을 제거하고, 로컬 CPU 자원을 소모하지 못하도록 방지하는 것입니다.

에이전트 계산. RSA 계산을 완료하려면 유휴 CPU 시스템 또는 전용 SSL 하드웨어 가속 카드를 사용하십시오.

비동기 실행. 기존 openssl이 RSA를 수행할 때 NGINX와 같은 상위 계층 애플리케이션은 동기적으로 기다려야 합니다. 이 단계는 또한 매우 영향력이 크며 RSA 계산을 위해 클러스터가 가속화될 때 액세스 서버가 다른 사용자로부터 요청을 받아 처리량을 향상시킬 수 있도록 비동기식으로 수정되어야 합니다.

openssl 핸드셰이크 프로토콜 스택의 심층적인 변환과 SSL 하드웨어 가속기 카드의 RSA 컴퓨팅 성능을 통해 Tencent Cloud CLB의 SSL 컴퓨팅 성능이 향상되었습니다. 350%. 단일 머신 ECDHE_RSA 처리 성능은 65000cps에 이릅니다.

대칭 암호화 알고리즘 자동 최적 선택

Tencent Cloud는 애플리케이션 시나리오에 따라 최적의 대칭 암호화 알고리즘을 일치시킵니다.

동영상과 같은 스트리밍 콘텐츠의 경우 aes-가 선호됩니다. gcm.gcm.

aes-ni 하드웨어 가속 명령어를 지원하지 않는 모바일 단말기의 경우 chacha20-poly1305를 사용하세요.

IE6 등 앤티크 수준 클라이언트의 경우 RC4 알고리즘을 사용하세요.

3. 프로토콜 병렬 제거

Tencent Cloud CLB는 현재 모든 주류 HTTP 프로토콜의 액세스 및 제거를 지원합니다. 포함:

http1.0/http1.1

http2 및 이전 버전 spdy3.1

https(ssl3.0, tlsv1.0, tlsv1.1, tlsv1 포함) . 2

웹소켓과 보안 웹소켓.

tcp, udp 투명 전달.

CLB는 위의 7계층 프로토콜을 HTTP1.1로 균일하게 변환하여 기업에 투명하게 전송할 수 있습니다. 비즈니스에 대한 이점도 매우 분명합니다. 개발 비용 없이 HTTPS와 HTTP2를 사용할 수 있으므로 다양한 프로토콜과 클라이언트에 적응해야 하는 부담이 크게 줄어듭니다.

4. 안전

보안과 관련된 분야와 시나리오는 매우 넓습니다. HTTPS는 링크 하이재킹을 완전히 해결할 수 있지만 다음 두 가지 유형의 문제에는 무력합니다.

CC 공격, 특히 HTTPS 컴퓨팅 공격, 성능 저하 HTTPS가 감소됩니다. 급격한 감소로 인해 보안 위험이 커집니다.

SQL 삽입, XSS 크로스 사이트, 웹사이트 악성 코드 등을 포함한 비즈니스 보안

위의 두 가지 범주는 종종 기업을 괴롭히는 매우 위험한 보안 문제입니다.

위 문제에 대응하여 Tencent Cloud는 HTTPS용 CC 및 WAF를 방지하는 보안 시스템도 설계 및 구현하여 이러한 보안 위험을 효과적으로 방어할 수 있습니다.

키리스(키 로딩 없음) 개인 키의 중요성

인증서에 조금 익숙한 친구들은 SSL 키와 인증서가 모두 사용된다는 것을 알고 있습니다. 인증서는 개인 키와 고유하게 일치해야 합니다. 전체 HTTPS에서 가장 중요한 데이터는 SSL 개인 키입니다. 개인 키가 유출되면 전체 핸드셰이크 프로세스가 탈취되고 서명이 위조될 수 있으며 대칭 키가 해독될 수 있습니다. HTTPS 전체에 대해서는 안전한 것이 없습니다.

기존 개인 키 사용 솔루션 및 위험

기존 개인 키 솔루션은 개인 키를 애플리케이션에 바인딩하는 것입니다. 예를 들어 잘 알려진 nginx 및 apache와 함께 HTTPS를 사용하려면 nginx가 배포된 액세스 머신에 관련 인증서와 개인 키를 배포해야 합니다.

이 솔루션에는 다음과 같은 보안 문제가 있습니다. 개인 키가 클라우드 또는 CDN에 배포됩니다.

무키 방식

Tencent Cloud의 인트라넷은 매우 안전하지만 고객의 보안에 대한 책임으로 개인 키 유출에 대한 사용자의 걱정을 완전히 없애고 사용자의 안전을 보장합니다. 절대적인 제어를 위해 Tencent Cloud는 개인 키가 없는 로딩 솔루션을 제공합니다. 이 솔루션의 핵심은 "Tencent Cloud에 개인 키를 저장할 필요가 없으므로 사용자가 자신의 서버를 사용하여 개인 키를 저장하고 HTTPS 액세스를 완료할 수 있다"는 것입니다. Tencent Cloud에는 개인 키에 대한 액세스 권한이 없으며 고객은 집에 있는 자체 서버에 개인 키를 저장할 수도 있습니다.

액세스 프로세스는 다음과 같습니다.

사용자가 HTTPS 핸드셰이크 요청을 시작합니다.

개인 키 계산과 관련하여 Tencent Cloud CLB는 암호화된 맞춤형 프로토콜을 통해 개인 키 계산 요청을 사용자의 키리스 서버에 전달합니다.

키리스 서비스는 사용자의 개인 키를 호출하여 계산을 완료합니다.

키리스 서비스는 계산 결과를 Tencent Cloud CLB로 반환합니다.

CLB는 계속해서 HTTPS 요청을 처리합니다.

전체 과정에서 Tencent Cloud는 HTTPS 개인 키에 액세스할 수 없습니다. Keyless 서버는 Tencent Cloud에서 제공하는 서버 프로그램이며 코드는 사용자입니다. 독립적으로 배포할 수 있습니다. 서버 동작은 사용자에 의해 제어됩니다.

6. 제로 임계값, WeChat 미니 프로그램에 대한 HTTPS 빠른 액세스

Tencent Cloud CLB 로드 밸런서는 프로토콜 스택의 심층적인 최적화를 통해 이를 달성합니다. 및 서버 HTTPS 성능이 크게 향상되었습니다. 동시에, 우리는 국제적으로 유명한 인증 기관과 협력하여 인증서 비용을 크게 절감했습니다. Tencent Cloud CLB는 다음과 같은 측면에서 WeChat 미니 프로그램 액세스에 매우 중요한 이점을 제공할 수 있습니다.

원클릭 SSL 인증서 애플리케이션을 제공하는 CLB 로드 밸런싱 서비스는 HTTPS 프록시 역할을 하여 개발자가 개발 부담을 줄여줍니다. 소규모 프로그램 사업의 발전에 관한 것입니다.

HTTPS를 사용해도 클라이언트측 액세스 속도는 줄어들지 않습니다. HTTP와 HTTPS 액세스 지연은 거의 동일합니다.

클러스터에 있는 단일 서버의 SSL 암호화 및 암호 해독 성능, 최대 6.5Wcps 전체 핸드셰이크. 고성능 CPU 대비 최소 3.5배 향상돼 서버 비용을 절감하고 업무 운영 및 트래픽 급증 시 서비스 능력을 대폭 향상시키며 전산 공격 방어 능력을 강화한다.

다양한 프로토콜 제거 및 변환을 지원합니다. 다양한 클라이언트 프로토콜에 적응해야 하는 비즈니스의 부담을 줄여줍니다. 비즈니스 백엔드는 HTTP2, SPDY, SSL3.0, TLS1.2 및 기타 버전의 프로토콜을 사용하기 위해 HTTP1.1만 지원하면 됩니다. WeChat 미니 프로그램, iOS 플랫폼 등의 프로토콜 요구 사항을 충족합니다.

SSL 인증서 적용, 모니터링 및 교체. 우리는 최고의 국제 인증 제조업체인 Comodo 및 Symantec과 긴밀한 협력 관계를 맺고 있으며 완벽한 서비스 시스템을 갖추고 있습니다.

Anti-CC 및 WAF 기능. 느린 연결, 고주파수 고정 소수점 공격, SQL 주입, 웹 페이지 악성 코드 등의 애플리케이션 계층 공격을 효과적으로 방지할 수 있습니다.

위의 이점은 개발자가 HTTPS 평가판 임계값을 낮추는 데 도움이 될 수 있습니다.

HTTPS 프로토콜에 대한 심층 분석에 주의가 필요한 소규모 프로그램 개발자는 PHP 중국어 웹사이트에 주목하세요!