Mobile Internet network condition is very complex, the three major operators, 3 g, 4 g, wi-fi, places such as any state changes will lead to the change of network conditions, and operators, agents in which could also make a few small damage, such as often there will be a user feedback said that a page can’t visit or return the result is not correct, In this case, domain name hijacking usually occurs. The common solution is to use IP direct connection to bypass the carrier’s LocalDNS server resolution process, thus reducing latency and avoiding hijacking.

Why IP

Why do people choose to connect directly to IP? It has many advantages:

  • Anti-hijacking: Bypasses the carrier’s LocalDNS resolution process, avoiding domain name hijacking and improving the success rate of network access

  • Reduce latency. DNS resolution is a time-consuming task, so skipping this process can reduce some latency

  • In precise scheduling, the nodes returned by the operator may not be optimal. The operator can obtain the most accurate and optimal nodes based on its own policies when obtaining IP addresses by itself

For obtaining IP, I have learned that there are two schemes: one is to directly access the HTTPDNS service of Tencent or Ali, and then directly use the IP to access services when initiating requests. One is the built-in Server IP address. The Server can deliver the corresponding list of domain names and IP addresses during startup, and the client can cache the domain names and IP addresses. When initiating network requests, the client can directly access services based on the cache IP address.

HTTPS & DNS hijacking

At first I was a bit skeptical, why does HTTPS still have DNS hijacking? HTTPS ensures network security from three aspects of identity authentication, content encryption, and tampering prevention. However, its timing is relatively late. DNS resolution is the first step of network Request. Therefore, HTTPS has no protection against DNS hijacking, but client authentication can be used to avoid the occurrence of AD cancellation, such as direct access failure after hijacking.

The identity authentication

In HTTPS networks, we authenticate the server. For example, AFNetworking provides three authentication options:

  • AFSSLPinningModeNone(Default)

  • AFSSLPinningModePublicKey

  • AFSSLPinningModeCertificate

For AFSSLPinningModeNone, the client will not verify the server certificate by itself, but will directly default the trust, and give the certificate to the system for verification to determine whether the returned certificate is issued by the official authority. If so, it will trust, which should be the most commonly adopted scheme by common developers. If the certificate returned by the hijacked authentication scheme is also issued by the official authorities, then the client will normally access the network, but the returned data is not the desired data, such as the occurrence of the phenomenon of advertising is cancelled.

For AFSSLPinningModePublicKey, AFSSLPinningModeCertificate two options, the client will usually keep a local server certificate, AFSSLPinningModePublicKey on behalf of the client certificate and returned by the server will be saved locally PublicKey part of the certificate of calibration independently, AFSSLPinningModeCertificate on behalf of the client certificate and returned by the server will be saved locally in the certificate all content, including PublicKey parts and certificate are all check independently. If the verification succeeds, perform subsequent operations, such as system verification.

HTTP IP Connect

Although Apple has been promoting ATS for a long time, it still supports HTTP network requests due to the complicated network situation in China, and the proportion of network requests under THE HTTP protocol is also large. The implementation of HTTP IP connection is actually very simple, we just need to intercept the network request through the NSURLProtocol, and then change the domain name in the symbolic condition of the network request URL to IP.

However, there are also some minor problems. After the domain name is replaced with IP, the server cannot determine which domain name you want to visit according to the URL. Therefore, we need to manually insert the host field into the header to facilitate the correct identification of the server.

HTTPS IP Connect

HTTPS is one more TLS handshake process than HTTP. This process involves a certificate verification problem. The server will return a certificate during the second handshake so that the client can verify its identity and avoid impersonation. During the verification, the system checks whether the domain of the certificate contains the host of the Request and whether the returned certificate is a trusted certificate issued by an official authority. Since the IP connection will replace the domain name in the URL with IP, the returned certificate will fail to verify our Request.

To solve the problem of certificate verification, we need to replace the domain name again before certificate verification. This time, we need to replace the IP address in the URL with the domain name. In this way, the problem of certificate verification can be solved easily.

SNI IP Connect

Normally our certificate is binding and domain name, sometimes there is a corresponding multiple domain name, IP this situation if the client IP directly connected, he didn’t tell the server to request which is domain name certificate, the server can’t return the correct certificate, leading to a client certificate validation failure.

Indication, an SSL/TLS extension for a Server that uses multiple domain names and certificates. When connecting to the server to establish an SSL connection, the Client can enter the domain name of the site to be visited (Hostname) in the SNI extended field of Client Hello for the first handshake so that the server can return an appropriate certificate based on the domain name.

To sum up, in the case of single IP address and multiple domain names, the client needs to manually configure the SNI field when we conduct DIRECT IP connection. However, the upper network library NSURLSession and NSURLConnection do not provide interfaces for configuration. We need to use the lower-level libcurl library and CFNetwork to complete the SNI field configuration. Using CFNetwork as an example, you can use the following code to configure SNI.

/ / HTTPS request processing SNI scene nsstrings * host = [self. SwizzleRequest. AllHTTPHeaderFields objectForKey: @"host"];
if(! host) { host = self.originalRequest.URL.host; } [self.inputStreamsetProperty:NSStreamSocketSecurityLevelNegotiatedSSL forKey:NSStreamSocketSecurityLevelKey];
NSDictionary *sslProperties = @{ (__bridge id) kCFStreamSSLPeerName : host };
[self.inputStream setProperty:sslProperties forKey:(__bridge_transfer NSString *) kCFStreamPropertySSLSettings];

Copy the code

Write in the last

In fact, IP direct connection has been numerous articles, this is just a study practice notes, more relevant information and code WILL be given at the end. NSURLProtocol and IP direct connection have many points to pay attention to, such as NSURLProtocol intercepts THE POST request to get httpBody empty, Cookie handling, WebView handling, etc. Some knowledge I do not practice, but you can find the corresponding solution in the reference article.

reference

  • Probably the most complete iOS HttpDns integration solution
  • DNS pollution scheme investigation
  • HTTPDNS in iOS practice
  • Mobile resolution HTTPDNS in App development practice summary
  • Also talk about HTTPS – HTTPDNS + HTTPS
  • How do I use cookies in HTTPDNS domain name resolution scenarios?
  • Ari Cloud related best practices
  • Server Name Indication (SNI)