[GRADLE-3250] Gradle using old HTTPClient lib that doesn't support SNI Created: 02/Mar/15  Updated: 10/Dec/15  Resolved: 10/Dec/15

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: 2.11-rc-1

Type: Bug
Reporter: Gradle Forums Assignee: Unassigned
Resolution: Fixed Votes: 4


 Description   

When using Gradle to build app that contains maven artefacts stored on HTTPS servers with wildcard certificates, then this error shows: hostname in certificate didn't match .
It seams that Gradle is using Apache HttpClient library 4.2.2 which does not support SNI extensions ([1]http://en.wikipedia.org/wiki/Server_N...).
SNI extensions have been added in HttpClient library 4.3.2.

To make possible use of Gradle on HTTPS servers which use SNI, Apache HttpClient library should be upgraded to a newer version.
----------------------------------------------------------------------------------------
[1] http://en.wikipedia.org/wiki/Server_Name_Indication



 Comments   
Comment by Gradle Forums [ 02/Mar/15 ]

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

Comment by Gradle Forums [ 02/Mar/15 ]

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.

Comment by Richard Bergoin [ 08/Apr/15 ]

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 :

NTLMSchemeFactory.java
    public static void register(DefaultHttpClient httpClient) {
        httpClient.getAuthSchemes().register("ntlm", new NTLMSchemeFactory());
    }

And now in org.apache.http.impl.client.HttpClientBuilder :

HttpClientBuilder.java
        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

AuthSchemes.java
    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

Comment by Richard Bergoin [ 13/Apr/15 ]

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 :

https://github.com/apache/httpclient/blob/ca956c1b90e8f642439a8bbcf72d8322bda39f05/httpclient/src/main/java/org/apache/http/impl/auth/NTLMScheme.java

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 ?

Comment by Sterling Greene [ 13/Apr/15 ]

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

Comment by Axel Fontaine [ 01/Jun/15 ]

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.

Generated at Wed Jun 30 12:43:55 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.