The CIM API is timing out for us. Is anyone else having this issue or is it just us?
@peter, we rolled back the LOW ciphers that were installed. That was the only change.
Are you forcing SSL v3 in your code?
06-04-2014 07:41 AM
So is the consensus that last night's removal of LOW ciphers didn't help those who couldn't connect?
If so I will report this and we'll probably reverse ALL the changes we attempted for the short term.
06-04-2014 07:46 AM
@Lilith, we still can not connect. Our test suite is completely broken since Monday. and we made no code change on our end.
06-04-2014 07:52 AM
What are you going to do for implementations that cannot force SSLv3 in their code?
Our whole implementation uses Debian 7.
We don't have the option to upgrade from 1.0.1e to unstable 1.0.1g.
We're using a library that doesn't give us control to change the SSL version of the request.
I understand security issues, but the server should be capable of negotiating the appropriate security.
This implementation has serious implications to a large portion of web hosts. Shouldn't this update have been applied so that there is no negative repercussions to the clients? What is the timeline for the launch of this change to the production server?
If we don't have the control to change our environment, and these changes are going to break it, then what are we supposed to do?
06-04-2014 07:53 AM
@bmoore, as I stated, we're probably going to reverse all the changes. It's not clear when or if this will reach Production.
06-04-2014 07:57 AM
@Lilith Thank you. Is there any information about the timeline for the reversal? All of our development is completely halted until this is fixed (which means significant $ lost).
For the record: I've been dealing with customer support, and apparently they're not allowed to help except for reading the manual for you. Jerry was the first helpful person I could reach who was able to give me any information about authorize.net. As an employee of a paying customer of an internet company, I would expect the at least some level of direct technical support above that of a developer moderated forum. As a developer that cannot get technical support, nor information, on a server level issue for over 24 hours is a bit unsettling.
06-04-2014 08:05 AM
It still doesn't work for me unless I add curl_setopt($curl_request, CURLOPT_SSLVERSION, 3);
06-04-2014 08:19 AM
I had to dive in to WordPress core and change
$connect_host = $secure_transport ? 'ssl://' . $connect_host : 'tcp://' . $connect_host;
to sslv3
This modifies core code, i'll have to find a work around but forcing sslv3 in class-http.php worked. I was not able to force sslv3 in my apache global config for some reason.
06-04-2014 08:34 AM
Modifying core should not be an option. As far as I'm concerned, this isn't solved. When will the changed be reversed?
06-04-2014 08:38 AM
I understand handling these issues takes time, but is there an estimate about when these issues are going to be rolled back?
06-04-2014 09:04 AM