line "wget https://www.mathworks.com/mpm/glnxa64/mpm" in dockerfile fails: suspect FIPS 140-3 non-compliant TLS handshake

[DanWoodrichNOAA]

Summary:

Want to use your dockerfile OOB as a suggested workflow for a community of users. We are in a hardened environment which enforces FIPS 140-3 on compute instances. Your content delivery endpoint at https://ssd.mathworks.com/supportfiles/downloads/mpm/2025.1/glnxa64/mpm (forwarded on your end from what's in the dockerfile, which is https://www.mathworks.com/mpm/glnxa64/mpm) does not appear to be using a FIPS 140-3 compatible algorithm in TLS handshake. This probably means your server needs updated configuration to conform to FIPS 140-3 standard.

Please review your server/CDN configuration for FIPS 140-3 compliance.

Tested:

Works: in a variety of environments where FIPS 140-3 is not present (including those where FIPS 140-2 is present): vanilla ubuntu major vers lts, linux-image-5.4.0-1021-gcp-fips
Does not work: linux-image-5.15.0-1088-gcp-fips (FIPS 140-3 policy enforced)

Output of failed TLS handshake:

curl -vI -L https://ssd.mathworks.com/supportfiles/downloads/mpm/2025.1/glnxa64/mpm

• Trying 23.9.151.41:443...
• Connected to ssd.mathworks.com (23.9.151.41) port 443 (#0)
• ALPN, offering h2
• ALPN, offering http/1.1
• CAfile: /etc/ssl/certs/ca-certificates.crt
• CApath: /etc/ssl/certs
• TLSv1.0 (OUT), TLS header, Certificate Status (22):
• TLSv1.3 (OUT), TLS handshake, Client hello (1):
• TLSv1.2 (IN), TLS header, Certificate Status (22):
• TLSv1.3 (IN), TLS handshake, Server hello (2):
• TLSv1.2 (IN), TLS header, Certificate Status (22):
• TLSv1.2 (IN), TLS handshake, Certificate (11):
• TLSv1.2 (IN), TLS header, Certificate Status (22):
• TLSv1.2 (IN), TLS handshake, Server key exchange (12):
• TLSv1.2 (IN), TLS header, Certificate Status (22):
• TLSv1.2 (IN), TLS handshake, Server finished (14):
• TLSv1.2 (OUT), TLS header, Certificate Status (22):
• TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
• TLSv1.2 (OUT), TLS header, Unknown (21):
• TLSv1.2 (OUT), TLS alert, internal error (592):
• error:1C800073:Provider routines::invalid data

[josmartin]

@DanWoodrichNOAA Many thanks for this - I wonder if you could test something for us? First off, its apparently really hard to get a list of FIPS 140-3 allowed cipher suites from the internet - however I did find this IBM java documentation and this OpenSSL wiki page which both seem to indicate that

AES256-GCM-SHA384

should be a supported FIPS 140-3 compliant. Running sslscan on our external TLS endpoint

$ sslscan www.mathworks.com:443
Version: 2.1.2
OpenSSL 3.0.13 30 Jan 2024

Connected to 23.217.5.27

Testing SSL server www.mathworks.com on port 443 using SNI name www.mathworks.com

  SSL/TLS Protocols:
SSLv2     disabled
SSLv3     disabled
TLSv1.0   disabled
TLSv1.1   disabled
TLSv1.2   enabled
TLSv1.3   enabled

  TLS Fallback SCSV:
Server supports TLS Fallback SCSV

  TLS renegotiation:
Session renegotiation not supported

  TLS Compression:
OpenSSL version does not support compression
Rebuild with zlib1g-dev package for zlib support

  Heartbleed:
TLSv1.3 not vulnerable to heartbleed
TLSv1.2 not vulnerable to heartbleed

  Supported Server Cipher(s):
Preferred TLSv1.3  256 bits  TLS_AES_256_GCM_SHA384        Curve 25519 DHE 253
Accepted  TLSv1.3  256 bits  TLS_CHACHA20_POLY1305_SHA256  Curve 25519 DHE 253
Accepted  TLSv1.3  128 bits  TLS_AES_128_GCM_SHA256        Curve 25519 DHE 253
Preferred TLSv1.2  256 bits  ECDHE-RSA-AES256-GCM-SHA384   Curve P-256 DHE 256
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-GCM-SHA256   Curve P-256 DHE 256
Accepted  TLSv1.2  256 bits  ECDHE-RSA-CHACHA20-POLY1305   Curve P-256 DHE 256

  Server Key Exchange Group(s):
TLSv1.3  128 bits  secp256r1 (NIST P-256)
TLSv1.3  128 bits  x25519
TLSv1.2  128 bits  secp256r1 (NIST P-256)
TLSv1.2  128 bits  x25519

  SSL Certificate:
Signature Algorithm: sha256WithRSAEncryption
RSA Key Strength:    2048

Subject:  *.mathworks.com
Altnames: DNS:*.mathworks.com, DNS:mathworks.com
Issuer:   DigiCert Global G2 TLS RSA SHA256 2020 CA1

Not valid before: Jun  3 00:00:00 2025 GMT
Not valid after:  Jun  2 23:59:59 2026 GMT

seems to indicate that this cipher suite is enabled and available if the client negotiates a TLS 1.3 connection with the server. I wonder if you could try executing

    curl --tlsv1.3 -vI -L https://ssd.mathworks.com/supportfiles/downloads/mpm/2025.1/glnxa64/mpm

to force your system to ONLY use the TLS 1.3 cipher suites - which should then use a FIPS 140-3 compliant cipher suite.

[DanWoodrichNOAA]

Thanks @josmartin

See two different responses for the two different cypher suites. Here is your requested test on the 140-3 hardened client:

curl --tlsv1.3 -vI -L https://ssd.mathworks.com/supportfiles/downloads/mpm/2025.1/glnxa64/mpm

• Trying 23.9.151.41:443...
• Connected to ssd.mathworks.com (23.9.151.41) port 443 (#0)
• ALPN, offering h2
• ALPN, offering http/1.1
• CAfile: /etc/ssl/certs/ca-certificates.crt
• CApath: /etc/ssl/certs
• TLSv1.0 (OUT), TLS header, Certificate Status (22):
• TLSv1.3 (OUT), TLS handshake, Client hello (1):
• TLSv1.2 (IN), TLS header, Unknown (21):
• TLSv1.3 (IN), TLS alert, protocol version (582):
• error:0A00042E:SSL routines::tlsv1 alert protocol version
• Closing connection 0
  curl: (35) error:0A00042E:SSL routines::tlsv1 alert protocol version

Interestingly, I see this same behavior on a FIPS 140-2 hardened client:

curl --tlsv1.3 -vI -L https://ssd.mathworks.com/supportfiles/downloads/mpm/2025.1/glnxa64/mpm

• Trying 23.9.151.41:443...
• TCP_NODELAY set
• Connected to ssd.mathworks.com (23.9.151.41) port 443 (#0)
• ALPN, offering h2
• ALPN, offering http/1.1
• successfully set certificate verify locations:
• CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
• TLSv1.3 (OUT), TLS handshake, Client hello (1):
• TLSv1.3 (IN), TLS alert, protocol version (582):
• error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version
• Closing connection 0
  curl: (35) error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version

And on a completely non FIPS device:

curl --tlsv1.3 -vI -L https://ssd.mathworks.com/supportfiles/downloads/mpm/2025.1/glnxa64/mpm

• Host ssd.mathworks.com:443 was resolved.
• IPv6: (none)
• IPv4: 23.9.151.41
• Trying 23.9.151.41:443...
• Connected to ssd.mathworks.com (23.9.151.41) port 443
• ALPN: curl offers h2,http/1.1
• TLSv1.3 (OUT), TLS handshake, Client hello (1):
• CAfile: /etc/ssl/certs/ca-certificates.crt
• CApath: /etc/ssl/certs
• TLSv1.3 (IN), TLS alert, protocol version (582):
• OpenSSL/3.0.13: error:0A00042E:SSL routines::tlsv1 alert protocol version
• Closing connection
  curl: (35) OpenSSL/3.0.13: error:0A00042E:SSL routines::tlsv1 alert protocol version

non FIPS device, windows (same on gov and non gov):
curl --tlsv1.3 -vI -L https://ssd.mathworks.com/supportfiles/downloads/mpm/2025.1/glnxa64/mpm

• Host ssd.mathworks.com:443 was resolved.
• IPv6: (none)
• IPv4: 23.196.156.41
• Trying 23.196.156.41:443...
• schannel: disabled automatic use of client certificate
• ALPN: curl offers http/1.1
• schannel: next InitializeSecurityContext failed: SEC_E_UNSUPPORTED_FUNCTION (0x80090302) - The function requested is not supported
• closing connection #0
  curl: (35) schannel: next InitializeSecurityContext failed: SEC_E_UNSUPPORTED_FUNCTION (0x80090302) - The function requested is not supported

So perhaps there are other issues with the tslv1.3 implementation server side that are not particular to FIPS 140-3. I couldn't connect with tslv1.3 from any device successfully. I would check that behavior out on your end as well- does it work for you? The difference on these clients, that lead to 140-2 working and 140-3 not, seems to be with tslv1.2

140-3 client:

curl --tlsv1.2 -vI -L https://ssd.mathworks.com/supportfiles/downlo
ads/mpm/2025.1/glnxa64/mpm

• Trying 23.213.86.215:443...
• Connected to ssd.mathworks.com (23.213.86.215) port 443 (#0)
• ALPN, offering h2
• ALPN, offering http/1.1
• CAfile: /etc/ssl/certs/ca-certificates.crt
• CApath: /etc/ssl/certs
• TLSv1.0 (OUT), TLS header, Certificate Status (22):
• TLSv1.3 (OUT), TLS handshake, Client hello (1):
• TLSv1.2 (IN), TLS header, Certificate Status (22):
• TLSv1.3 (IN), TLS handshake, Server hello (2):
• TLSv1.2 (IN), TLS header, Certificate Status (22):
• TLSv1.2 (IN), TLS handshake, Certificate (11):
• TLSv1.2 (IN), TLS header, Certificate Status (22):
• TLSv1.2 (IN), TLS handshake, Server key exchange (12):
• TLSv1.2 (IN), TLS header, Certificate Status (22):
• TLSv1.2 (IN), TLS handshake, Server finished (14):
• TLSv1.2 (OUT), TLS header, Certificate Status (22):
• TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
• TLSv1.2 (OUT), TLS header, Unknown (21):
• TLSv1.2 (OUT), TLS alert, internal error (592):
• error:1C800073:Provider routines::invalid data
• Closing connection 0
  curl: (35) error:1C800073:Provider routines::invalid data

140-2 client:

curl --tlsv1.2 -vI -L https://ssd.mathworks.com/supportfiles/dow
nloads/mpm/2025.1/glnxa64/mpm

• Trying 23.9.151.41:443...
• TCP_NODELAY set
• Connected to ssd.mathworks.com (23.9.151.41) port 443 (#0)
• ALPN, offering h2
• ALPN, offering http/1.1
• successfully set certificate verify locations:
• CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
• TLSv1.3 (OUT), TLS handshake, Client hello (1):
• TLSv1.3 (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 handshake, Finished (20):
• SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
• ... blah blah blah (works)

So yeah, from what I can tell it seems that something is funky on your side with TLS v1.3, and then TLS v1.2 is not FIPS 140-3 compliant. Even if it was working properly on unhardened clients, the curve in TLSv1.3 (Curve 25519) is not FIPS 140-3 compliant . I think 140-3 also could be taking issue to ECDHE-RSA-CHACHA20-POLY1305, which is not FIPS 140-3 compliant, being included in your cypher suite when using TLS v1.2

-Dan

[josmartin]

@DanWoodrichNOAA Many thanks - I'm now looking into the discrepancy in our edge node TLS 1.3 implementation. Thanks to your sleuthing we know that https://www.mathworks.com is behaving differently to https://ssd.mathworks.com - which is somewhat surprising given that they are both CDN's. Will update when I know more and am hopeful that some reasonably trivial cipher updates should support your FIPS 140-3 requirements on ssd.mathworks.com.

As an aside - if you happen have any suggestions for how to get a fully FIPS 140-3 compliant docker container to test all this I would be most appreciative - I've been scouring hub.docker.com for anything that looks like it would give me a test environment and not really found anything useful (esp. for 140-3 ... there seem to be some older 140-2 alpine containers). Note that I definitely do not have a FIPS 140-3 compliant host and that would be hard to make - hence I'm only looking for a client container to mimic the test behaviour of clients.

[DanWoodrichNOAA]

@josmartin I am not aware... Ubuntu has FIPS 140-3 support through Ubuntu Pro, which is licensed.

If you have access to GCP, you can use ubuntu pro in compute engine with a pay as you go license which is all quite cheap to test. Other cloud platforms probably have equivalents.

Here's a direct link to an example marketplace image that should work to test FIPS 140-3 oob: https://console.cloud.google.com/compute/imagesDetail/projects/ubuntu-os-pro-cloud/global/images/ubuntu-pro-fips-updates-2204-jammy-v20250730

https://ubuntu.com/gcp/fips

[josmartin]

@DanWoodrichNOAA Many thanks for the tip on using Ubuntu Pro. I followed these instructions to make an ubuntu-focal-fips container on my local machine. On trying this container connecting to ssd.mathworks.com I get a valid connection using TLSv1.2 with the cipher suite

TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384

Digging into available FIPS documentation I'm struggling to get you a NIST source of truth that this cipher suite is truly FIPS 140-3 compliant (I can't really find anything on NIST that talks at this level - their doc appears to be at "parts of suite" level annoyingly). However I did find this AWS load-balancer page which says that for the Policy called ELBSecurityPolicy-TLS13-1-2-FIPS-2023-04 (which the box above shows supports TLSv1.2) the ciphers it enables contains ECDHE-ECDSA-AES256-GCM-SHA384.

Also when I ask the ubuntu-focal-fips what it's openssl considers FIPS ciphers (using ECDH as the key exchange and AES256 block cipher) I get

root@83fc04365316:/# openssl ciphers -v 'TLSv1.2+FIPS+ECDH+AES256'
TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(256) Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any      Au=any  Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-CCM  TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESCCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384

I believe the +FIPS in the above query means that it loads the OpenSSL FIPS Crypto Module to source the allowable algorithms.

This would suggest that TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 is an allowable FIPS140-3 compliant cipher.

I'll carry on working out why our CDN isn't correctly supporting TLSv1.3 for that domain, but in the mean time I wonder if something is stopping your end use of the TLSv1.2 FIPS ciphers?

[DanWoodrichNOAA]

@josmartin

I will ask somewhere on my side who knows better. I think you are correct that that named cipher and curve are ok. But my impression is that a single non allowable cipher in the suite is enough for FIPS to reject (?). I am not the expert on these topics at all, really my involvement in FIPS is when I need to work around it. It is possible other hardening policy on the device could be at play and stopping TLSv1.2

Please let me know when the TLSv1.3 issue has been worked out so I can retry.

-Dan