About the experience sharing of HTTPS forced handshake in iOS SDK

Because of the project needs, the HTTPS forced handshake has been studied, the sharing processing method is as follows:

I. Problems and needs

problem: The Access Party may have HTTPS certificate authentication for the same domain name, and under the caching mechanism, the HTTPS handshake is reused by default in the SDK, or Nsurlprotocol is blocked for authentication.

Requirements: based on the SDK side does not trust the access authentication, the need to force a handshake.

Second, the theoretical premise

1. Handshake cache with IP address, DNS domain name, port key for handshake caching

2. "Www.xxx.com", "www.xxx.com." will have the same DNS resolution result

Third, the solution

1. Server-side gives a dedicated IP, domain name or port

2. Client:

A. When accessing the API at the Unified portal, add the "." After the domain name. As a forged URL

B. After forging the URL trigger handshake, the request returns Didload or failed did fail is not processed, the forged API is removed ".",

Change back to standard API, continue normal communication

C. SDK handshake add identity, because "skip verification" caused by Urlprotocol or certificate cache can be defended

Iv. Negative effects

1. Increased network access time by no longer using the handshake of the Access party

2. Increased communication time for a forged URL access

About the experience sharing of HTTPS forced handshake in iOS SDK