Do Apache DefaultHttpClient (Android) and NSURLConnection (iOS) connections repeat failed connections with older versions of the protocol?

Regarding the disclosure of the POODLE vulnerability, Google makes the following expression :

To bypass errors on HTTPS servers, browsers will retry unsuccessful connections with older versions of the protocol, including SSL 3.0

Does this also apply to the DefaultHttpClient Java library and the Objective-C class of NSURLConnection ? I think the answer is no, but I wanted to double check.

+6
source share
1 answer

Editing my answer completely after some testing, both the HttpUrlConnection and NSURLConnection seem to repeat the failed TLS connections with the old SSLv3 connections. For improvement, or mostly worse, this is deliberate functionality for backward compatibility with improperly configured servers and is documented in most reference documents in most places or you need to scan the source code. My original post was wrong in that I never tracked Oracle changes to solve this problem in the Android source 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 I said that the ability to set the minimum acceptable version of TLS in iOS and the ability to specify supported protocol versions in Android, respectively, really makes this somewhat unrelated to the problem in applications.

IOS example: https://developer.apple.com/library/mac/documentation/Foundation/Reference/NSURLSessionConfiguration_class/index.html#//apple_ref/occ/instp/NSURLSessionConfiguration/TLSMinimumSupportedProtocol

+4
source

Source: https://habr.com/ru/post/976791/


All Articles