Gradle can't access Maven repos over TLS servers using SNI

Bugs
1

Hi everyone, my first post here.

I’m using Gradle 2.8rc1 with some dependency from a private maven repos. The build.gradle looks like:

    maven {
        url "https://foo.example.com/maven"
    }

This should work fine. The problem is that foo.example.com is secured with TLS1.2 including SNI. This is causing the following result:

hostname in certificate didn't match: <foo.example.com> != <example.com> OR <example.com> OR <www.example.com>

Which is caused by:

Caused by: javax.net.ssl.SSLException: hostname in certificate didn't match: <foo.example.com> != <example.com> OR <example.com> OR <www.example.com>
	at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:228)

Looking into it some more, I’m 99% sure this is caused by using Apache HttpClient version prior to 4.3.2, and is due to this bug. I confirm that Gradle 2.8rc1 is using httpclient-4.2.2.jar, so it is impacted by that bug and cannot access SNI sites correctly.

Can anyone confirm if this is what is going on, and if so, I believe that this is a bug which should be fixed prior to release of Gradle 2.8, due to the wide use of SNI at this point. I believe the fix is simply upgrading to a more recent HttpClient.

Thanks

2

This is a known issue, tracked as GRADLE-3250. We’re tentative to simply upgrade HttpClient versions as it may introduce regressions for some functionality like NTLM and Kerberos support that we are currently lacking adequate test coverage for.

3

Thank you Mark. That’s exactly it, and there’s a full discussion of it. I agree with comment at the end of the bug. TLS is normal these days, and is essential for important things like build artifacts, and everyone is now using SNI. I hope Gradle will consider this as a high-priority fix for 2.8. I had to reconfigure my web server to carve out a build artifacts directory that it will serve as non-TLS. It’s no big deal to configure but turning off encryption is always a step backwards.

4

I just want to clarify that the version of HTTP client we are on does in fact support TLS, just not the SNI extensions. If you have the ability to reconfigure the webserver you are hosting your artifacts from you might consider using a single combination of (IP address, hostname, SSL certificate) to get around this problem rather than resorting to disabling TLS entirely.

5

Hello,

We’re experiencing the same issues, but when publishing artifacts to the maven repository.
Our server relies on SNI to correctly determine which certificate to present.

It looks like Gradle is using 2.4 of the wagon libraries, which in turn uses 4.2.3 of org.apache.httpcomponents. Support for SNI was added in version 4.3.2.

This is via the Maven plugin which we use via gradle-nexus-plugin (but the result should be the same by using the Maven plugin’s uploadArchives directly).

Any chance we can look at upgrading this? SNI has been available since 2004 and isn’t exactly a new technique.

6

(Since I’m only allowed to put 5 links in one post, this a continuation on above…)

For some reason the Maven plugin uses apache http client via wagon, so the fixes in gradle version 2.11 regarding this does not solve this issue. We can however correctly pull artifacts.

As a work-around, we’re putting -Dmaven.wagon.http.ssl.insecure=true -Dmaven.wagon.http.ssl.allowall=true in our gradle command, which is not good for obvious reasons.

7

This is correct. You can however use the maven-publish plugin which does take advantage of the upgrade to HttpClient 4.4.1 in 2.11.

8

Changing to the maven-publish-plugin require quite some changes for us.
Do you not want to update the wagon dependencies?

9

Upgrading these libraries is definitely a possibility. Would you consider contributing a pull request for this?

10

I tried, and it is not trivial (i.e… just updating the version wasn’t enough, it complained about classes not existing when I tried to compile it. Didn’t dig any deeper.). I don’t think I’ll have time anytime soon :frowning:

11

For the record, we tried to update to the new maven-publish plugin, but that doesn’t support signing artifacts yet,which is required by the maven repository we have. Hence we have no option but to disable host verification in the Maven plugin.