[
https://jira.codehaus.org/browse/MNG-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317745#comment-317745
]
James Kionka commented on MNG-5363:
-----------------------------------
Gili, the link in your comment on 23/Dec/12 2:26 PM is correct. Hendy, I agree,
all the SSL error messages I've seen are pretty terrible.
This ticket is more or less independent of deploying to oss.sonatype.org. Based
on the error description and attempted fixes on the stackoverflow page, it
sounds almost exactly like this problem. The one part that does not make sense
is that their deployments failed only sometimes. Our problem is repeatable. I
figured their problem was intermittent from a load balancer which was sometimes
sent the client to an SSLv3 server. However, based on Roberto's comments and
the current evidence, these problems are not related as it originally seemed.
Our team at work was able to handle the Java SSLv3 issues for
java.net.URLConnection using:
-Dhttps.protocols="SSLv3"
or
System.setProperty("https.protocols", "SSLv3");
This how we worked out the issue before Maven made the switch to HttpClient in
3.0.4. HttpClient does not respect this setting.
When we use HttpClient in our other projects, we have a method named
getSslv3SocketFactory() which creates a generic SocketFactory with the method
on it.
private void setSslv3Protocol(SSLSocket sslSocket) {
sslSocket.setEnabledProtocols(new String[] { "SSLv3" });
}
We then create ThreadSafeClientConnManager using our SocketFactory.
(Apparently, it is now called PoolingClientConnectionManager.)
How to create that object is explained in "2.8.4. Pooling connection manager":
https://hc.apache.org/httpcomponents-client-ga/tutorial/html/connmgmt.html
Javadoc for PoolingClientConnectionManager:
https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/conn/PoolingClientConnectionManager.html
This is obviously a frustrating solution, but there were no other options. Part
of life is that web browsers handle SSL better than Java, and HttpClient did
not feel like this was something they'd like to make easy.
Some more background is available at:
http://stackoverflow.com/questions/2159586/jsse-handshake-failure-on-public-https-web-site
http://docs.oracle.com/javase/1.4.2/docs/guide/plugin/developer_guide/faq/troubleshooting.html
http://httpcomponents.10934.n7.nabble.com/Fwd-Httpclient-sslv3-amp-bad-record-mac-error-td16136.html#a21999553
Maven could really use a way to specify what https protocols to respect, one
way or another, since there is currently no way to do so as of 3.0.4. This
could be done in a lot of different ways, but respecting the System Property
seems like a clean solution to me at this time.
> Regression for SSLv3
> --------------------
>
> Key: MNG-5363
> URL: https://jira.codehaus.org/browse/MNG-5363
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Errors
> Affects Versions: 3.0.4
> Environment: Operation system independent, but tested on Macbook Pro
> with 10.6 and Red Hat Enterprise Linux 6 on a virtual machine.
> Reporter: James Kionka
> Priority: Critical
>
> When attempting to access a Maven repository which uses SSLv3, you get the
> following error, "javax.net.ssl.SSLException: Received fatal alert:
> bad_record_mac".
> Earlier versions of Maven used java.net.URLConnection which respects the
> https.protocols system property. This allowed us to set it to SSLv3, which is
> what our Maven repository uses. However, HttpClient ignores that property. In
> other situations, we programmatically tell HttpClient to use SSLv3, which we
> cannot do from our end.
> You can find another person in the same situation here:
> http://stackoverflow.com/questions/12787657/received-fatal-alert-bad-record-mac-when-deploying-to-sonatype
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
