Re: SSL API Issues after latest CUM PTFs on V7R3 -- WEB400

Well, my client had a call with IBM.
IBM had them change the system value QSSLPCL from *OPSYS to a list:
*TLSV1.2
*TLSV1.1
*TLSV1

And that seemed to fix their specific issue. Doesn't make sense (well, it
does). I have a feeling their trading partner was using older version of
TLS. That should have been easy to tell. Seems like a bandaid fix.

On Tue, Oct 6, 2020 at 10:09 AM Gerald Magnuson <gmagqcy.midrange@xxxxxxxxx>
wrote:

Sorry, I should clarify , we use HTTPAPI here.

On Tue, Oct 6, 2020 at 9:40 AM Brad Stone <bvstone@xxxxxxxxx> wrote:

I'd sure love to be able to test it, though. Then I could figure out if

I

needed to just retry the handshake, or if I need to totally restart the
connection. But the trace from the customer did show that the SSL
handshake wasn't working properly...

On Tue, Oct 6, 2020 at 9:20 AM Charles Wilt <charles.wilt@xxxxxxxxx>
wrote:

I'd agree that there should be a number of retries.

Charles

On Tue, Oct 6, 2020 at 7:05 AM Brad Stone <bvstone@xxxxxxxxx> wrote:

Thanks for following up. I haven't heard from my customers yet

either

(which I normally take as a good thing).

I wonder if in our applications if a handshake fails we should have a
default number of retries. The only issue is I can't recreate the

issue

on

my end to test with.

On Tue, Oct 6, 2020 at 7:59 AM Gerald Magnuson <

gmagqcy.midrange@xxxxxxxxx

wrote:

The PTF (MF67570) didn't fix it.

On Mon, Oct 5, 2020 at 1:48 PM Brad Stone <bvstone@xxxxxxxxx>

wrote:

Keep up updated on your issues and if the PTF IBM suggest solves

the

issue.

On Mon, Oct 5, 2020 at 1:43 PM Gerald Magnuson <

gmagqcy.midrange@xxxxxxxxx

wrote:

Also, not only are we getting the TLSv1.2 Peer not

recognized...

errors

when connecting to our internal servers (HAProxy), were have

been

getting that -16 error when we try to connect to one of our

VANs

(COVISINT).

On Mon, Oct 5, 2020 at 1:22 PM Gerald Magnuson <

gmagqcy.midrange@xxxxxxxxx

wrote:

We have had these errors since we went to 7.4 on Labor Day.

After

changing ciphers and putting on all the latest PTF groups,

we

now

have

this very strange symptom: these errors "(GSKit) Peer not

recognized

or

badly formatted message received." are only happening

between

the

hours

of 6am through 10am (we may get 1 or 2 outside of this time

frame).

I have just installed that ptf (MF67593 - 7.4 MF67570), so

let's

see

what

tomorrow brings.

On Thu, Oct 1, 2020 at 4:07 PM Brad Stone <bvstone@xxxxxxxxx

wrote:

Info from IBM that a customer got:

-APAR MA48442 (“OSP-OTHER-UNPRED SYSTEM TLS FAILS TLSV1.2

SERVER

HELLO

WITHOUT EXTENSION DATA LENGTH”)
-Update a few PTF Groups to current levels
-Apply PTF MF67593, which isn’t in any PTF Group.

So it does seem to be an IBM issue that has already been

(hopefully)

fixed. I will know for sure after the weekend.

I tried searching for PTFs but that seems futile these

days...

unless

I'm

just not understanding how their newer searches work...lol.

On Thu, Oct 1, 2020 at 10:07 AM Brad Stone <

bvstone@xxxxxxxxx

wrote:

Hi, Jeff.

I haven't seen any issues with Google, no. I just am

wondering

if

it's

an

issue with only certain endpoints. It's hard to tell. I

am

hoping

to

hear

from one customer to see what IBM tells them.

On Thu, Oct 1, 2020 at 9:36 AM Jeff Crosby <

jlcrosby@xxxxxxxxxxxxxxxx

wrote:

Is this 7.3? Would this possibly affect my using G4G

uploading

PDFs?

Asking because I'm set to IPL and apply some PTF groups

tomorrow

night.

Thanks.

On Thu, Oct 1, 2020 at 10:23 AM Brad Stone <

bvstone@xxxxxxxxx>

wrote:

I have a few customers that seem to be reporting an

issue

with

the

IBM

SSL

APIs after applying a recent PTF group when using

GETURI

(HTTPAPI

also

reports the same issues) communicating with a web

service.

Also from tests using cURL and PHP on the IBM i the

error

cannot

be

reproduced, neither can it on the PC using Postman,

etc.

Randomly they are receiving the error:

415 - Peer not recognized or badly formatted message

received.

If the standard SSL APIs are used RC is normally -16

if I

recall.

One customer was able to work with a trading partner

and

they

did a

trace

on their end and tracked it down to the "Hello"

communications

from

the

IBM

i during SSL negotiation.

What they saw and explained was something like this:

"...When everything is working fine we have noticed the

server

hellos

are

super small …376 bytes which is an indication of TLS

session

reuse.

Then

there is an attempt to do TLS reuse with a different

proxy

or

backend

server and it fails which is likely this TLS FATAL

illegal

parameter

error. The NEXT server hello is much larger, 3586

bytes,

because

the

TLS

session is trashed and has to start over.

It then works for a while with the little server

hello's

doing

session

reuse ... until a proxy or backend server gets switched

and

it

blows

up

and

starts all over..."

So, when this error is reported on the IBM i seems to

correlate

with

what

they see on their end where the TLS session is

"trashed".

My suspicion is that a recent PTF broke this, since it

worked

for

years

previously and after the PTFs this behavior started.

I have the customer contacting IBM to see when they can

find

with

all

this

information, but I am just curious if anyone else is

experiencing

this

issue and what they have found.

Thanks.

Bradley V. Stone
www.bvstools.com
Native IBM i e-Mail solutions for Microsoft Office 365,

Gmail,

or

any

Cloud

Provider!
--
This is the Web Enabling the IBM i (AS/400 and iSeries)

(WEB400)

mailing

list
To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:

https://lists.midrange.com/mailman/listinfo/web400

or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the

archives

at https://archive.midrange.com/web400.

--

Jeff Crosby
VP Information Systems
UniPro FoodService/Dilgard
P.O. Box 13369
Ft. Wayne, IN 46868-3369
260-422-7531
direct.dilgardfoods.com

The opinions expressed are my own and not necessarily the

opinion

of

my

company. Unless I say so.
--
This is the Web Enabling the IBM i (AS/400 and iSeries)

(WEB400)

mailing

list
To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:

https://lists.midrange.com/mailman/listinfo/web400

or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the

archives

at https://archive.midrange.com/web400.

--
This is the Web Enabling the IBM i (AS/400 and iSeries)

(WEB400)

mailing

list
To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.

--
This is the Web Enabling the IBM i (AS/400 and iSeries)

(WEB400)

mailing

list
To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.

--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)

mailing

list
To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.

--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)

mailing

list
To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.

--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)

mailing

list
To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.

--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)

mailing

list
To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.

--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.

--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.