Community
Participate
Working Groups
Build ID: M20070921-1145 Steps To Reproduce: 1. Connect to a trac server at an https URL (that uses a self-signed SSL cert) 2. Enter username and password 3. Click on "Validate Settings" 4. It'll say "No Trac repository at URL" 5. Tick open "Additional Settings" 6. Try XML-RPC. 7. Click on "validate settings" 8. See the message: No Trac repository found at url: I/O error while communicating with HTTP server: Received fatal alert: bad_record_mac 9. Try Web 10. Click on "validate settings" 11. See the message: No Trac repository found at url: Received fatal alert: bad_record_mac More information: This (bad_record_mac) is a common problem with HTTPClient, as far as I can tell. There's no built in way to import the ssl certificate, and, as far as I can tell, there's no cert repository that is used by httpclient (I've tried to import the site's cert using the Java Control Panel, with no luck). I've read that it's possible to use HTTPClient in such a way that it does allow self-signed certs somehow, but I'm not completely sure how to do this. By the way, I see the same error message with Subclipse if I use the "pure Java" SVN client, and so must use the the "JavaHL" JNI interface to the native svn client.
Mylyn should accept all certificates by default. This is an error that hints at a communication problem between your host and the server. Could you please try to connect to this repository https://mylyn.eclipse.org/tractest to verify that?
(In reply to comment #1) > Mylyn should accept all certificates by default. This is an error that hints at > a communication problem between your host and the server. Could you please try > to connect to this repository https://mylyn.eclipse.org/tractest to verify > that? OK, your site does work for me. I wonder why the site I'm using is failing, then? svn commandline and firefox both load the site up fine. BTW, our site does _not_ allow anonymous access. Every connection must be authenticated. Is there anything I can do to provide better debugging details?
From a quick web search that could be related to the SSL versions supported by your server. It could be that Java tries to communicate using an older version such as v2 but your server only supports v3. Could you check on the server which SSL ciphers and versions are enabled?
(In reply to comment #3) > From a quick web search that could be related to the SSL versions supported by > your server. It could be that Java tries to communicate using an older version > such as v2 but your server only supports v3. Could you check on the server > which SSL ciphers and versions are enabled? We're running an apache2 server with just SSLv3 enabled (this is from our apache2 conf for the ssl site: SSLEngine on ... SSLProtocol -all +SSLv3 SSLCipherSuite SSLv3:+HIGH:+MEDIUM I can switch add in SSLv2 and see what happens to Mylyn.
(In reply to comment #4) > SSLProtocol -all +SSLv3 If I change this to SSLProtocol -all +SSLv2 +TLSv1 and mylyn works. So I guess this bug could be retitled to, "Mylyn does not support SSLv3 encryption for https" or similar.
Thanks for verifying. I can reproduce that problem with our server when I only enable SSLv3. Mylyn relies on the JDK for its SSL support. Which operating system and java version are you using? If I add this line to SslProtocolSocketFactory.createSocket() it works (disabling TLSv1 support): ((SSLSocket)socket).setEnabledProtocols(new String[] { "SSLv3", "SSLv2Hello" }); Rob, any thoughts? We could potentially detect the exception and try a different protocol set as a fallback?
I have verified that this problem occurs on Java 1.5.0_13 as well as on 1.6.0_03 on Linux.
(In reply to comment #6) > Mylyn relies on the JDK for its SSL support. Which operating system and java > version are you using? Ubuntu 7.10 with the latest sun-java6-jdk as packaged in the Ubuntu multiverse (6-03-0ubuntu2, with "java -fullversion"=1.6.0_03-b05)
(In reply to comment #6) is line to SslProtocolSocketFactory.createSocket() it works > Rob, any thoughts? We could potentially detect the exception and try a different > protocol set as a fallback? Sounds right to me but should we only support as low as SSLv3 for security reasons?
(In reply to comment #5) > (In reply to comment #4) > > SSLProtocol -all +SSLv3 > > If I change this to > SSLProtocol -all +SSLv2 +TLSv1 Just going back over this bug due to the recent comment. that should read "SSLProtocol -all +SSLv3 +TLSv1" In other words, the client required the server to be serving https with TLSv1. SSLv2 needn't be supported, but SSLv3 probably should work out of the box, no?
Is there any chance this can be fixed soon? I've got Fedora Core 10 server that my mylyn has trouble with. If I enable TLSv1, then Firefox 3 on Linux and Windows can't connect to the server with an error: ssl_error_rx_unexpected_change_cipher (which apparently is due to some openssl bug on the client side). I really want to use Mylyn to connect to this trac repository, but am unable to due to this improper handling of SSLv3.
(In reply to comment #11) > Is there any chance this can be fixed soon? I've got Fedora Core 10 server that > my mylyn has trouble with. If I enable TLSv1, then Firefox 3 on Linux and > Windows can't connect to the server with an error: > ssl_error_rx_unexpected_change_cipher (which apparently is due to some openssl > bug on the client side). I really want to use Mylyn to connect to this trac > repository, but am unable to due to this improper handling of SSLv3. HI all, Adding my voice : we use a hosted svn/trac service. Just a few days ago, this host upgraded apache to 2.2.14. For some reason, this upgrade has force him to force sslv3 only. This has broken my Mylin/Trac connection, with the exact same description as posted by the OP (in 2007!). I am not sure however this has to do with jre (jre6 here), as I can browse and commit to our svn repo on the very same server. Any suggestion, things I could try, information I can look for ? Thanks and best regards
Couldn't we just fix this bug by catching the SSLException saying "Received fatal alert: bad_record_mac"? Then we reconfigure the socket ("socket.setEnabledProtocols(new String[] {"SSLv3"})") and try again! I think, it is save to do that!
... a better solution might be: Server-wise configuration of SSL options in the Mylyn Preferences section (Window->Preferences). There, one could configure SSLv3-only servers. I could do that and provide a patch, if you promise to commit it :-)
Yes, we could a (per task repository) configuration option although I would prefer not to expose technical details of this sort to users. On the other hand, Firefox and Chrome allow configuration of the supported protocols and only select SSL v3 and TLS v1 by default. Andre, I would consider accepting a patch that added the configuration UI in a well hidden place and preferably did the right thing during validation. I'll bring this up on the next Mylyn meeting to get some feedback from other committers.
We discussed this and came up with the following suggestion: * Add UI under Additional Settings for selecting SSL protocols * If validation fails with the described error, automatically unselect TLS
Should this work in the most recently released version of Mylyn yet? I'd really like to get at my trac instances that are on an apache server that only accepts SSLv2 and SSLv3. Right now I get the error: Received fatal alert: bad_record_mac
No, the work has not been started, yet. Andre, would you be interested in providing a patch for the changes proposed in comment 16?
(In reply to comment #18) > No, the work has not been started, yet. Andre, would you be interested in > providing a patch for the changes proposed in comment 16? Yes, I am interested. Let's discuss the best way to do that. There are three parts of the patch: 1. Socket creation changes 2. Handling the SSLException and changing SSL configuration data automatically 3. Configuration UI changes for host wise management of the SSLv3 option 1. Socket creation changes ----------------------------- Focusing on the Bugzilla client, I see that HTTP(S) communication is handled by the class org.eclipse.mylyn.commons.net.WebUtil. WebUtil uses org.eclipse.mylyn.internal.commons.net.PollingSslProtocolSocketFactory for SSL connections. In order to configure the socket to use SSLv3 only, I need to use my own SocketFactory. I propose the following change: org.eclipse.mylyn.commons.net.AbstractWebLocation: New method "isSslv3Only(): boolean", default implementation: return false org.eclipse.mylyn.internal.tasks.core.TaskRepositoryLocation: Overwrites "isSslv3Only(): boolean": gets the information from TaskRepository org.eclipse.mylyn.tasks.core.TaskRepository: New property (Key: "org.eclipse.mylyn.tasklist.repositories.sslv3only") New methods (get/set)Sslv3Only org.eclipse.mylyn.commons.net.WebUtil.createHostConfiguration: If SSL and location.isSslv3Only(), use alternative SocketFactory, which configures the socket correctly using "socket.setEnabledProtocols(new String[] {"SSLv3"})" 2. Handling the SSLException and changing SSL configuration data automatically ----------------------------- I don't know, how to do that. The exception could be caught in WebUtil.executeInternal, but I see no reasonable way to access configuration data from there. Please help me on that. 3. Configuration UI changes for host wise management of the SSLv3 option ----------------------------- org.eclipse.mylyn.internal.tasks.ui.preferences.TasksUiPreferencePage: Use TaskRepositoryManager (TasksUIPlugin.getRepositoryManager()) to set SSLv3 options (TaskRepository.setSslv3Only - see above) What do you think?
What's really frustrating is that I can't seem to get around this. According to Sun I should be able to add "-Dhttps.protocols=SSLv3" to the java command line and force SSLv3. I can use the Eclipse web browser to visit my Trac site, but mylyn doesn't work.
Jon, can you provide a link to documentation that describes this VM system property? Did you specify it after the -vmargs switch?
Right from Sun: http://java.sun.com/j2se/1.4.2/docs/guide/plugin/developer_guide/faq/troubleshooting.html Here's my eclipse.ini (Mac): -startup ../../../plugins/org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar --launcher.library ../../../plugins/org.eclipse.equinox.launcher.cocoa.macosx.x86_64_1.0.1.R35x_v20090707 -product org.eclipse.epp.package.jee.product -showsplash org.eclipse.platform --launcher.XXMaxPermSize 256m -vmargs -Dhttps.protocols=SSLv3 -Dosgi.requiredJavaVersion=1.5 -XstartOnFirstThread -Dorg.eclipse.swt.internal.carbon.smallFonts -XX:MaxPermSize=256m -Xms40m -Xmx512m -Xdock:icon=../Resources/Eclipse.icns -XstartOnFirstThread -Dorg.eclipse.swt.internal.carbon.smallFonts
Sorry for the slow response and thanks for taking the time to investigate this. I have pasted my answers below. (In reply to comment #19) > Let's discuss the best way to do that. > > There are three parts of the patch: > 1. Socket creation changes > 2. Handling the SSLException and changing SSL configuration data automatically > 3. Configuration UI changes for host wise management of the SSLv3 option > > 1. Socket creation changes > ----------------------------- > Focusing on the Bugzilla client, I see that HTTP(S) communication is handled by > the class org.eclipse.mylyn.commons.net.WebUtil. WebUtil uses > org.eclipse.mylyn.internal.commons.net.PollingSslProtocolSocketFactory for SSL > connections. In order to configure the socket to use SSLv3 only, I need to use > my own SocketFactory. The changes should be applied to PollingSslProtocolSocketFactory since that's already used by all connectors. > I propose the following change: > > org.eclipse.mylyn.commons.net.AbstractWebLocation: > New method "isSslv3Only(): boolean", default implementation: return false > > org.eclipse.mylyn.internal.tasks.core.TaskRepositoryLocation: > Overwrites "isSslv3Only(): boolean": gets the information from TaskRepository How about a more flexible type such as or enum in case we want to support other protocol combinations in the future? > org.eclipse.mylyn.tasks.core.TaskRepository: > New property (Key: "org.eclipse.mylyn.tasklist.repositories.sslv3only") > New methods (get/set)Sslv3Only It should be sufficient to declare a new property key without the need for adding new methods. > org.eclipse.mylyn.commons.net.WebUtil.createHostConfiguration: > If SSL and location.isSslv3Only(), use alternative SocketFactory, which > configures the socket correctly using "socket.setEnabledProtocols(new String[] > {"SSLv3"})" Couldn't this be directly implemented in PollingSslProtocolSocketFactory? > 2. Handling the SSLException and changing SSL configuration data automatically > ----------------------------- > I don't know, how to do that. The exception could be caught in > WebUtil.executeInternal, but I see no reasonable way to access configuration > data from there. Please help me on that. I think this would need to be handled in BugzillaRepositorySettingsPage.validate() to be able to do the proper exception handling. Once this works for one connector we can put a generic implementation in AbstractRepositorySettingsPage. > 3. Configuration UI changes for host wise management of the SSLv3 option > ----------------------------- > org.eclipse.mylyn.internal.tasks.ui.preferences.TasksUiPreferencePage: > Use TaskRepositoryManager (TasksUIPlugin.getRepositoryManager()) to set SSLv3 > options (TaskRepository.setSslv3Only - see above) Yes, it's good if we keep this simple for now, with two selections for either default or SSLv3 maybe.
Created attachment 165468 [details] mylyn/context/zip
Sorry for the delay. Before jumping in the code any further, I wanted to look, how other Eclipse plugins handle SSL sockets. SVNKit for example works with SSLv3 servers out of the box. That is because in the SVNKit SVNSocketFactory, there is a statement ((SSLSocket) sslSocket).setEnabledProtocols(new String[] {"SSLv3"}); for every SSL socket. If a wide used library like SVNKit does that, we shouldn't we? It seams to be valid for old non SSLv3 server, too, right? I think, the JRE automatically switches back to SSLv2 etc. Could someone verify, if setting enabled protocols to SSLv3 is backwards compatible to non SSLv3 server?
Sorry for the delay. Before jumping in the code any further, I wanted to look, how other Eclipse plugins handle SSL sockets. SVNKit for example works with SSLv3 servers out of the box. That is because in the SVNKit SVNSocketFactory, there is a statement ((SSLSocket) sslSocket).setEnabledProtocols(new String[] {"SSLv3"}); for every SSL socket. If a wide used library like SVNKit does that, we shouldn't we? It seams to be valid for old non SSLv3 server, too, right? I think, the JRE automatically switches back to SSLv2 etc. Could someone verify, if setting enabled protocols to SSLv3 is backwards compatible to non SSLv3 servers?
I added support for a new system property that allows overriding of the enabled protocols for SSL sockets: http://wiki.eclipse.org/Mylyn/FAQ#System_Properties . If you set this system property in the eclipse.ini you can limit support to SSLv3 to work around the problem described in this bug: -Dorg.eclipse.mylyn.https.protocols=SSLv3 The problem is also described in the following FAQ entry: http://wiki.eclipse.org/Mylyn/FAQ#Error_.22Received_fatal_alert:_bad_record_mac.22_when_using_https . This property will be supported in the next weekly build.
Created attachment 208770 [details] mylyn/context/zip
