I need some advice here. We received this noticed from a company whom we interface with through pub.client.http. Message content is PGP encrypted and protocol is https.

"To eliminate exposure to recently announced security vulnerability, also known POODLE,
will disable Secure Sockets Layer version 3.0 protocol (SSL 3.0) for file delivery services for Transaction Services.
In order to continue sending files please ensure that Transport Layer Security version 1.x (TLS 1.x) is enabled for
encryption when sending files to via FTPS (SSL) or FTPS Explicit or AS2 or HTTPS or HTTPS (Mutual Authentication).
TLS 1.x will need to be enabled in order for to accept incoming files and to decrypt files. "

Is there something in webMethods (8.2.2.0) that allows me to define the protocol to be used, or is this entirely a matter for the firewalls on either side?

Thanks for any advice you may have that could help me forward…
Arnt

ok, I found this:

I’ll continue from here…

Good catch Arnt, let us know if you resolve or get stuck with anything.

Thanks,

Well, at least I understand the issue better now, but I’m kind of stuck in the sense that I’m not sure if the solution is to upgrade to upgrade to IS_8.2_SP2_Core_Fix15 (from 7) or if 8.2.2.0 already has the support needed so that I can control this through extended settings, for instance watt.net.ssl.client.strongcipheronly.

And I’m also wondering how the fix - whatever the fix is - would affect our pub.client.http connections to other customers and partners.

I’m not a webMethods admin, so I’m not even sure where the corefix release notes - or the patches - are found…

I was just the guy who was unlucky enough NOT to be on vacation when this landed in my lap a couple of days ago.

So yeah, any hints are appreciated at this time

Hi Arnt,

do you have access to Empower?

If so search for the knowledgebase article mentioned in the referenced thread.
If not you can either request it if you know your companies customer number at SAG or you will have to wait for your Admins to return from vacations (in the hope that they have the neccessary access rights).

You will need the Empower access also when trying to download the Fixes via UpdateManager.

To be definitely save it is recommended to update to latest IS_Core_Fix (currently Fix17) and set the Handshake properties mentioned in the Readme for PIE-34054 accordingly.

Please note that this Fix has dependencies on the security library Fixes (SCG_Entrust, currently Fix4) which need to be installed together with the IS_Core_Fix to get this feature working.

I dont think that just setting the strongcipheronly-property will be enough to avoid the POODLE issue, as there still are SSL V3 sessions possible even with the strong ciphers.

Regards,
Holger

Addendum:

You will have to apply latest Fixes anyway when preparing migration to newer wM version.

So it might be a good idea to do it now and get it thoroughly tested before starting the migration.

Knowledge Base Article in Empower:
KB # 1760581
webMethods Integration Server - POODLE Vulnerability for wM7.x, 8.x and 9.x IS, Broker and MWS

Regards,
Holger

Hi Holger.

Thank you very much for your answer, Holger. VERY much appreciated!

My next step is to upgrade the required fixes. It took me some time to find a server that I can upgrade, but I hope I can start this afternoon.

If the answer to the problem lies within the extended settings, then it is natural to assume that this will affect every call made by pub.client.http. As such, we need to set up test cases for every customer we connect to in existing integrations - to make sure we haven’t introduced new problems.

But as you say, first I need to get hold of the fix and read myself up on what the fix actually is.

ps; when we migrate to new webMethods versions, we start with fresh servers running the latest SW, then we migrate the integrations one by one and decommission the old. We never do a major upgrade on an existing production server. It’s just the policy we’ve chosen…

Hi Arnt,

sure you will have to test this.

But your partners might be also asked by their security teams to prepare to apply any updates to their systems for the POODLE vulnerability.

Maybe it is a good idea to plan this together.

Regarding your PS:
The migration will be a side-by-side migration as there is no possibility for an overinstall any longer.
But it is stated in the migration guides, that the source servers (8.2 in your case) need to be updated to the latest fixes.
Of course migrations usually start on development and test environments before doing so in production.

Threre are already several threads ongoing here which deal with migration questions.
Additionally it might be neccessary or at least useful to contact SAG Consulting for migration assistance.

Regards,
Holger

I got a packet dump from our network team. This is traffic from our webMethods server doing external https and a different customer than the one which is about to disable SSL 3.0 on their end.

I’ll be the first one to admit that I’m a novice - at best - in interpreting these dumps, but can I make the conclusion that TLS 1.0 was the chosen protocol during this negotiation? See attached image…

Any replies are appreciated!

https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files3/bad58c7b1055a6b0dbf04546fffb9ade94dce175_2_793x750.jpeg 1.5x, https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/bad58c7b1055a6b0dbf04546fffb9ade94dce175.jpeg 2x" data-dominant-color="E8E6E7">

ws.jpg895×845 354 KB

Based on the logs, yes choosen protocol is TLS 1.0. Also did you check with your partner regarding the request raised from you.

Thanks,

We captured traffic to this business partner yesterday, webMethods is proposing SSL 2.0, the server responds with TLS 1.0, and that’s the protocol chosen for the rest of the transfer. So I thought we were in the clear, but there was a set-back:

• The business partner claims they have already enforced the restriction (rejecting incoming SSL requests)
• We were able to connect because they have already white listed our IP
• Without white listing, their end will reject SSL * -before- protocol negotiation takes place.

There seemed to be a 0.1% uncertainty about the last point, so we’ll run another test next week, this time with white listing disabled on their end. Then we will know for sure.

We won’t be able to do core fix upgrade on our servers until mid-August, so until then we’ll have to live with extended white listing if next week’s test fails.