Issues with latest CA root certificate and SSL connections (possibly OpenSSL v3 related)

You can’t do that, they are not ABI compatible. And they can be installed side by side, so even if you install Openssl 1.1.1, everything (mostly, except a few very old packages) will still use openssl3. The migration to openssl3 was done for beta 5 and I don’t think there is a need to go back to older versions.

However, I see there was recently an update to openssl 3.5. I am surprised that your log mentions openssl3-3.0.14, since we moved to 3.0.15 back in december, then 3.0.16 in march, then 3.5.0 in april. So, if the working system is from december, you are comparing 4 months of changes, there are quite a lot of things that could have changed.

I’m not sure how I can apply your suggestion with the openssl client EOF
option in combination with external tools - I need git etc.
to work, it’s not my own script or application that fails.

Maybe by setting an openssl config file:

If the current OPENSSLDIR is readonly, you can define an env OPENSSL_CONF to point to a custom openssl config file just to see if it works with ignoring EOF option.

@PulkoMandy in my latest, problematic Haiku nightly hrev58831 from today, I do have openssl-3.5 installed:

> openssl version -d
OPENSSLDIR: "/packages/openssl3-3.5.0-2/.self/data/ssl"

EOF setting doesn’t seem to help @phoudoin but I’ll see if I can get some useful debug output with openssl connections.

So I was not quite right about the timeout - this only happens in WebPositive.
In the Terminal, with a git pull..., I do get more interesting errors:

fatal: unable to access 'https://github.com/Genio-The-Haiku-IDE/Genio.git/': TLS connect error: error:00000000:lib(0)::reason(0)

Then I did a simple certificate check with openssl and got this (after quite a while which seems to be a timeout):

> openssl s_client -connect www.github.com:443 -prexit
Connecting to 140.82.121.3
CONNECTED(00000003)
closed
---
no peer certificate available
---
No client certificate CA names sent
Negotiated TLS1.3 group: <NULL>
---
SSL handshake has read 0 bytes and written 1554 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Protocol: TLSv1.3
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
no peer certificate available
---
No client certificate CA names sent
Negotiated TLS1.3 group: <NULL>
---
SSL handshake has read 0 bytes and written 1554 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Protocol: TLSv1.3
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

So something’s definitley off with my certificates. How can I ensure my setup is consistent?

from my working backup state (23.4.2025) I get this:

> openssl s_client -connect www.github.com:443 -prexit
CONNECTED(00000003)
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust ECC Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo ECC Domain Validation Secure Server CA
verify return:1
depth=0 CN = github.com
verify return:1
---
Certificate chain
 0 s:CN = github.com
   i:C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo ECC Domain Validation Secure Server CA
   a:PKEY: id-ecPublicKey, 256 (bit); sigalg: ecdsa-with-SHA256
   v:NotBefore: Feb  5 00:00:00 2025 GMT; NotAfter: Feb  5 23:59:59 2026 GMT
 1 s:C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo ECC Domain Validation Secure Server CA
   i:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust ECC Certification Authority
   a:PKEY: id-ecPublicKey, 256 (bit); sigalg: ecdsa-with-SHA384
   v:NotBefore: Nov  2 00:00:00 2018 GMT; NotAfter: Dec 31 23:59:59 2030 GMT
 2 s:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust ECC Certification Authority
   i:C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN = AAA Certificate Services
   a:PKEY: id-ecPublicKey, 384 (bit); sigalg: RSA-SHA384
   v:NotBefore: Mar 12 00:00:00 2019 GMT; NotAfter: Dec 31 23:59:59 2028 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
