On real 68k hardware certain connections are being dropped during SSL handshake

[jens-maus]

In a recent YAM issue ticket (see https://github.com/jens-maus/yam/issues/651) a user is reporting connection problems with his real A1200/68060 system. After some investigation it seems that not YAM can be blamed, but the problem already appear if he is using the openssl command-line tool to initiate a test connection via the following command sequence:

openssl s_client -debug -connect pop3.live.com:995

After execution of the command the openssl command doesn't switch to interactive connection mode and the POP3 server doesn't report with plain text +OK that the connection succeeded. Looking at the debug output one can see that after outputting the certificate chain it actually output some write:errno=32 error which means "Broken pipe":

[...]
depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
verify return:1
depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign Organization Validation CA - SHA256 - G2
verify return:1
depth=0 C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = *.hotmail.com
verify return:1
write to 0x60ca7a7c [0x60c5f40c] (166 bytes => -1 (0xFFFFFFFF))
write:errno=32
[...]

As said, errno=32 stands for "Broken pipe" and could easily mean the mail server had already canceled/dropped the connection to to waiting to long for a response. The current suspicion is that due to unknown reasons certain cipher/certificate digest calculations might take to long so that the server drops connection and the openssl tries to continue communication with the server, but fails of course.

Some debugging are required and thus we should generate a openssl command line binary with more debugging output between the certificate output and the successive write commands. In addition, some timing information have to be added to be able to verify if some calculations are really taking to long.

[jens-maus]

@Futaura Can you please try to reproduce this issue on your real m68k hardware system?

[jerseywurzel]

How do I revert to AmiSSL 3, to test this?

[Futaura]

@jens-maus Unfortunately, AmigaKit still have my real m68k hardware :-(

@jerseywurzel Simply using an older version of YAM or the old v3 OpenSSL tool will use the AmiSSL v3 library

[Futaura]

Not that it probably helps much, but this works correctly using AmiSSL 68k under emulation on OS4. I do know that with AmiSSL v3, old style DH ciphers were heavily CPU intensive on my 68060, which made HTTPS connections really slow (hence DH was disabled by default in IBrowse).

[jerseywurzel]

@futaura How can I backtrack to v3? I updated amissl to v4 using the installer, has it overwritten the old version? Thanks

[Futaura]

@jerseywurzel No - you should have both the v3 and v4 libs installed already (check AmiSSL:Libs/AmiSSL). The installer will have overwritten the v3 OpenSSL tool though, so you need to download that to test the OpenSSL tool with v3.

[jerseywurzel]

@Futaura I downloaded AmiSSL3.6 and changed the OpenSSL and AmiSSL3 libs back. I couldn't get a connection because something was looking for AmiSSL4. This was from the CLI, not YAM I left OpenSSL3.6 but re-enabled AmiSSL4 and then I got something. Instead or errno 32 as before, I got errno 54 Don't` know if that points to anything?

[Weber-Frank]

I use here a real Amiga 2000 with a Blizzard 2060 at 50MHz and OS 3.9 with MiamiDX. I execute the command and it needed 18.8 seconds until "+OK DUB006-POP301 POP3 server ready" Until timeout and show the cursor it needed 79 seconds. Here is the output:

[...]
New, SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : ECDHE-RSA-AES256-SHA
    Session-ID: F34C0000E28E26998714CE8D7236B2AF37061CE2976E1D1DA789D9AE9587EDFC
    Session-ID-ctx: 
    Master-Key: 7DA8224DFB93270CDAF00C053096FA480173666AE54062E476F23A2DC013484624642C2D1EAF323C1C2328F8233CD3EB
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1486939596
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: yes
---
read from 0xa6941fc [0xa7470fb] (5 bytes => 5 (0x5))
0000 - 17 03 01 00 40                                    ....@
read from 0xa6941fc [0xa747100] (64 bytes => 64 (0x40))
0000 - b5 c7 04 83 8f f4 f6 1c-5e b2 6a 5a 66 d0 12 1e   ........^.jZf...
0010 - e3 1f 9c 4b cd 6e b6 d3-7f 80 31 0c 15 9e d1 fd   ...K.n....1.....
0020 - d7 e4 84 cd 3b e7 a2 67-95 57 cf c7 0c e7 36 ab   ....;..g.W....6.
0030 - 1a e3 d9 c9 ca b5 31 b8-96 c7 71 21 90 a9 92 d9   ......1...q!....
+OK DUB006-POP301 POP3 server ready
read from 0xa6941fc [0xa7470fb] (5 bytes => -1 (0xFFFFFFFF))
read:errno=54
write to 0xa6941fc [0xa74b25b] (37 bytes => -1 (0xFFFFFFFF))
12.Ram_Disk:>   

[jens-maus]

@jerseywurzel No, this means more or less the same, the peer (mail server) has closed the connection. I am really more and more convinced that all these modern encryption algorithms require more processing power than all these obsolete real 68k processors can provide.

[jens-maus]

@Weber-Frank This is very interesting Frank. Can you please say which TCP/IP stack you are using and which internet connection do you have? Perhaps this is also related to the TCP/IP stack type or internet connection speed or something like this. Because I am surprise that the test connection works for you.

[Weber-Frank]

i do the same with the yahoo server. I execute the command and it needed 19.1 seconds until "+OK hello from jpop-0.1" Until timeout and show the cursor it needed 136 seconds. Here is the output:

[...]
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Sunnyvale/O=Yahoo Inc./OU=Information Technology/CN=legacy.pop.mail.yahoo.com
issuer=/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server CA - G4
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 5284 bytes and written 302 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
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-AES256-GCM-SHA384
    Session-ID: 58A0D9D50DF660BE0D8BED1C373732BDE32C06FD95EF868733D52DD0E0A32CFF
    Session-ID-ctx: 
    Master-Key: F5BF869F2E6C9811EA752F3C8B57736663341B18305DD179BA05BC247213C706080F6BE0D08FB72297A4A41227D98FA3
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1486939812
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---
read from 0xa69421c [0xa7470fb] (5 bytes => 5 (0x5))
0000 - 17 03 03 00 31                                    ....1
read from 0xa69421c [0xa747100] (49 bytes => 49 (0x31))
0000 - 00 00 00 00 00 00 00 01-9f 71 24 38 1d 16 ae db   .........q$8....
0010 - 8a 51 e5 cc ad 55 df 44-55 75 f4 71 6d 82 ad ef   .Q...U.DUu.qm...
0020 - 11 ca 9c 7e 97 0d 54 2b-c6 fd ed a0 7d d1 2c 02   ...~..T+....}.,.
0030 - a0                                                .
+OK hello from jpop-0.1
read from 0xa69421c [0xa7470fb] (5 bytes => 5 (0x5))
0000 - 15 03 03 00 1a                                    .....
read from 0xa69421c [0xa747100] (26 bytes => 26 (0x1A))
0000 - 00 00 00 00 00 00 00 02-cd bf 44 87 39 28 49 73   ..........D.9(Is
0010 - aa f2 ed 82 9a 68 d0 24-c8 e0                     .....h.$..
closed
write to 0xa69421c [0xa74b25b] (31 bytes => 31 (0x1F))
0000 - 15 03 03 00 1a e3 92 d3-71 39 0e ee 29 2e 37 6f   ........q9..).7o
0010 - 01 5f 3b 6e c2 8d 47 3c-40 f5 78 fd ce 7f 98      ._;n..G<@.x....
12.Ram_Disk:>   

I do the same again an try to log in (of course with a wrong password). Here is the output (i have cut the upper part):

...
+OK hello from jpop-0.1
›71mUSER Opionline
›51mwrite to 0xa5fabbc [0xa61428b] (44 bytes => 44 (0x2C))
0000 - 17 03 03 00 27 42 e7 48-46 2d fe 96 0e 52 52 e5   ....'B.HF-...RR.
0010 - 8b 2c 52 01 d4 aa bf b9-b5 c7 f6 61 54 17 a5 61   .,R........aT..a
0020 - 10 b5 62 ca c2 c0 59 55-d7 cf a7 fc               ..b...YU....
read from 0xa5fabbc [0xa60454b] (5 bytes => 5 (0x5))
0000 - 17 03 03 00 30                                    ....0
read from 0xa5fabbc [0xa604550] (48 bytes => 48 (0x30))
0000 - 00 00 00 00 00 00 00 02-72 0b 56 22 42 06 dc 10   ........r.V"B...
0010 - 89 df d3 81 ac eb 07 ae-9f 1a 98 29 34 50 5c 15   ...........)4P\.
0020 - 58 0c b6 59 50 00 f7 de-b8 7e 57 d3 dc b7 37 15   X..YP....~W...7.
+OK password required.
›71mPASS Test
›51mwrite to 0xa5fabbc [0xa61428b] (39 bytes => 39 (0x27))
0000 - 17 03 03 00 22 42 e7 48-46 2d fe 96 0f c6 da 4a   ...."B.HF-.....J
0010 - 97 b5 18 b0 58 e2 8e d0-b6 97 a2 e8 b8 86 29 08   ....X.........).
0020 - 0e 08 d5 ff c7 b2 2c                              ......,
read from 0xa5fabbc [0xa60454b] (5 bytes => 5 (0x5))
0000 - 17 03 03 00 50                                    ....P
read from 0xa5fabbc [0xa604550] (80 bytes => 80 (0x50))
0000 - 00 00 00 00 00 00 00 03-07 d2 79 c4 b9 d5 18 d6   ..........y.....
0010 - ce d3 57 53 71 6b 8e ca-b9 c6 cb ec 63 a3 46 a0   ..WSqk......c.F.
0020 - 24 1a 8d 8c 74 fa 18 8e-5d d8 8f 76 da 94 33 38   $...t...]..v..38
0030 - bd 66 d7 2b b0 1c 69 5c-84 6e d9 45 97 b4 20 81   .f.+..i\.n.E.. .
0040 - a1 15 08 a6 ef 21 bc 20-cc b4 9a 5e 85 85 c4 d9   .....!. ...^....
-ERR Server error - Please try again later. [SYS/TEMP]

It seems all is working correct here on a 68060. :-)

[Weber-Frank]

@jens-maus See my first post in this ticket. i wrote: I use here a real Amiga 2000 with a Blizzard 2060 at 50MHz and OS 3.9 with MiamiDX. I think that say all what you need. :-)

btw. i do the same again with the correkt password and get:

... here was the Password part...
read from 0xa5f9ba4 [0xa60454b] (5 bytes => 5 (0x5))
0000 - 17 03 03 00 4b                                    ....K
read from 0xa5f9ba4 [0xa604550] (75 bytes => 75 (0x4B))
0000 - 00 00 00 00 00 00 00 03-cd 8c c9 02 c7 d7 f5 ce   ................
0010 - 72 ab 48 76 79 38 c4 e0-60 7f 2f 2d 7b bd 54 77   r.Hvy8..`./-{.Tw
0020 - 82 4d 36 db 70 13 1c a5-98 f2 88 63 16 1c 46 67   .M6.p......c..Fg
0030 - eb b3 ff 5e 65 f6 99 13-c2 17 5d d7 37 73 3b 70   ...^e.....].7s;p
0040 - e7 58 90 19 a6 e7 0b 23-dc a3 40                  .X.....#..@
+OK maildrop ready, 149 messages (2773042 octets)

[Weber-Frank]

Sorry i forget to say my connection speed. I have here a 16 Mbit DSL connection which is in real only 12 Mbit.

[jerseywurzel]

I use Miami, I have fibre broadband with up to 50mb download speeds

[jens-maus]

@jerseywurzel Ok, thanks for this information. I am, however, still curious why @Weber-Frank isn't having any issues with his A2000/060 while your A1200/060 installation shows this issue? Which operating system versions are you guys using and also please state the exact Miami version you are using.

[jens-maus]

@Futaura Could it be that this issue is somehow related to #8 ? What do you think?

@jerseywurzel @Weber-Frank Can you guys please try to execute openssl s_client -connect google.com:443 and see if this shows an error as well? And please do not post all the lengthy openssl debug output, but concentrate on the relevant output or upload your *.txt files here.

[tboeckel]

I mocked up a tiny program which reads stdin line by line and outputs each line immediately again to stdout prefixed by the elapsed time since program start. This makes it possible for us to monitor the time spent until the desired output is created.

tsstdin.zip

If you have the PIPE command installed (don't confuse it with the PIPE: handler) you should be able to call it like this: openssl s_client -debug -connect pop3.live.com:995 | tsstdin

Otherwise you have to open two shell windows. In the first one enter this: tsstdin <pipe:foo

And in the second one enter this: openssl s_client -debug -connect pop3.live.com:995 >pipe:foo

The output will then look like this:

[       3.332619] CONNECTED(00000000)
[       3.337045] write to 0x114def44 [0x114f2b58] (176 bytes => 176 (0xB0))
[       3.338520] 0000 - 16 03 01 00 ab 01 00 00-a7 03 03 d8 f5 d9 f0 bc   ................
[       3.339354] 0010 - 10 2e f1 76 4c 42 3b ba-5a 48 2a b7 bd 22 67 cf   ...vLB;.ZH*.."g.
[       3.340252] 0020 - ef 4f e9 29 be 96 a5 d7-b2 99 da 00 00 38 c0 2c   .O.).........8.,
[       3.341664] 0030 - c0 30 00 9f cc a9 cc a8-cc aa c0 2b c0 2f 00 9e   .0.........+./..
[       3.342497] 0040 - c0 24 c0 28 00 6b c0 23-c0 27 00 67 c0 0a c0 14   .$.(.k.#.'.g....
[       3.343203] 0050 - 00 39 c0 09 c0 13 00 33-00 9d 00 9c 00 3d 00 3c   .9.....3.....=.<
[       3.343908] 0060 - 00 35 00 2f 00 ff 01 00-00 46 00 0b 00 04 03 00   .5./.....F......
[       3.344742] 0070 - 01 02 00 0a 00 0a 00 08-00 1d 00 17 00 19 00 18   ................
[       3.345960] 0080 - 00 23 00 00 00 0d 00 20-00 1e 06 01 06 02 06 03   .#..... ........
[       3.346858] 0090 - 05 01 05 02 05 03 04 01-04 02 04 03 03 01 03 02   ................
[       3.347753] 00a0 - 03 03 02 01 02 02 02 03-00 16 00 00 00 17         ..............
[       3.348462] 00b0 - <SPACES/NULS>
[       3.349104] read from 0x114def44 [0x114e7c53] (5 bytes => 5 (0x5))
[...]

Perhaps this tool will expose how much time is spent during the individual steps.

[jerseywurzel]

A quick test that @Jens-maus asked for shows errno54.

Question: @futuaura showed on IBrowse website, how to disable TSLv2 and v3 using Setenv. Would that be a possibility?

[jerseywurzel]

@Futaura see above comment

[Weber-Frank]

@jens-maus I use here MiamiDeluxe 1.0c (10.04.2000). I add the output for both servers with Thores tool used in the two windows version. @tboeckel Your tool seems not working correct because

1. here are many "-" signs in the output and
2. it show not the real point of delay :-( e.g. my outputfile FW1-pop3.live.com-995.txt Your tool show the long delay between the lines

   [      18.-168998] read from 0xa1f83b4 [0xa20157b] (5 bytes => 5 (0x5))
   [      77.229613] 0000 - 16 03 01 00 30                                    ....0 

   but the delay is in reality after the line +OK BLU003-POP256 POP3 server ready (The server waits for input and timed out) btw: In reality the above line is a seperate line in the cli. In the output it is not a seperate line.

[Weber-Frank]

# FW1-pop3.live.com-995.txt FW1-google.com-443.txt

[Futaura]

@jerseywurzel I think the environment vars you refer to have been completely removed from AmiSSL v4, so no those shouldn't be a factor. Of course, AmiSSL v3 will still read them as before.

[Futaura]

I really wish I had my A1200 mobo back right now... I'm wondering if it could be something as "simple" as a MTU related issue or some other TCP setting in MiamiDx, especially as not all MiamiDx appear to have this issue. Having the MTU set incorrectly can certainly break SSL connections, as I had that problem in the past. IBrowse seems to be running fine now on a 060 with MiamiDx.

[tboeckel]

Here is new version of tsstdin. The time calculation should be correct now. It was wrong to unsigned integers used by clib2. tsstdin.zip

[jerseywurzel]

Ok, I have tried to revert to AmiSSL3, by renaming OpenSSL latest version, so its not recognised and so should load V3 AmiSSL. It doesnt work because something recognises that AmiSSL4 is not installed. I have tried various combinations of renaming OpenSSL and AmiSSL so that V4 is not picked up, but I still cannot connect with errno 32 or 54 every time. Enclosed is the latest log which has errno zero but now I`m stumped. Even with AmiSSL 3 running, the latest nightly build of YAM insists that AMiSSL4 be running, or it quits. I just cannot get YAM to download mails any more. Any further ideas? debug.pdf

[Futaura]

You're misunderstanding the way AmiSSL works - it's not like regular libraries. Applications are tied to a specific version of AmiSSL - you can't make the latest version of YAM use AmiSSL v3, just like you can't make older applications use AmiSSL v4, simply by renaming the libraries.

For example, the OpenSSL tool supplied with AmiSSL v3 will always open AmiSSL v3, and the OpenSSL tool supplied with AmiSSL v4 will always open AmiSSL v4. You can have multiple versions of AmiSSL installed simultaneously, which is recommended. No special configuration is required - just install v4 over v3.

[Weber-Frank]

@tboeckel Is your tool now a part of Amissl? Should we open a extra ticket for this? Should your recent changes commited? I attach the output here as FW2-pop3.live.com-995.txt. The displayd time is ok now but the problem that your tsstdin tool doesn't show the correct point of delay still exists. FW2-pop3.live.com-995.txt

[jens-maus]

@jerseywurzel Can you please run the openssl s_client test like @Weber-Frank with tsstdin? I am curious about your actual delay times.

[jens-maus]

And can you guys please use the following s_client command to debug further:

openssl s_client -debug -connect pop3.live.com:995 -msg

Note that I added the -msg option to output more on the TLS handshake.

[jens-maus]

Please find attached a debug version of the openssl tool which will not enter the interactive mode at the end. Please use that one for your tests with tsstdin so that are output times are in correct order.

openssl-debug.zip

[jerseywurzel]

@Futaura You're right, I didn't understand but I think I do now. @jens-maus Is there any way to test if my system still can connect with pop3.live.com using AmiSSL3? The latest build of YAM seems to require AmiSSL4? Thanks both

[jerseywurzel]

@jens-maus I enclose some logs, forgive me if they're not correct, this stuff is new to me. I had trouble with Thore's original command " | tsstdin" so had to resort to using 2 shell windows. I hope these help but if not, I`m happy to try again. log.txt msg.txt

[Weber-Frank]

@jerseywurzel If you use a YAM version build before AmiSSL V4 was added then this Version should use AmiSSL V3. @jens-maus I Attach my log as FW3-pop3.live.com-995.txt, build with -msg option and using the tsstdin tool. The output still not show the correct delay like in a CLI. I made a Video and try to upload it here ASAP, it seems it's to big so i must convert it first. FW3-pop3.live.com-995.txt

[Weber-Frank]

I attach the Video here. please delete the .pdf part in the filename. As you can see the biggest delay is in the video at 13 seconds and stay until 20 seconds. I can't see the delay in the output from the tsstdin tool.

VideoLog2.mp4.pdf

[jens-maus]

@Weber-Frank Sorry, but I cannot read anything on the video, It has a too low resolution. And anyway such video don't really help a lot. I think I will have to provide you guys with another openssl debug binary which directly outputs something without tsstdin. Due to output buffering this doesn't seem to work well, I am afraid.

[Weber-Frank]

Unfortunately, the video was not meant to read anything. It should show the delay that does not appear in the tsstdin output. The delay is clearly visible. If you want to read something, use the txt file. This contains almost exactly the same data that was visible on the screen. I'll wait for a new openssl debug version.

[Futaura]

So, the MS server as a 60 second timeout, Yahoo 120 second and Gmail 10 minutes! Although I suppose these may vary throughout their server farms. But, if it takes under 60 seconds on @Weber-Frank 's 68060, but much longer on @jerseywurzel 's then either something else is eating CPU cycles, slowing AmiSSL down or @Weber-Frank has some good system speedup patches installed. This is a assuming the delay is not a network stall of some kind, which Miamitcpdump may be able to help debug.

Are there any decent tools on 68k to measure CPU loading and/or benchmark CPU performance? It would be useful to compare the systems and to check if CPU is loaded during the delay.

[jerseywurzel]

@Futaura @Weber-Frank There is Syspeed, which although not perfect, does give an idea. I`ll post my results later, see if that helps

[jerseywurzel]

Here you are:

[Futaura]

@jerseywurzel @Weber-Frank Probably sysinfo is not ideal as, IIRC, it runs at a high priority and disables multitasking. How about the distributed.net client? Just run it from the shell with "dnetc -benchmark" - if you don't already have it installed, download from http://http.distributed.net/pub/dcti/current-client/dnetc-amigaos-68k.lha and unpack it to the ram disk and run from there. This will run at normal priority, so comparing both your results could indicate if you have some background process hogging the processor.

[jerseywurzel]

@Futaura dnetc.pdf Hi Oliver, Hope this is what you want.

[Futaura]

@jerseywurzel doesn't look too bad - only 5% off top speed. I wouldn't expect the results from @Weber-Frank will be much different. Which doesn't get us any closer on pinpointing the issue unfortunately. It could still be a network misconfiguration somewhere, but hard for me to do much more until I get my A1200 mobo back.

[jerseywurzel]

@jens-maus @Futaura Ok, so I enclose 2 logs from openssl s_client -debug pop3.live.com:995, though in the same file. The 1st is using opensslv3 and the 2nd using opensslv4. I don`t know if that helps any. openssllog.pdf

[jens-maus]

@jerseywurzel Thanks for the two logs. Just out of interest, please try the following openssl command with AmiSSLv4 to force the same cipher algorithms being used:

openssl s_client -cipher AES256-SHA -debug -connect pop3.live.com:995

[jerseywurzel]

@jens-maus Hre you are Jens-Maus. I'm curious, to me, the v3 log shows that it didn't connect, correct? If so, that`s strange and would point to something else being wrong as I'd always been able to download emails prior to the latest YAM nightly build and before AMiSSLv4. cipherdebug.pdf

[jens-maus]

@jerseywurzel Why do you think it didn't connect correctly? As soon as it shows +OK at the end everything went fine. All other errors afterwards are just timeouts because you didn't respond to the open connection.

And thanks for the new debug output. It seems that this cipher type seems to work better/faster with your system so that the pop3 server connection is not dropped while your system is busy initialising the SSL connection. So, this really shows that there is some performance problem somewhere – however, the question remains if we can improve that for that old real 68k hardware.

For your initial problem/request regarding getting your YAM working again, please add/change the DefaultSSLCiphers config item in your YAM:.config configuration file:

DefaultSSLCiphers        = AES256-SHA

This might solve your current problem of not being able to connect to your POP3 server when using AmiSSLv4. But please keep active/listing here because I might come up with a debug version of AmiSSLv4 later on so that you please should test it then so that we can permanently solve/workaround it. And because you are currently the only active one who suffers from this issue we still need your help!

[jens-maus]

@jerseywurzel Now that we seem to have found a workaround/reason for your problem, I want to find out which exact cipher combination might cause the issue. So please try the following openssl commands after another and report which of those show the final +OK DUB005-POP29 POP3 server ready and which not:

1. openssl s_client -cipher "DEFAULT:!ECDH:!DH" -connect pop3.live.com:995
2. openssl s_client -cipher "DEFAULT:!DH" -connect pop3.live.com:995
3. openssl s_client -cipher "DEFAULT:!ECDH:!AES256:!AES128" -connect pop3.live.com:995

Please report for each of those execution if +OK is shown and which Ciphers was chosen for the connection (look for Cipher : XXXXXXXX line).

[Weber-Frank]

Here my speed results: and FW-dnetc_68k.txt

SysInfo show a big difference but the dnetc benchmark difference is not so big.

[Weber-Frank]

@jens-maus I run all 3 commands here and get for all 3 an errormessage. The used OpenSSL version is on top of the output:

13.Ram_Disk:> which openssl
Work:C/OpenSSL
13.Ram_Disk:> version Work:C/OpenSSL
OpenSSL 1.1.0d  26 Jan 2017
13.Ram_Disk:> 
13.Ram_Disk:> openssl s_client -cipher 'DEFAULT:!ECDH:!DH' -connect pop3.live.com:995
Error with command: "-cipher 'DEFAULT:!ECDH:!DH'"
0:error:2506906C:DSO support routines:DSO_pathbyaddr:functionality not supported:../../openssl/crypto/dso/dso_lib.c:315:
0:error:140E6118:SSL routines:ssl_cipher_process_rulestr:invalid command:../../openssl/ssl/ssl_ciph.c:1052:
0:error:140E6118:SSL routines:ssl_cipher_process_rulestr:invalid command:../../openssl/ssl/ssl_ciph.c:1052:
13.Ram_Disk:> 
13.Ram_Disk:> openssl s_client -cipher 'DEFAULT:!DH' -connect pop3.live.com:995
Error with command: "-cipher 'DEFAULT:!DH'"
0:error:2506906C:DSO support routines:DSO_pathbyaddr:functionality not supported:../../openssl/crypto/dso/dso_lib.c:315:
0:error:140E6118:SSL routines:ssl_cipher_process_rulestr:invalid command:../../openssl/ssl/ssl_ciph.c:1052:
0:error:140E6118:SSL routines:ssl_cipher_process_rulestr:invalid command:../../openssl/ssl/ssl_ciph.c:1052:
13.Ram_Disk:> 
13.Ram_Disk:> openssl s_client -cipher 'DEFAULT:!ECDH:!AES256:!AES128' -connect pop3.live.com:995
Error with command: "-cipher 'DEFAULT:!ECDH:!AES256:!AES128'"
0:error:2506906C:DSO support routines:DSO_pathbyaddr:functionality not supported:../../openssl/crypto/dso/dso_lib.c:315:
0:error:140E6118:SSL routines:ssl_cipher_process_rulestr:invalid command:../../openssl/ssl/ssl_ciph.c:1052:
0:error:140E6118:SSL routines:ssl_cipher_process_rulestr:invalid command:../../openssl/ssl/ssl_ciph.c:1052:
13.Ram_Disk:> 

[jens-maus]

@Weber-Frank Then please try to use double quotes " instead of single quotes for the cipher definitions. Obviously the Amiga Shell seem to have a problem with the way the cipher string is quoted.