Recently, several friends who do chess ran to ask me, said that now DDoS hit more and more fierce, want to go on the high defense CDN and worry about HTTPS encryption - after all, the game of recharge, user data, card game records are sensitive information, naked transmission is simply an invitation to hackers to have a party. I directly dumped the conclusion:Regular high-defense CDNs not only support HTTPS, but must be encrypted throughout the entire processBut there are more potholes here than you think.
Last year our team took over a chess project, just migrated to a CDN out of the moth. User feedback will occasionally receive a “certificate warning”, a check to find the CDN node back to the source actually used HTTP, sensitive data in the last link naked. I was so angry that I was on the spot to beat the table:These days, even CDNs have to “prevent teammates”!。
Why must chess and cards stick to HTTPS full encryption? Simply put, three pain points: first, the user login state and transaction data is intercepted directly means that the black industry carnival; second, the operator sniffs out the gambling keywords may directly pinch the line; third, iOS and Android stores are now on the plaintext transmission of the App audit directly rejected. Don't ask me how I know, paid my dues a few times.
Having tested three major high-defense CDN providers (randomly called CDN5, CDN07, and 08Host, I think), the conclusion is:Support for HTTPS is only the basic operation, the key to see how to realize the closed loop of the encrypted linkFor example, in the default configuration of CDN5, the user goes to the CDN node over HTTPS, but the node returns to the source over HTTP. For example, the default configuration of CDN5, the user to the CDN node is HTTPS, but the node back to the source but went HTTP - this “halfway encryption” is purely psychological comfort. Later, I looked up the documentation and realized that to open a separate “force back to the source HTTPS” switch, hidden deeper than the hidden menu of the sea fish.
Here we post a tested and usable Nginx repo configuration to help you avoid the pitfalls:
Don't look at just a few lines, 08Host customer service actually told me that they do not support HTTPS back to the source, had to let me change to TCP port forwarding. I backhanded on the test CDN07, people not only support, but also can use its own certificate to do two-way verification - game servers only accept requests from CDN nodes, blackmail want to forge back to the source packet door have not.
Certificate management is the real deep endThe first thing you need to do is to get a certificate from the CDN provider. Some CDN providers let you upload the private key of the certificate, and companies with big hearts directly take wildcard certificates and dislike them. I strongly recommend:Never expose high defense nodes with wildcard certificates! Once an edge node is infiltrated, all your subdomains may be naked. The mainstream practice nowadays is to issue certificates for sub-domains, or even use short validity certificates to rotate them automatically (e.g. Let's Encrypt with acme.sh script).
Last year, in the architecture we made for the "Texas Night" project, we signed independent certificates for the user side, backend API, and payment callback. With the SNI (Server Name Indication) function of CDN5, the same IP can host dozens of certificates, and the hacker wants to check the domain name through the IP counter? Directly let him doubt his life.
The performance issue is also a betting point. Many people feel that the HTTPS handshake consumes performance, but modern TLS 1.3 has pressed the handshake time to within 1-RTT. Test data: CDN07 open TLS 1.3 + ECDHE key exchange, the average delay is only 8ms higher than HTTP, but the anti-hijacking ability to double. As for the encryption of CPU consumption, now are hardware accelerated card, QPS 200,000 below the game node can not feel the fluctuations.
The most exciting maneuver is the “certificate sandwich.”--Some small CDNs will secretly sign their own certificates for your domain names, which is called “optimizing the experience” and is actually equivalent to leaving a backdoor in your data channel. Detection method is very simple: use openssl s_client to connect to the CDN node to see if there is any unfamiliar issuer in the certificate chain. After catching it once, we now directly write in the contract “prohibit certificate signature”.
Speaking of configuration hands-on, share a blood lesson:Don't just click “Enable HTTPS” in the CDN console and think everything is fine!. The complete encrypted link requires four steps of verification:
Lastly, some vendors publicize “HTTPS support” as a selling point, but the default configuration is full of loopholes. If you really want to protect the security of chess data, you have to check this list item by item:
In the end, HTTPS for chess high defense CDN is not a multiple choice question but a mandatory question. But encryption isn't enough, it has to be guarded against every single aspect like a jack-in-the-pulpit -If you don't encrypt any of the links from the browser to the server, it's like posting the combination to the safe at the door of the casino.. Now my team always turns on full-link HTTPS by default for new projects, and even requires the CDN vendor to provide configuration templates with SSL Labs scores of A+ or higher.
By the way, I'd like to give you an egg in the end: during the test, I found that the Japanese node of 08Host had mistakenly installed a self-signed root certificate, which led to frequent alarms on iOS devices. SoBe sure to scan the entire node with an SSL inspection tool before going live!, after all, your users won't give you a second chance at trust.
