SNI support

[bemasc]

My app was experiencing timeouts when connecting to some domains. To make a reduced testcase, I started with the 'TCP secure get https website three times' test (https://github.com/MobileChromeApps/cordova-plugin-chrome-apps-sockets-tcp/blob/master/tests/tests.js#L793). Running that test on my Nexus 5X, by clicking the "Run" button in the test app with only chrome-sockets-tcp selected, I see flakiness, with maybe an 80% success rate. (The second run in particular seems to fail frequently.) I modified the target domain from httpbin.org to a0.awsstatic.com, and saw similar results. However, when I changed the target domain to sdk.amazonaws.com, I saw 100% failure.

In the last case, I set breakpoints to locate the failure. It appears that chrome.sockets.tcp.secure() never calls its callback, resulting in a test timeout.

The flakiness of the test does not seem surprising. In particular, any nagling or similar aggregation would break the recvCounter mechanism. However, I'm not aware of any difference between the a0.awsstatic.com and sdk.amazonaws.com domains that would logically explain the difference in behavior. (Both domains are hosted on Amazon Cloudfront, so they should behave almost identically.)

The only difference I've been able to find between these domains is that sdk.amazonaws.com is defined by a CNAME record, whereas a0.awsstatic.com is defined by an A record. The extra DNS lookup and secondary name should not be a problem, but perhaps a buggy TLS client could fail in this case.

[bemasc]

By debugging the unit tests when pointed to sdk.amazonaws.com, I've found that the failures occur after finishConnect() succeeds, but the SSL handshake fails. Debugging revealed that the server replies with 7 bytes before closing the socket: 21, 3, 3, 0, 2, 2, 40. Reading the TLS specification, I've determined that this is

21 // ContentType = alert
3 // ProtocolVersion = 3,3 (TLS 1.2)
3
0 // length = 0,2 (2 bytes)
2
// Alert:
2 // AlertLevel = 2 (fatal)
40 // AlertDescription = 40 (handshake_failure)

I don't yet know what is causing the handshake failure.

[bemasc]

After tracing this deeper, I'm now convinced that the issue is a lack of SNI (Server Name Indication). Chrome's sockets API always includes SNI when connecting to a domain by name. This plugin never includes SNI ... understandably, since the requisite method is only now being introduced in API 24 (Android N). The servers where this fails appear to require SNI.