OS3/m68k build: "openssl s_client -connect google.com:443" doesn't work

[jens-maus]

Due to some problems the current sources compiled for OS3/m68k aren't able to initiate connections to google.com:443. When using the openssl command-line client the following output is shown:

$ openssl s_client -cipher "ECDHE-RSA-CHACHA20-POLY1305" -connect google.com:443
CONNECTED(00000000)
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.google.com
verify return:1
0:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record mac:../../openssl/ssl/record/rec_layer_s3.c:1394:SSL alert number 20
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIH7TCCBtWgAwIBAgIIBeYggpOQQCwwDQYJKoZIhvcNAQELBQAwSTELMAkGA1UE
BhMCVVMxEzARBgNVBAoTCkdvb2dsZSBJbmMxJTAjBgNVBAMTHEdvb2dsZSBJbnRl
cm5ldCBBdXRob3JpdHkgRzIwHhcNMTYxMTAzMDE0OTQxWhcNMTcwMTI2MDExMzAw
WjBmMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwN
TW91bnRhaW4gVmlldzETMBEGA1UECgwKR29vZ2xlIEluYzEVMBMGA1UEAwwMKi5n
b29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt7pS6S+Z
TDX9tGBRTxM7wcbH9z3+A0TfG0MKxTywnXviFySw2ff08QpG7NlBlPSWLlB2tQIG
OuutvHW5FPo4Z+Ie5tJ30wxbiF9ibkl43g85wiEM0Xz+xAC7YoH6WbYOP8BqOhtO
cJwjY0MSzgdD8YZOhENnWGK8uUEyTV5un1+/PTLoG/+oj7Xvwxpw+XmJMcihuxy5
W3L/sMvoWw0ZhbJIlzhNDQwjyGcVYiniJS1FS22WdCMYgLfCE63BXjdjS5P4jkA+
DgCcmz8meMevQe2mmC2VSUTBvv9mhwTc961l9DaHM3pTLRLTvOAcy1oN8M3Au9gw
b5ozrBzBfHk5swIDAQABo4IEujCCBLYwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsG
AQUFBwMCMIIDhgYDVR0RBIIDfTCCA3mCDCouZ29vZ2xlLmNvbYINKi5hbmRyb2lk
LmNvbYIWKi5hcHBlbmdpbmUuZ29vZ2xlLmNvbYISKi5jbG91ZC5nb29nbGUuY29t
ghYqLmdvb2dsZS1hbmFseXRpY3MuY29tggsqLmdvb2dsZS5jYYILKi5nb29nbGUu
Y2yCDiouZ29vZ2xlLmNvLmlugg4qLmdvb2dsZS5jby5qcIIOKi5nb29nbGUuY28u
dWuCDyouZ29vZ2xlLmNvbS5hcoIPKi5nb29nbGUuY29tLmF1gg8qLmdvb2dsZS5j
b20uYnKCDyouZ29vZ2xlLmNvbS5jb4IPKi5nb29nbGUuY29tLm14gg8qLmdvb2ds
ZS5jb20udHKCDyouZ29vZ2xlLmNvbS52boILKi5nb29nbGUuZGWCCyouZ29vZ2xl
LmVzggsqLmdvb2dsZS5mcoILKi5nb29nbGUuaHWCCyouZ29vZ2xlLml0ggsqLmdv
b2dsZS5ubIILKi5nb29nbGUucGyCCyouZ29vZ2xlLnB0ghIqLmdvb2dsZWFkYXBp
cy5jb22CDyouZ29vZ2xlYXBpcy5jboIUKi5nb29nbGVjb21tZXJjZS5jb22CESou
Z29vZ2xldmlkZW8uY29tggwqLmdzdGF0aWMuY26CDSouZ3N0YXRpYy5jb22CCiou
Z3Z0MS5jb22CCiouZ3Z0Mi5jb22CFCoubWV0cmljLmdzdGF0aWMuY29tggwqLnVy
Y2hpbi5jb22CECoudXJsLmdvb2dsZS5jb22CFioueW91dHViZS1ub2Nvb2tpZS5j
b22CDSoueW91dHViZS5jb22CFioueW91dHViZWVkdWNhdGlvbi5jb22CCyoueXRp
bWcuY29tghphbmRyb2lkLmNsaWVudHMuZ29vZ2xlLmNvbYILYW5kcm9pZC5jb22C
G2RldmVsb3Blci5hbmRyb2lkLmdvb2dsZS5jboIEZy5jb4IGZ29vLmdsghRnb29n
bGUtYW5hbHl0aWNzLmNvbYIKZ29vZ2xlLmNvbYISZ29vZ2xlY29tbWVyY2UuY29t
ghlwb2xpY3kubXRhLXN0cy5nb29nbGUuY29tggp1cmNoaW4uY29tggp3d3cuZ29v
Lmdsggh5b3V0dS5iZYILeW91dHViZS5jb22CFHlvdXR1YmVlZHVjYXRpb24uY29t
MGgGCCsGAQUFBwEBBFwwWjArBggrBgEFBQcwAoYfaHR0cDovL3BraS5nb29nbGUu
Y29tL0dJQUcyLmNydDArBggrBgEFBQcwAYYfaHR0cDovL2NsaWVudHMxLmdvb2ds
ZS5jb20vb2NzcDAdBgNVHQ4EFgQUcyFEjIFx7LZzVeInfNE27yi31cIwDAYDVR0T
AQH/BAIwADAfBgNVHSMEGDAWgBRK3QYWG7z2aLV29YG2u2IaulqBLzAhBgNVHSAE
GjAYMAwGCisGAQQB1nkCBQEwCAYGZ4EMAQICMDAGA1UdHwQpMCcwJaAjoCGGH2h0
dHA6Ly9wa2kuZ29vZ2xlLmNvbS9HSUFHMi5jcmwwDQYJKoZIhvcNAQELBQADggEB
ADOD/tov1yJDMuXXMDhol9oufYXouKtD8VkQFouNYDU0qoULpQh3sjs+n8JlHhHg
EiAYnP/S4UvIsl0rM6nSfvARdGDO69pbn9TsBef662OE+2PiROGTIS+YCxBI4HtF
aOwL8omkWwKjLEA1DdhMyOtctQr+6pzZ0VvDRzCN1E4JAEzNDNfHQ3aAeZ+RBWQB
TFUYu4hfW80Gy0Ag/kEa5zC0flLND+/8FNSE7p5+2F89MXF6hw1Bm5mF1JbPT9F2
oTDl4+YGq3XRtw32f31K7V3nLmA82d6YeBFmINtyIx2BMG8lTIPuH/A1xMD2izMB
HGvFmiBcnd517wVzteZbiNU=
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 4352 bytes and written 261 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-CHACHA20-POLY1305
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-CHACHA20-POLY1305
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 5051C5AA207195CD5A73889B2630EFF28A01CF8B046163B55565EFECC3F05DDCB962B9B1DBB52A9F6491B73892236FAE
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1479037411
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: yes
---

