[
https://issues.apache.org/jira/browse/BUILDS-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14702810#comment-14702810
]
Dennis Lundberg commented on BUILDS-85:
---------------------------------------
Thanks for the feedback [~pctony]. I understand fully that you (Infra) are
tasked with keeping our infrastructure as secure as possible, and for that we
are grateful.
The problem at hand is straight-forward, and fortunatelly the solution is too.
Problem:
When using a Java-based tool (i.e. a build tool like Ant or Maven) the user
cannot control which ciphers it should use. This is only possible if you write
your own client. Many projects here at ASF base their software on Java and use
Ant or Maven as a build tool. The changes that were made to the SSL proxy means
that some of these projects, those that still build software that works on Java
6, are no longer able to do automated releases using the build tools of their
choice. I will not get into an argument about whether Java 6 is dead or not,
cause this is not the place for such a discussion.
Solution:
There is a solution to this that does not lower the cipher security levels IMO.
There is a cipher among the ones available on the SSL proxy that Java 6 based
clients can use: TLS_RSA_WITH_AES_128_CBC_SHA. The problem is that there are
other ciphers that are prefered by the server so they are used instead. The
problematic ones are those that non-EC diffie hellman, i.e. the ones prefixed
TLS_DHE_. They are problematic because they use a larger parameter size than
Java 6 can handle. It seems that the parameter size is not something that is
used in the negotiation of which cipher to use. One way to enable Java 6 based
build tools to once again communicate with the services that use the SSL proxy
is to remove those ciphers from the SSL proxy.
> Could not generate DH keypair / peer not authenticated
> -------------------------------------------------------
>
> Key: BUILDS-85
> URL: https://issues.apache.org/jira/browse/BUILDS-85
> Project: Infra Build Platform
> Issue Type: Bug
> Components: Jenkins
> Reporter: Andreas Lehmkühler
> Assignee: Tony Stevenson
> Attachments: SSLPoke.java
>
>
> We're getting this since june 10th:
> [INFO] --- maven-deploy-plugin:2.6:deploy (default-deploy) @ pdfbox-parent ---
> Downloading:https://repository.apache.org/content/repositories/snapshots/org/apache/pdfbox/pdfbox-parent/1.8.10-SNAPSHOT/maven-metadata.xml
> [WARNING] Could not transfer metadata
> org.apache.pdfbox:pdfbox-parent:1.8.10-SNAPSHOT/maven-metadata.xml from/to
> apache.snapshots.https
> (https://repository.apache.org/content/repositories/snapshots): Error
> transferring file: java.lang.RuntimeException: Could not generate DH keypair
> and this:
> [INFO] --- maven-deploy-plugin:2.8.2:deploy (default-deploy) @ pdfbox-parent
> ---
> Downloading:https://repository.apache.org/content/repositories/snapshots/org/apache/pdfbox/pdfbox-parent/2.0.0-SNAPSHOT/maven-metadata.xml
> [WARNING] Could not transfer metadata
> org.apache.pdfbox:pdfbox-parent:2.0.0-SNAPSHOT/maven-metadata.xml from/to
> apache.snapshots.https
> (https://repository.apache.org/content/repositories/snapshots): peer not
> authenticated
> The issue seems to be jdk related as only those builds using java 1.6.0_37
> (unlimited security) are failing. I've reconfigured the trunk build to use
> java 7 and everything works fine, as well as our jdk7 based branch build.
> Any ideas? Maybe a plugin update which doesn't work with java6?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
