Here is the duplication of this issue with some additional links [1]http://forums.gradle.org/gradle/topic....
We are also affected by this :/
----------------------------------------------------------------------------------------
[1] http://forums.gradle.org/gradle/topics/gradle-does-not-support-maven-repositories-with-sni-implemented
We've needed to update HttpClient for other reasons, but there are some changes to the HttpClient API that may break our NTLM integration. We don't have much code coverage for it, so the real work is making sure nothing breaks.
I think we had looked at updating to the latest, so if there's an older version (e.g., 4.3.2) that doesn't have as large of an impact and fixes your problems, I think a PR would be welcome if it can show that NTLM still works.
The 5 Feb 2015, https://hc.apache.org/news.html :
Native Windows Negotiate and NTLM via SSPI through JNA: when running on Windows OS HttpClient configured to use native NTLM or SPNEGO authentication schemes can make use of platform specific functionality via JNA and current user credentials. This functionality is still considered experimental, known to have compatibility issues and subject to change without prior notice.
I've just successfully updated httpclient to 4.4.1 (and added httpclient-win for being able to use WindowsCredentialsProvider class).
There are some deprecations, like the SystemDefaultHttpClient (which extends DefaultHttpClient) in favor of HttpClientBuilder :
https://github.com/apache/httpclient/search?utf8=%E2%9C%93&q=SystemDefaultHttpClient
And the brand new org.apache.http.impl.client.HttpClientBuilder (since 4.3) is now responsible for "HttpClient" instanciations. It manages UserAgent, credentials, authScheme...
AuthSchemes that were previously managed in org.gradle.internal.resource.transport.http.ntlm.NTLMSchemeFactory :
public static void register(DefaultHttpClient httpClient) {
httpClient.getAuthSchemes().register("ntlm", new NTLMSchemeFactory());
}
And now in org.apache.http.impl.client.HttpClientBuilder :
Lookup<AuthSchemeProvider> authSchemeRegistryCopy = this.authSchemeRegistry;
if (authSchemeRegistryCopy == null) {
authSchemeRegistryCopy = RegistryBuilder.<AuthSchemeProvider>create()
.register(AuthSchemes.BASIC, new BasicSchemeFactory())
.register(AuthSchemes.DIGEST, new DigestSchemeFactory())
.register(AuthSchemes.NTLM, new NTLMSchemeFactory())
.register(AuthSchemes.SPNEGO, new SPNegoSchemeFactory())
.register(AuthSchemes.KERBEROS, new KerberosSchemeFactory())
.build();
}
The ntlm will now be uppercase, as defined in org.apache.http.client.config.AuthSchemes
public static final String NTLM = "NTLM";
Big changes will be in org.gradle.internal.resource.transport.http.HttpClientConfigurer :
Use of an HttpClientBuilder in configure (renamed to createAndConfigureClient) and now returns a HttpClient instead of receiving it as a parameter from constructor of org.gradle.internal.resource.transport.http.HttpClientHelper.
I know have to create a "NTLM test", run it with current codebase, and see if it still passes with the changes done.
Then I'll make a PR with these changes.
Related httpclient issue is at https://issues.apache.org/jira/browse/HTTPCLIENT-1119
No luck, for testing I need httpclient 4.4 
to be able to use ServerBootstrap
My idea is to add an integration test that checks if the three exchange for NTLM auth are correct, based on :
But I will first only update to 4.4 for this test, make it green. And then patch the HttpClientHelper.
I think there will be two commits, or better, first send an "incomplete" PR (adding the test), and then updating the PR that will include modifications of HttpClientHelper. Doing this will make continuous integration do its job, isn't it ?
Hey Richard!
Would you mind replying to this email chain? https://groups.google.com/forum/#!topic/gradle-dev/RxmS3j2aD8w
We ask everyone to also sign a CLA. You can read more about the process here: http://discuss.gradle.org/t/developer-guidelines/108
The version of the HttpClient used by Gradle is now 2 years old. Forcing people to fall back to plain http for something as critical as artifacts that will end up on production systems just doesn't make sense in 2015. SNI and modern TLS support is a must in this day and age. Fixing this should be a high priority if you value the security of your users.