Secure transport mechanism

  • Article
  • 5 minutes to read

Content hijacking means that an operator, link provider, or hacker connects a bypass device to the router to detect HTTP requests passing through, identifies target HTTP requests using a particular hijack strategy, and sends a 302 response to the client before the source station feeds back data, so that the client is forced to jump to other server request content (that is, the URL request is hijacked).

Criminals might replace the original client user request content with tempered content for nefarious purposes, such as to illegally profit, spread malicious information, or compete by improper means.

Content hijacking or content tampering causes end users to experience access errors or download the wrong files.

Azure Content Delivery Network-accelerated end-to-end access for user Content Delivery Network node access: Content Delivery Network network file transfer > Content Delivery Network node back to source. The Content Delivery Network ensures that files within the Content Delivery Network are securely transferred. To prevent and handle content hijacking and tampering, the Content Delivery Network also uses certificate encryption, intelligent routing, and URI encryption for transfers between users accessing a Content Delivery Network node and the return-to-source Content Delivery Network node. The security of the source station itself depends upon the client taking the corresponding measures.

Secure file transport in the Content Delivery Network

Content Delivery Network acceleration ensures that files within the Content Delivery Network are securely transferred and Content Delivery Network-node files are securely stored.

Secure file transport in the Content Delivery Network

Content obtained by the Content Delivery Network is transferred within the Content Delivery Network using the Content Delivery Network operator’s proprietary transport protocol, which encrypts data packets for transfer.

Content Delivery Network-node file storage security

  1. Content Delivery Network-node file caching uses a special hash algorithm optimized by Content Delivery Network partners to map files to irregular directories. It is impossible to find the storage path for the file without the Content Delivery Network partner’s hash algorithm. This method ensures that documents are both secure and invisible, preventing illegitimate users from retrieving stored content or tampering with cached content.

  2. Content Delivery Network partners use encrypted storage for file content stored on nodes, so even if the file storage path is found, the stored files are still encrypted. Without knowing the file encryption algorithm, even if the file content is accessed, it will simply be rendered unrecognizable. This stops criminals from achieving their illegal objectives by means of content tampering.

Secure transfers
This section discusses secure transfers between end users who access a Content Delivery Network node and the return-to-source Content Delivery Network node.

HTTPS acceleration

The request encryption scheme is the HTTPS acceleration solution. The request encryption scheme is the HTTPS acceleration solution. HTTPS is a network protocol that is built by using the SSL and HTTP protocols that can perform accelerated transfers and authentication. The creation of an encrypted communication channel between the server and the client ensures that data will not be intercepted or hacked during the online transfer process. It also makes hijacking impossible.

HTTPS acceleration access modes

Content Delivery Network partners apply for SSL certificates for clients and deploy them to the Content Delivery Network node. The end-user initiates an HTTPS connection request, and then request data is returned to the user if the SSL handshake is successful.

Intelligent routing options to prevent hijacking

Smaller operators generally use certain probabilities of interception for content hijacking, and they generally perform hijacks using specific links. If the client has multiple sources, this approach is equivalent to having multiple return-to-source paths. Moreover, the probability of operator hijacks occurring simultaneously on multiple links is far lower than for a single link. Based on this feature, when the return-to-source Content Delivery Network is hijacked, a corresponding return-to-source path is selected for the next return-to-source path tried by determining the legitimacy of the location address for the 302 jump. Intelligently determining return-to-source paths greatly reduces the risk of content hijacking.

Access mode selected for intelligent anti-hijack routing
The client initiates a request for Content Delivery Network node access > Content Delivery Network node not cached > Content Delivery Network node return-to-source request A > return-to-source 302 jump occurs > the legitimacy of the 302 jump is judged and determined to be a hijack > the return-to-source request automatically tries the next source B > source B responds normally.

URI encryption

The Content Delivery Network URI encryption anti-hijacking features work by performing a certain form of encryption on URIs, so that the URI that corresponds to a particular file is continually changing. This methods makes it impossible for operators to hijack, thereby effectively reducing the incidence of such activity.

In situations that require source station cooperation or where there is a [source character missing] side environment, the source station or app client encrypts request URIs using an encryption key agreed with the Content Delivery Network partner.

Encryption principles

  1. Client-side encryption:

    Original URL: Http://[:]/URI?a=1&b=2

    DES encryption of URLs: DES (current time + encryption key + path, encryption key) = DES encryption string

    Encrypted URL: http://[:]/?a=1&b=2

  2. Content Delivery Network reverse decryption

    The Content Delivery Network reverse-decrypts the source station URI by using the agreed-upon encryption key, splices it to produce the original URL, and then continues with the subsequent processing based on the original URL.

Explanation

  1. The value of the encryption key must be agreed upon by the Content Delivery Network partner and the customer.
  2. Because one of the encryption factors uses the time that the request was initiated, a different request URL will be sent for the same file at different times, thereby achieving customization of URLs.
  3. If the customer’s file is in APK format, because mobile operating systems may verify the file’s extension name before downloading the APK, the extension name (for example, APK) of the previous file must be added to the final encrypted URL (that is, after the DES encrypted string), as well as any other query_string values (if necessary).

Handling exceptions

In exceptional circumstances (for example, where the form of the request URL is not consistent with the encryption format, decryption fails, or the key obtained after decryption is different from the key used for decryption), the Content Delivery Network will by default regard this as an illegal request and return a 403 Forbidden error.

Access modes

The source station encrypts the requested URI with the agreed-upon encryption algorithm and key, the user-initiated request reaches the CDN node, the CDN node performs encryption, and then the response is sent to the client.