[GNC-dev] New OFX Requirements For USAA FSB

Thu Feb 11 22:40:02 EST 2021

Martin,

Thanks.  I integrated the 'make clean' and I can now run locally modified code.

It turns out I am getting a 400 on receive from:

aqbanking-cli request --account=00075XXXXX --transactions --fromdate=20210120 --todate=20210208

Debug output:

...
===== Enter Password =====
Please enter the password for user XXXXXX
Input: ******
3:2021/02/11 21-39-57:aqofxconnect(3280):io_network.c: 175: Saving OFX log to "/Users/bobwhite/aqbanking/logs/aqofx.log" ...
Saving communication log to /Users/bobwhite/aqbanking/logs/aqofx.log
3:2021/02/11 21-39-57:aqofxconnect(3280):io_network.c: 128: RBW _createConnection
3:2021/02/11 21-39-57:aqofxconnect(3280):io_network.c: 136: RBW addr https://df3cx-services.1fsapi.com/casm/usaa/access.ofx
3:2021/02/11 21-39-57:aqofxconnect(3280):io_network.c: 145: RBW HttpVMajor 0
3:2021/02/11 21-39-57:aqofxconnect(3280):io_network.c: 147: RBW HttpVMinor 0
3:2021/02/11 21-39-57:aqofxconnect(3280):io_network.c: 151: RBW userAgent InetClntApp/3.0
6:2021/02/11 21-39-57:aqbanking(3280):httpsession.c: 167: Extending TLS SyncIo
3:2021/02/11 21-39-57:aqofxconnect(3280):io_network.c: 65: RBW Connect here (0)
3:2021/02/11 21-39-57:aqofxconnect(3280):io_network.c: 75: RBW POST (0)
3:2021/02/11 21-39-57:aqofxconnect(3280):io_network.c: 88: RBW Recv (400)
3:2021/02/11 21-39-57:aqofxconnect(3280):io_network.c: 99: here (400)
6:2021/02/11 21-39-57:aqbanking(3280):./provider_user.c: 252: Unlocking customer "4563"
8:2021/02/11 21-39-57:aqbanking(3280):provider.c: 82: Destroying AB_PROVIDER (aqofxconnect)
accountInfoList {
} #accountInfoList

securityList {
} #securityList

messageList {
} #messageList

Not being familiar with the gwenhywfar lib I haven't been able to see the actual buffer with the content of the POST request.

The curl version of the request specified in the aqbanking-cli request above is working.  I am including the verbose curl output from the request in the hopes it might provide clues as to whether gwenhywfar supports the interaction it describes, like the switchover to HTTP/2.  (In the aqbanking-cli request I also did get a prompt to accept the cert due to "Status : Certificate owner does not match hostname" so it makes me wonder if the subjectAltName is supported.)

