ACF2

Has anyone implemented the following XFC rule to allow V2 / V3 SSL after the ZOS apars are put in that puts default to TLS1?

$KEY(GSK.ENABLE.SSLV*.DEFAULT) TYPE(XFC)

UID(*) ALLOW SERVICE(UPDATE)

Our reason for doing this would be to basically ignore the code as a backout instead of Reipling on the Minus one SYSRES

or to just let a few uids use V2 or V3 in case a critical app is failing because of it.

We got the rule from CA.

Implemented in a test region and tried to test with a 3270 app that fails if we specified SSL V3.   Maybe that was a bad app

to test but was the only one we are sure we could get to fail.

Opened ticket with CA and they had us do a Sectrace.   Nothing showed up.

Our security folks ensured us the rule was in place.

CA suggested I contact the CA communities or IBM. 

Has anyone run into this?

Thanks.   Jess

Just a thought, since the KEY is masked:  Make sure that R-RXFC is specified in the GSO INFODIR record.

Chuck

Charles,  I checked and we do have that specified.

set control(gso) sysid(****)

L infodir

bunch of stuff shows up and R-RXFC is one of them.

Also looked for GSO SYSID(YYYY) which would have been lpar specific and INFODIR didn't exist

so I think the way its set up here is SYSID(****) will take effect.

ZOS system programmer,  not ACF2 system programmer.

Jess,

I've never used masking for the ACF2 SYSID, so can't say for sure how that would function.  You may want to have your InfoSec folks put out a SYSID-specific INFODIR GSO record on that LPAR for testing, modeled after the SYSID(****) INFODIR record, since the XFC directory is resident:  R-RXFC.

Hope that helps narrow it down, at least.

Chuck

If in doubt as to residency of directories ask someone with sufficient authority to go into the ACF command on TSO or submit an ACFBATCH job and issue command SHOW RESIDENT .

Jess -

It makes sense that IBM is doing this (security vulnerabilities with SSL).  Do you happen to know the APAR/PTF numbers so we don't accidently put these fixes on w/out testing?

For whatever it's worth, our Windows security folks have disabled SSL in IE and Firefox.  I needed to get an exemption so I could remote into our HMC (a bit back leveled).

- Don

Don,

I think it started with APAR OA46489.   Then later there was performance issues with those fixes and they added more fixes.

Our PTF list for ZOS 1.13 is (although yours may be different depending on whats applied). 

UA76977, UA77207, UA77208, UA76978, UA76901, UA76933, UI24978, UI26698, UI27051 and UI27686.

Some of those are SSL ptfs and some are TCPIP ptfs.

We got a little confuse because we had problems with 3270 software using SSL-V2  and V3 protocols so we removed all the ptfs that mentioned

GSK in the HOLDDATA,  however removing those did not take care of the problem.   There were TCPIP ptfs that also restricted the protocols.  We had

to remove them also.  To get those I think we searched for SSL in the Holddata.

And that's how we initially saw the potential problem,  by seeing the comments in the ACTION HOLDDATA.   Of course at the time,

I didn't realize the ramifications.