SDK/J

Hello,

Continuing the conversation with Alex Reyes from this incident with my opentext account: https://ricoh-ridp.com/ridp/support-system/incident/ricoh-americas-corp-technology-center/1618011075/934425031/4094

I understand that you do not want to go through the process of explaining how to get SDK/J applications to use TLS 1.2, but I (and also my managers) have not been able to find out who at OpenText has worked on this (it's a large company) so if you could help point me towards somebody at OpenText who has worked on this this would help a lot.

Can you give us a contact at OpenText who you worked with on this? Or give us access to the support incident where it was discussed (with my new account I can see incidents entered by RightFax but we have contacted them and they do not have a currently supported SDK/J)?

Thanks,

Peter Utiger 

Hello,

We have a client (Broward College) which has some older Ricoh MFPs which require our old SDK/J application to interface with our cloud fax server. Our cloud server only accepts TLS 1.2 and higher. A couple of years ago I asked about support for TLS 1.2 with SDK/J which you answered here. 

Broward College is doing some tests with their MP C4503 machines and are not able to get our application to connect to the cloud server using TLS 1.2. Our network traces show that the calls from the MFP are still made in TLS 1.0. Broward College have been working with Ricoh on their side and have been told that the installed version of the firmware that is installed does support TLS 1.2 even though the version of the Java platform they currently have (11.44.80) does not match the version from the list you gave me a couple of years ago which indicated the custom firmware versions that specifically support TLS 1.2 for this model (11.32.63). 

Some people in sales at OpenText (which bought XMedius last year) have mentioned that some products at OpenText had similar issues but that they managed to fix them, saying that maybe we "are not utilizing the cypher properly within the new firmware" (I'm not sure what this means but thought I might mention it). 

We only use standard Java for our web calls.

My questions are therefore:

- Is the answer I got for the incident I linked to above still valid? Or are there newer versions of the firmware that support TLS 1.2? Shoud this work with version 11.44.80 of the Java platform?

- Is there anything special we need to do (either in our code or configuration of the MFP) to be able to make the application use TLS 1.2 instead of TLS 1.0?

Thanks,

Peter

Customer reports that on an IMC4500, after the MFP goes to sleep, it won't wake up. Manually putting the MFP to sleep doesn't cause the issue. It only happens if the MFP goes to sleep on it's own. I have the log from the MFP but it's too large to upload with this ticket. I'll try putting it in Slack.

I have a change in the next release of our SDK/J solution that should only require a maintenance signature.

1. We are still supporting devices with SDK/J versions 4, 5, 7, 10, 11, 12.
2. SVGA COLOR, WVGA COLOR and HVGA COLOR.
3. 34099970.jar and 34099971.jar are the only modified jar files.
4. No modifications to the .dalp file other than updating the version.

Changes:

1. Added OAuth2 device code flow with Azure AD for Authentication/Enrollment.

Regards
Bryan

Hello,

Wells Fargo has been having an issue where our client is hanging on Device Authentication on their models. In our testing however, we are able to device authenticate users into our server just fine.

Attached is a screenshot of the dialog the device hangs on.

We do not see this dialog appear on our device. 

We sent this message to Martin and Gerardo asking them for assistance. We are adding this here for the record.

Jason Garbo requested a compatibility test in behalf of a proposal for Cotchett Pitre & McCarthy. The test would would verify that Equitrac Professional v5.7 and the embedded client v2.05.0050 is compatiblie with the Charis-C3 Office device (IM C6500 & IM C8000). PTEC verified that the solutions is compatible.

Hi,

For Kofax SafeCom Go Ricoh, we are working on implementing various fixes for customer reports and feedback from previous certifications, and would like to certify our final build as a generally available release. Can you please respond to the following questions to help?

1. Can we request a certification time slot starting 1st April, or close to it in April?
2. If we can allocate a time slot, can you please send us a quote for the certification?
3. Can you please share the latest process documentation for SDK/J certifications, so we can use it to prepare our submission?

Thank you in advance!

Sebestyen

Hello,

We will be ready to submit our client for certification on March 1st, 2021. We want to know if the submission process will be the same as it was previously? Will we need to do anything before submission? Do you guys need a VM with our Encapture server?

Thanks,

Scott

The xlet maintenance bundle (attached) needs production signing, the release includes bugs fix to resolve stability issues. 

(Gerardo said that Alex would be point on this, so please direct this to him).

Adding the notes from our emails>

Gerardo and Martin,

We were discussing this further and it seems like they are going to still have this problem, even if we address this problem on our side.

Are you able to disable specific ciphers that are used by the built-in device portal page?
If you aren’t, they will still be in non-compliance related to their security sweep.
If they can, are they not in the same boat, where the browsers can’t find a support cipher to talk to that portal page?

We’re on a status call with Wells in an hour and a half and trying to determine the extent of the issue and how best this can be addressed.

---

Gerardo and Martin,

We've been working with the latest firmware and CVM so far and, for the most part, it has been going well.

As a bit of background, the list of ciphers supported on the devices is as follows:
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA

One of the security requests made by Wells is to protect against the Robot vulnerability, which is done by disabling the TLS_RSA_* ciphers. The problem is that when we disable those ciphers, only the TLS_DHE_* ciphers remain, and because Chromium no longer allows the TLS_DHE_* ciphers, we are unable to connect to our configuration endpoint using any Chromium-based browser.

We've gotten our installation/configuration utility working with the DHE ciphers, but I don't believe we'll be able to get any of the bank's browsers to connect to us.

The purpose of this email is to double check all the information above with you and make sure we're on the same page before we raise this to the customer. I believe that we're going to recommend that Wells disables the TLS_RSA_* ciphers, with the understanding that they'll lose the easy, browser-based configuration that they're used to.

Are you available for a short meeting on Monday or Tuesday to discuss the information above, determine if there are any options that we've overlooked, and make sure we're in agreement with regard to our recommendations and communications to Wells?

Thanks,
Scott