* Trying 45.60.151.211...
* TCP_NODELAY set
* Connected to df3cx-services.1fsapi.com (45.60.151.211) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=imperva.com
*  start date: Jan 20 17:31:41 2021 GMT
*  expire date: Jul 22 08:26:17 2021 GMT
*  subjectAltName: host "df3cx-services.1fsapi.com" matched cert's "*.1fsapi.com"
*  issuer: C=BE; O=GlobalSign nv-sa; CN=GlobalSign Atlas R3 DV TLS CA 2020
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x8c3bb0)
> POST /casm/usaa/access.ofx HTTP/2
> Host: df3cx-services.1fsapi.com
> User-Agent: InetClntApp/3.0
> Accept: */*
> Content-Type: application/x-ofx
> Content-Length: 753
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
* We are completely uploaded and fine
< HTTP/2 200
HTTP/2 200
< date: Fri, 12 Feb 2021 02:51:19 GMT
date: Fri, 12 Feb 2021 02:51:19 GMT
< content-type: application/x-ofx
content-type: application/x-ofx
< content-length: 5097
content-length: 5097
< vary: Origin
vary: Origin
< vary: Access-Control-Request-Method
vary: Access-Control-Request-Method
< vary: Access-Control-Request-Headers
vary: Access-Control-Request-Headers
< x-content-type-options: nosniff
x-content-type-options: nosniff
< x-xss-protection: 1; mode=block
x-xss-protection: 1; mode=block
< cache-control: no-cache, no-store, max-age=0, must-revalidate
cache-control: no-cache, no-store, max-age=0, must-revalidate
< pragma: no-cache
pragma: no-cache
< expires: 0
expires: 0
< strict-transport-security: max-age=31536000 ; includeSubDomains
strict-transport-security: max-age=31536000 ; includeSubDomains
< x-frame-options: DENY
x-frame-options: DENY
< set-cookie: visid_incap_2454689=MRSRHr7fT6qOqlWtxfrzWSbtJWAAAAAAQUIPAAAAAADEpEAhLOG6NipBTNfV1vXY; expires=Fri, 11 Feb 2022 10:20:34 GMT; HttpOnly; path=/; Domain=.1fsapi.com; Secure; SameSite=None
set-cookie: visid_incap_2454689=MRSRHr7fT6qOqlWtxfrzWSbtJWAAAAAAQUIPAAAAAADEpEAhLOG6NipBTNfV1vXY; expires=Fri, 11 Feb 2022 10:20:34 GMT; HttpOnly; path=/; Domain=.1fsapi.com; Secure; SameSite=None
< set-cookie: nlbi_2454689=WCVvUDxEvHjvcWozhXBnAwAAAAAtgmMABh/EhEr6j5RNlnax; path=/; Domain=.1fsapi.com; Secure; SameSite=None
set-cookie: nlbi_2454689=WCVvUDxEvHjvcWozhXBnAwAAAAAtgmMABh/EhEr6j5RNlnax; path=/; Domain=.1fsapi.com; Secure; SameSite=None
< set-cookie: incap_ses_1211_2454689=/vjDaM/xdD+lq06tT1bOECbtJWAAAAAA1PSYV8vjV8nlh6yIjsayog==; path=/; Domain=.1fsapi.com; Secure; SameSite=None
set-cookie: incap_ses_1211_2454689=/vjDaM/xdD+lq06tT1bOECbtJWAAAAAA1PSYV8vjV8nlh6yIjsayog==; path=/; Domain=.1fsapi.com; Secure; SameSite=None
< x-cdn: Incapsula
x-cdn: Incapsula
< x-iinfo: 9-6486643-6486644 NNNN CT(8 4 0) RT(1613098275955 0) q(0 0 0 -1) r(29 29) U6
x-iinfo: 9-6486643-6486644 NNNN CT(8 4 0) RT(1613098275955 0) q(0 0 0 -1) r(29 29) U6

<
OFXHEADER:100
DATA:OFXSGML
VERSION:103
SECURITY:NONE
ENCODING:USASCII
CHARSET:1252
COMPRESSION:NONE
OLDFILEUID:NONE
NEWFILEUID:NONE

<OFX><SIGNONMSGSRSV1><SONRS>
...

I've got gwenhywfar and aqbanking build environments setup on an EC2 instance so as to avoid IP blocking issues mentioned previously by Scott McRae.

I hope you can offer some assistance or recommendations for next steps.  

Regards,

Bob

On February 11, 2021 at 11:02 AM, Martin Preuss <martin at aquamaniac.de> wrote:

Am 11.02.21 um 01:48 schrieb Bob White:
[...]
I pulled the latest (on master) but didn't see any commits beyond the uuid fix.

I made the following changes, ran 'make && make install', but don't see the NONE reflected in aqbanking-cli requests (they still have time-base NEWFILEUID):
[...]

Maybe it has to with a bug in the build system, I couldn't figure out why but sometimes you need to do a "make clean" before "make". Sometimes not all sub-libraries files are properly rebuilt...

Regards
Martin