At the end of this output openssl doesn't change into interactive mode. Also note the following error message at the very top of the output:

0:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record mac:../../openssl/ssl/record/rec_layer_s3.c:1394:SSL alert number 20

After further investigation it seems to be related to the elliptic curve algorithms used which currently only google.com seems to be massively using worldwide. So changing the openssl command line call from:

openssl s_client -cipher "ECDHE-RSA-CHACHA20-POLY1305" -connect google.com:443 -curves X25519

to

openssl s_client -cipher "ECDHE-RSA-CHACHA20-POLY1305" -connect google.com:443 -curves prime256v1

seems to solve the issue and connection can then be initiated to google.com.

[jens-maus]

Please note that the latest commit seems to work around the issue somehow. Nor can the optimization level during compilation increased to -O2 or higher, nor can the -fomit-frame-pointer option be used or the issue appear again. This of course is a very fishy work around which might easily just hide the real root cause of the issue and which we should fix instead.

[Futaura]

Mistakenly referenced this issue in ff6c5f9 instead of #11. There are still issues using -O2 or higher. Some modules won't even compile at all in OpenSSL 1.1.1d. More investigation required.

[Futaura]

@jens-maus You are quite right about elliptic curves... Compiling https://github.com/jens-maus/amissl/blob/master/openssl/crypto/ec/curve25519.c with -O1 and everything else with -O2 or -O3 makes the example above work fine, so clearly the GCC 2.95.3 optimizer is not able to cope with this file for some reason - the code is complex, so it is hard to trace exactly. My guess is that it is related to the heavy 64-bit long long usage in the routines in that file.

One thing I have found, by checking each individual optimization enabled by -O2, is that -fexpensive-optimizations is the only switch that triggers the problem. Using -O1 -fexpensive-optimizations also generates bad code, whereas -O2 -fno-expensive-optimizations -fomit-frame-pointer and -O3 -fno-expensive-optimizations -fomit-frame-pointer generate working code. Additionally, I have tested again with -O1 -fomit-frame-pointer and that still breaks.

However, throughout OpenSSL, -O2 and -O3 are producing slightly slower code on a real 68060 than -O1. So, it is probably best we stick with -O1 anyway.

Also, I've found the following simple code will not compile with -O2 or higher on GCC 2.95.3, causing an internal compiler error in our cross compiler. On my Amiga-native GG GCC 2.95.3 build, the compiler hangs. It's the -1 array index that is causing an issue, so, clearly a compiler issue there (works in 3.3.3, for example):

amissl/openssl/crypto/x509/x_name.c

Lines 419 to 425 in d58263c

	to = from + len;
	/* Ignore trailing spaces */
	while (len > 0 && ossl_isspace(to[-1])) {
	to--;
	len--;
	}

It is easy to tweak the OpenSSL code to work around this bug, but I've not committed any changes due to -O2 generating slower code anyway.