How to know in IOS 9 which version of TLS is used

Hi,


I have upgraded my server with Jetty 9.3 to enable HTTP/2.

My App is using NSURLSession, is there a way to retreive from the response the TSL version that has been used with the server?

Replies

There’s no way to get the TLS version that was used for a particular HTTP transaction. This would make a fine enhancement request for NSURLSessionTaskTransactionMetrics.

If you want to find out the version of TLS used on a one-off basis, you can look at a packet trace. See QA1176 Getting a Packet Trace for references to various packet trace tools.

If you want to force a particular TLS version to be used, you can do this in two ways:

  • If you don’t disable App Transport Security (ATS) for your server, it will enforce TLS 1.2 (or later, if and when such a standard is published and Apple’s OSes support it).

  • You can also pin the minimum and maximum TLS versions by setting the

    TLSMinimumSupportedProtocol
    and
    TLSMaximumSupportedProtocol
    property in the NSURLSessionConfiguration you use to configure your session.

It’s very likely that any server that supports HTTP/2 will also support TLS 1.2, so pinning the minimum TLS version isn’t a bad idea.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Hi eskimo

I am checking the impact on iOS app upon decommission of TLS 1.0/TLS 1.1 & commission TLS 1.2 on server side.


Before adding support for TLS 1.2 on server side, I am assuming "URLSessionConfiguration.default.tlsMinimumSupportedProtocol = SSLProtocol.tlsProtocol12"; is the only way we can test its impact on iOS app(both URLSession/NSURLConnection & WKWebView/UIWebView). Could you please confirm the same. Also let me know if there is another way to do that.


After adding support for only TLS 1.2(removing TLS1.0 & TLS1.1) on server side(www.nist.gov, https://github.com & https://fancyssl.hboeck.de) I tried to load the page in WKWebView by setting "URLSessionConfiguration.default.tlsMaximumSupportedProtocol = SSLProtocol.tlsProtocol11" but seems like it works. My expectation was it should not work.(Tried it on iOS 8 Simulator with iOS 11.2)

Thanks

Anand

Hmmm, there’s a lot of things to consider here:

  • This code:

    URLSessionConfiguration.default.tlsMaximumSupportedProtocol = SSLProtocol.tlsProtocol11

    is not valid.

    URLSessionConfiguration.default
    returns a new instance of the default configuration each time you call it, so all you’re doing here is modifying that instance.
  • Similarly, you can’t do something like this:

    URLSession.shared.configuration.tlsMaximumSupportedProtocol = SSLProtocol.tlsProtocol11

    While the code compiles, it won’t work. The session latches its configuration when you create it, so trying to alter the configuration afterwards is not supported.

  • Combined these mean that it’s not possible to change configuration parameters of the shared session.

  • There’s no connection between

    URLSession
    configurations and
    WKWebView
    .
    WKWebView
    does its networking in a separate process, and you won’t be able to alter its TLS configuration by changing
    URLSession
    parameters in your process.
  • As far as I know,

    WKWebView
    has no way to programmatically set its TLS parameters. The only TLS configuration option I’m aware of is provided by App Transport Security (ATS). See my App Transport Security pinned post for links to the docs.
  • If you want to test that your server configuration is correct, there’s a variety of ways to do that:

    • Various third-party web sites will inspect your TLS configuration for you.

    • You can talk to the server via

      URLSession
      . If you create a custom session you can override the TLS settings on that session via the
      URLSessionConfiguration
      you use to create the session.
    • You can poke at it with TLSTool

    Note TLSTool is sample code, which you can download from here

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thank you eskimo for quick reply.


To summerize,

1) Don't use URLSession.shared if customized URLSessionConfiguration required

2) WKWebView runs in separate process & respects the setting from info.plist. URLSessionConfiguration provided to instance of URLSession has no effect on WKWebView


Correct me if I am wrong

1) "Both UIWebView & WKWebView respect setting from info.plist"

- I have verified by setting Allow arbitory load = NO & tried loading https://www.vbhc.com(Only TLS1.0 supported) ,https://github.com(Only TLS1.2 supported). Verified in iOS 9.0 Simulator

2) There is no setting on NSURLConnection. It will by default try negotiating with server starting from TLS1.2, TLS1.1, TLS1.0 in that order

3) As long as URLSession.shared is used or customized URLSessionConfiguration is used without setting tlsMaximumSupportedProtocol, removing TLS1.0 & TLS 1.1 support and adding TLS 1.2 on serve will not fail handshake.

1) "Both UIWebView & WKWebView respect setting from info.plist"

Correct.

2) There is no setting on NSURLConnection

Not quite.

NSURLConnection
has no programmatic way to configure the TLS version in use, but it will honour the App Transport Security (ATS) settings in the
Info.plist
.

It will by default try negotiating with server starting from TLS1.2, TLS1.1, TLS1.0 in that order

The exactly sequence used by

NSURLConnection
is not documented but it should be something similar to this.

3) As long as URLSession.shared is used or customized URLSessionConfiguration is used without setting tlsMaximumSupportedProtocol, removing TLS1.0 & TLS 1.1 support and adding TLS 1.2 on serve will not fail handshake.

Correct. To understand what’s going on here you need to know a little bit about the TLS handshake process. Here’s a rough summary:

  1. The client sends a Client Hello message with the maximum TLS version that it supports.

  2. If that version is too low for the server, the server fails the connection.

  3. Otherwise the server sends a Server Hello message with the maximum version that it’s prepared to support.

  4. If that version is too low for the client, it fails the connection.

So in your scenario the client will ask for TLS 1.2, the server will accept that, and the negotiation will succeed.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thanks you eskimofor the support.