Per the disclosure of the POODLE vulnerability, Google makes the following statement:
In order to work around bugs in HTTPS servers, browsers will retry failed connections with older protocol versions, including SSL 3.0
Is this also true of the DefaultHttpClient Java library and the Objective C NSURLConnection class? I believe the answer is "no", but I wanted to double-check.
Editing my answer entirely after some more testing, both HttpUrlConnection and NSURLConnection appear to retry failed TLS connections with older SSLv3 connections. For better or mostly worse, this is intentional functionality for backwards compatibility with incorrectly configured servers and is documented in most of the reference docs in most places or you have to dig through the native code source. My original post was incorrect in that I never traced the Oracle change to resolve this issue into the native Android code. http://www.oracle.com/technetwork/java/javase/overview/tlsreadme2-176330.html
Some documentation:
HttpUrlConnection
TLS Intolerance Support
This class attempts to create secure connections using common TLS extensions and SSL deflate compression. Should that fail, the connection will be retried with SSLv3 only.
OkHttp
OkHttp initiates new connections with modern TLS features (SNI, ALPN), and falls back to SSLv3 if the handshake fails.
All that said I think the ability to set a minimum allowed TLS version in iOS and the ability to specify supported protocol versions in Android respectively really makes this somewhat of a non-issue in apps.
iOS Example: https://developer.apple.com/library/mac/documentation/Foundation/Reference/NSURLSessionConfiguration_class/index.html#//apple_ref/occ/instp/NSURLSessionConfiguration/TLSMinimumSupportedProtocol
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With