subject=CN = github.com
issuer=C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo ECC Domain Validation Secure Server CA
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3482 bytes and written 384 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_128_GCM_SHA256
    Session-ID: 9D420FFB0E51F5A03FE7D42C34631B91730CA391F81DC0E74AC8E93FD60B1851
    Session-ID-ctx: 
    Resumption PSK: CBFAED925D0E38E56FA74ABEA3C06C406A8AAD3D69CDFCD0818F1A041BE08D10
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 33 12 80 23 21 2f 95 56-c5 a2 41 7f bb f4 51 cc   3..#!/.V..A...Q.
    0010 - f0 a1 26 da 7c 2a 2d 10-f6 2d da f5 2c 34 f5 17   ..&.|*-..-..,4..

    Start Time: 1745863004
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_128_GCM_SHA256
    Session-ID: 48573F27C7F4DA189D54BE019A77C07F3305CDB4AE4604C87027BA91DAE4205D
    Session-ID-ctx: 
    Resumption PSK: 72D4893500BB6EB3DCB0017D5F1B60F35B4A29992FCD1D106911AD9740C2837C
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - b7 85 9e 3f e9 5b 0f e7-21 3f 23 c4 2e 1e b7 e6   ...?.[..!?#.....
    0010 - 70 78 a1 ba fc a8 12 db-d8 98 30 d6 87 d7 b0 db   px........0.....

    Start Time: 1745863004
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
closed
---
Certificate chain
 0 s:CN = github.com
   i:C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo ECC Domain Validation Secure Server CA
   a:PKEY: id-ecPublicKey, 256 (bit); sigalg: ecdsa-with-SHA256
   v:NotBefore: Feb  5 00:00:00 2025 GMT; NotAfter: Feb  5 23:59:59 2026 GMT
 1 s:C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo ECC Domain Validation Secure Server CA
   i:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust ECC Certification Authority
   a:PKEY: id-ecPublicKey, 256 (bit); sigalg: ecdsa-with-SHA384
   v:NotBefore: Nov  2 00:00:00 2018 GMT; NotAfter: Dec 31 23:59:59 2030 GMT
 2 s:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust ECC Certification Authority
   i:C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN = AAA Certificate Services
   a:PKEY: id-ecPublicKey, 384 (bit); sigalg: RSA-SHA384
   v:NotBefore: Mar 12 00:00:00 2019 GMT; NotAfter: Dec 31 23:59:59 2028 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
subject=CN = github.com
issuer=C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo ECC Domain Validation Secure Server CA
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3664 bytes and written 408 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

just tried to use the latest CA root certificate you pointed out @phoudoin in my non-working latest Haiku and got another interesting error:

~> openssl s_client -CAfile Downloads/cacert.pem -connect github.com:443
Connecting to 140.82.121.3
CONNECTED(00000003)
E001A24727000000:error:0A000126:SSL routines::unexpected eof while reading:ssl/record/rec_layer_s3.c:691:
---
no peer certificate available
---
No client certificate CA names sent
Negotiated TLS1.3 group: <NULL>
---
SSL handshake has read 0 bytes and written 1557 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Protocol: TLSv1.3
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

PS: probably unrelated, but I even managed to crash git during a push (!) twice now:

Haiku revision: hrev58829 Apr 23 2025 06:02:18 (x86_64)

Active Threads:
	thread 5638: pthread func 
	thread 5640: team 5637 debug task 
	thread 5637: git (main)
		state: Call (mutex was not actually locked!)

		Frame		IP			Function Name
		-----------------------------------------------
		00000000	0x8f0288d4b7	_kern_debugger + 0x7 
			Disassembly:
				_kern_debugger:
				0x0000008f0288d4b0:   48c7c0ec000000  mov $0xec, %rax
				0x0000008f0288d4b7:             0f05  syscall <--

		0x7f8f5a6ae5e0	0x8f0290a57e	__heap_after_fork_parent + 0x3e 
		0x7f8f5a6ae610	0x8f02901c18	fork + 0xf8 
		0x7f8f5a6ae710	0x4c5ce2fcd5	start_command + 0x3c5 
		0x7f8f5a6ae960	0x4c5ce33317	send_pack + 0x707 
		0x7f8f5a6af250	0x4c5ccc8ef6	cmd_send_pack + 0xa16 
		0x7f8f5a6af330	0x4c5cc12eff	/boot/system/lib/git-core/git + 0x61eff 
		0x7f8f5a6af450	0x4c5cc14018	/boot/system/lib/git-core/git + 0x63018 
		0x7f8f5a6af4b0	0x4c5cc14b31	cmd_main + 0xf1 
		0x7f8f5a6af510	0x4c5cc12baf	main + 0xcf 
		0x7f8f5a6af540	0x4c5cc12cf9	_start + 0x39 
		0x7f8f5a6af570	0x6d4734a383	runtime_loader + 0x113 
		00000000	0x7ffff8007258	commpage_thread_exit + 0 

more on topic, another interesting observation (this is on hrev58841 now):

  • opening the SEN website works fine, but I cannot reach GitHub
  • both are served from github in the end, as SEN web site redirects to a static GitHub pages site.

So it has definitely something to do with the route and intermediaries, IP origin and whatever which sometimes breaks my network connection and which worked fine before updating OpenSSL.

@PulkoMandy also saw this once with git, but it doesn’t seem to reproduce reliably. These mutexes should absolutely never be unlocked in this state, and I don’t know how they could be. Something strange may be going on with memory. The fact that the problem has only happened with git so far is interesting.

1 Like

ok so I digged into the openssl-3.5.0.2 vs openssl-3.0.14.2 package contents and already the openssl.cnf contain some significant changes:

diff /packages/openssl3-3.5.0-2/.self/data/ssl/openssl.cnf data/ssl/openssl.cnf
16c16
< # Use this in order to automatically load providers.
---
>  # Use this in order to automatically load providers.
95c95
< private_key   = $dir/private/cakey.pem # The private key
---
> private_key   = $dir/private/cakey.pem# The private key
333,334c333,334
< ess_cert_id_alg               = sha256        # algorithm to compute certificate
<                               # identifier (optional, default: sha256)
---
> ess_cert_id_alg               = sha1  # algorithm to compute certificate
>                               # identifier (optional, default: sha1)
345,346c345,346
< ignore_keyusage = 1 # quirk needed to accept Insta CA cert not including digitalsignature
< unprotected_errors = 1 # quirk needed to accept negative responses possibly not protected
---
> ignore_keyusage = 1 # potentially needed quirk
> unprotected_errors = 1 # potentially needed quirk

Notice the different encoding sha1 vs sha256 - maybe the cacert has not been re-encoded or there is some other conflict in the format OpenSSL 3.5 now expects and the ssl-cert package shipped one?

Also maybe even a potentially breaking # comment (without whitespace after the value - in some cases I had issues with this) in the line:

private_key = $dir/private/cakey.pem# The private key

(the old OpenSSL package had a whitespace between value and comment, so maybe the private_key value is not set and hence the certificate not found?

I will dig some more in potential breaking changes, but the question remains:
Why does it seem I am the only one having issues, when my network is the same, everthing worked ifne until the update in OpenSSL, and I have no issues on other systems like Linux in the same environment… :thinking:

Another fun fact with my mysteriously broken openssl setup:

another test run with latest nightly hrev58861 and according to this docs:

I get different results for Gitlab (works) and Github (fails).
I could really need some help here from Haiku devs/SSL experts, as I’d rather focus on SEN again now;-(

  1. SSL connection to Gitlab works fine:
~> echo | openssl s_client -connect www.gitlab.com:443
Connecting to 172.65.251.78
CONNECTED(00000003)
depth=2 C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority
verify return:1
depth=1 C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited, CN=Sectigo RSA Domain Validation Secure Server CA
verify return:1
depth=0 CN=gitlab.com
verify return:1
---
Certificate chain
 0 s:CN=gitlab.com
   i:C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited, CN=Sectigo RSA Domain Validation Secure Server CA
   a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
   v:NotBefore: Apr 12 00:00:00 2025 GMT; NotAfter: May 11 23:59:59 2026 GMT
 1 s:C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited, CN=Sectigo RSA Domain Validation Secure Server CA
   i:C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority
   a:PKEY: RSA, 2048 (bit); sigalg: sha384WithRSAEncryption
   v:NotBefore: Nov  2 00:00:00 2018 GMT; NotAfter: Dec 31 23:59:59 2030 GMT
 2 s:C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority
   i:C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority
   a:PKEY: RSA, 4096 (bit); sigalg: sha384WithRSAEncryption
   v:NotBefore: Feb  1 00:00:00 2010 GMT; NotAfter: Jan 18 23:59:59 2038 GMT
---
Server certificate
...
subject=CN=gitlab.com
issuer=C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited, CN=Sectigo RSA Domain Validation Secure Server CA
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: rsa_pss_rsae_sha256
Negotiated TLS1.3 group: X25519MLKEM768
---
SSL handshake has read 6327 bytes and written 1634 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Protocol: TLSv1.3
Server public key is 2048 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
DONE
  1. the same test against github.com does not work:
~> echo | openssl s_client -connect www.github.com:443
Connecting to 140.82.121.3
CONNECTED(00000003)
E0C1F432B7010000:error:0A000126:SSL routines::unexpected eof while reading:ssl/record/rec_layer_s3.c:691:
---
no peer certificate available
---
No client certificate CA names sent
Negotiated TLS1.3 group: <NULL>
---
SSL handshake has read 0 bytes and written 1561 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Protocol: TLSv1.3
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)

In both cases I see that

No client certificate CA names sent

but in the Gitlab case I still get a peer certificate :thinking: .
This error seems to point to the root cause, but I have no idea why it occurs:

E0C1F432B7010000:error:0A000126:SSL routines::unexpected eof while reading:ssl/record/rec_layer_s3.c:691:

I also checked the contents of my CAcert and it’s fine, same as the latest one I downloaded manually:

~> openssl x509 -in /boot/home/Downloads/cacert.pem -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            04:00:00:00:00:01:15:4b:5a:c3:94
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA
        Validity
            Not Before: Sep  1 12:00:00 1998 GMT
            Not After : Jan 28 12:00:00 2028 GMT
        Subject: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                   ...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier: 
                60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B
    Signature Algorithm: sha1WithRSAEncryption
    Signature Value:
...

This is normal and not an error. In the typical use of ssl with https, there is a server certificate, that allows you to check you are connecting to the right server. There is no client certificate because the server does not care who you are.

So, this log is just saying that: no certificate in that direction.

Other than that, I think you should ask openssl devs for support, it doesn’t look like Haiku code is involved here?

re certificate: ok that makes sense.
But that was only a side story, the real problem is this error message in the log:

E0C1F432B7010000:error:0A000126:SSL routines::unexpected eof while reading:ssl/record/rec_layer_s3.c:691:

However since it’s working fine in Linux with the same version (will check though and generate a similar connection log to compare), I do think it’s Haiku specific. At least that’s what OpenSSL devs will tell me.

I just set up a QEMU VM with a fresh nightly on the weekend and after the first update it broke again and shows the same connection issues as my local setup.

as promised, here is a log from an equivalent but working connection to github from Linux (6.14.4-1-MANJARO, OpenSSL 3.5.0 8 Apr 2025 (Library: OpenSSL 3.5.0 8 Apr 2025)

echo | openssl s_client -connect www.github.com:443                                                                                         ✔ 
Connecting to 140.82.121.4
CONNECTED(00000003)
depth=2 C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust ECC Certification Authority
verify return:1
depth=1 C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited, CN=Sectigo ECC Domain Validation Secure Server CA
verify return:1
depth=0 CN=github.com
verify return:1
---
Certificate chain
 0 s:CN=github.com
   i:C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited, CN=Sectigo ECC Domain Validation Secure Server CA
   a:PKEY: EC, (prime256v1); sigalg: ecdsa-with-SHA256
   v:NotBefore: Feb  5 00:00:00 2025 GMT; NotAfter: Feb  5 23:59:59 2026 GMT
 1 s:C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited, CN=Sectigo ECC Domain Validation Secure Server CA
   i:C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust ECC Certification Authority
   a:PKEY: EC, (prime256v1); sigalg: ecdsa-with-SHA384
   v:NotBefore: Nov  2 00:00:00 2018 GMT; NotAfter: Dec 31 23:59:59 2030 GMT
 2 s:C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust ECC Certification Authority
   i:C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=AAA Certificate Services
   a:PKEY: EC, (secp384r1); sigalg: sha384WithRSAEncryption
   v:NotBefore: Mar 12 00:00:00 2019 GMT; NotAfter: Dec 31 23:59:59 2028 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
subject=CN=github.com
issuer=C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited, CN=Sectigo ECC Domain Validation Secure Server CA
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ecdsa_secp256r1_sha256
Peer Temp Key: X25519, 253 bits
---
SSL handshake has read 3481 bytes and written 1611 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Protocol: TLSv1.3
Server public key is 256 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
DONE

Yes it also says:

No client certificate CA names sent

but there is no error in the log and the CA issuers chain is returned as it should, resulting in a working handshake:

SSL handshake has read 3481 bytes and written 1611 bytes
Verification: OK

So it’s definitely not an OpenSSL but a Haiku issue and it has something to do with the SSL configuration, possibly some update script ruining it during a kernel upgrade (when going from latest nightly to the next one).

I can prove that also with the VM situation, which shows that something is going downhill on updating the system from one nightly to the other:

  1. I downloaded the latest nightly end of last week from 9/5/2025
  2. everthing works (same openssl client log as in linux with gtihub)
  3. update using SoftwareUpdater or pkgman
  4. reboot, get the error log, github connection fails.

Just checked again and could reproduce, but the only packages upgraded were the kernel, datatranslations and Webpositive, no ssl stuff, and no config script ran on next boot (the sshkeygen script only runs on a fresh install anyway).

1 Like

Could you use tcpdump command line tool to capture the traffic at your network interface while running the openssl s_client command under Haiku?

It seems to choke while reading the handshake ssl records:

SSL handshake has read 6327 bytes and written 1634 bytes

vs

SSL handshake has read 0 bytes and written 1561 bytes

Clearly, the reading of the server reply (ServerHello handshake SSL message) failed on the very beginning of the parsing of its content.

I failed to see how the content of CA file could have impact here, the server certificate is not transmitted in the first TLS record of the server messages, far from it.

The difference of bytes written (by client) is due to different client behavior without any server SSL handshake information (no supported protocols, no supported ciphers, etc). The root issue is behind this “read 0 bytes”.
A tcpdump capture could help to investigate what the client actually received and hopefully allow to understand why it fail at reading and parsing the TLS records in the SSL Handshake message from the server.

You can also test if it behave differently when you force the client to accept only TLS 1.2 for instance, forcing thefore github.com server to fallback on TLS 1.2? Use -tls1_2 option of openssl s_client comman to do that.

2 Likes

tcpdump shows only this suspicious message several times, nothing interesting besides that:

IP lb-140-82-121-3-fra.github.com > grexbox.telekom.ip: ICMP ip reassembly time exceeded, length 556

So something is off, but I have no clue yet why this happens, a good explanation I found is here:
https://supportportal.juniper.net/s/article/What-does-ICMP-fail-with-Frag-reassembly-time-exceeded-error-mean?language=en_US

In other research, I found that sometimes the MTU can cause issues if it is too small or too big.

You can also test if it behave differently when you force the client to accept only TLS 1.2 for instance, forcing thefore github.com server to fallback on TLS 1.2? Use -tls1_2 option of openssl s_client comman to do that.

darn, that worked!
Could have sworn I tried that already, but with this option, I get an instant response that looks like the legit response in the positive tests.

So now the question is: Why is TLS broken and how can I force the system to use TLS 1.2 throughout? Or even better: How to fix latest TLS?

1 Like

TLs 1.3 connection negotiation has differences to TLS 1.2 (including support for less roundtrips)

In theory this can be faster aswell, but the question is why this goes wrong then…

1 Like

I found the right way to set this option as default in openssl, but that doesn’t help for separate tools like git, which I would need the most.

For reference, set this in your ENV:

OPENSSL_CONF=/boot/home/config/settings/openssl.conf

and add this option in your openssl.conf:

MaxProtocol = TLSv1.2

Okay, so it seems that your issue root cause is:

  • in TLS v1.2, multiple TCP messages are sent by server in reply to a ClientHello from a client, leading to smaller payloads in each message, which can be smaller than the MTU.
  • in TLS v1.3, the client try to already select/guess default probable server supported options, leading to a larger ClientHello message that can be larger than MTU, and therefore probable fragmentation, and the server reply is one single message too when the pre-selected/guessed options are indeed supported by the server, which make this reply most probably larger than the MTU, leading to IP fragmentation of the server reply too.
  • your network route between your machine and github.com seems to fail somewhere in the journey to reassemble it in due time (seems to be the github server reporting it), leading to partial/empty/truncated/empty/missing reply payload, and therefore the failure to parse its content, and to establish the TLS connection.

The fact that your host receive an ICMP message notifying a reassembly failure, from github.com server, makes me suspect that:

  • either Haiku TCP/IP stack failed to send in due time to this server all the IP fragments of the ClientHello message
  • some routers in between failed to do it, potentially on the server reply.

Considering that the default MTU is probably lower already at your haiku network interface, I will bet the fragmentation happened on Haiku side.

If you can share the tcpdump regarding the IP packets from you Haiku toward the github server, it could help to see if the fragments were correctly emitted or not.

2 Likes

What about:

git config --global http.sslVersion "tlsv1.2"

?

https://git-scm.com/docs/git-config#Documentation/git-config.txt-httpsslVersion

1 Like