By introducing a session variable we can avoid now that the client needs to expose the certificate twice in the 2nd authentication step (after re-negotiation).

Thanks for your feedback. What did the change involve?

After further debugging on our side we found a way to improve the 2-step authentication process (particularly the handling of the re-negotiation requests).

With this new authentication method WinSCP does not fail anymore and does not shown the SSL handshake failures anymore.

So it looks as this issue is a non-issue for the time being. ;-)

Thanks for your answers and support!

Thanks for your report.
I have sent you an email with a debug version of WinSCP to the address you have used to register on this forum.

You mentioned the session timeout in your initial post and there was my answer. ;-)

https://winscp.net/forum/viewtopic.php?t=30425#104257

As requested I added a log file from CarotDAV after transferring the same file to the server. For me it looks as for each new connection the 2-step authentication is performed as well (as expected) but the transfer isn't re-started but finished and the file appears successfully.

I guess that the 2-step authentication (server asks client for re-negotiation with certificate during connection establishing) seems to irritate the WinSCP transfer connection in any way after some timeout.

Would a verbose level 2 logfile of WinSCP bring further help?

I do not know. Can you try setting a longer session timeout in WinSCP? Can you post a verbose log files from other WebDAV client that can upload the file?

My hope was that you can help here. :-)

Can you see in the logfiles the reason, why WinSCP looses the connection and starts a re-transfer? Even if the re-transfer completes (up to 100%) the error message is shown and the file disappears.

Are there further hints in the logfiles?

Mythos wrote:

2) Then a new connection is automatically initiated which finally fails with the handshake failure. This effect is even visible in the UI on the progress bar (see the attached video clip).

Thanks for all the details. And do you know why does the reconnect handshake fail?

After checking the server logs the login process seems to bring WinSCP into trouble.

The login process is based on the following 3 steps:

1) The server ignores the client certificate in the first step (since there are different sites with and without certificate hosted on the same machine).
2) After evaluating the requested path the server decides whether a client certificate is needed or not and requests the client to re-negotitate with client certificate (in our case).
3) The client re-negotiates the connection as requested and the server evaluates the certificate and the session starts.

I simplified the transfer a little to use a single connection and the effect is as follows:

1) The client initiates a new connection for the transfer, supplying the client certificate and starts the transfer but the persistent connection is timed out (see the attached log-file in line 109).
2) Then a new connection is automatically initiated which finally fails with the handshake failure. This effect is even visible in the UI on the progress bar (see the attached video clip).

Thanks in advance for your support.

Thanks for the details. Do server-side logs give any useful information?

Just another irregularity I noticed during testing:

On the initial login WinSCP asks three times (!) for a password. First for the (1) certificate password then for the (2) user password and finally again (3) for the certificate password. This issue seems to be related to the 2-step authentication method of the server and may help on analyzing.

Just for your interest, other WebDAV clients (like CarotDAV) does work very well with our servers. There have been no issues so far.

Just WinSCP is failing with larger file transfers.

But since WinSCP has the best user interface it would be great to have this issues fixed.

I made another test run with multiple transfers in parallel. If you click retry the transfer did well from 0-100% but at the end the SSL handshake failure is shown anyway.

Please check the attached video and log files...

Thanks for your answer!

I tested two different timeouts: 15s and 60s, in both cases the transfer fails and it (visually) resets (starts again at 0%) approx. 15-20s after the transfer was initiated. It looks identical to the screencast video-clip I submitted in my first posting.

Two things are visually noticable on the user interface:

1. The transfer restarts after about 20s (the progress starts again at 0%).
2. At the end of the (2nd :-) transfer (when reaching 100%) the error message appears (see above).

So did you try setting a long session timeout?
https://winscp.net/eng/docs/ui_login_connection

For me it looks a little bit as a 2nd connection (in the background) runs into a timeout and also terminates the running transfer-task in the foreground (leading to a "restart" with an undefined context). That may explain why short transfers are fine and only time consuming tasks fail constantly ...

Hello,

we have a strange effect with an external WebDAV server. The authentication is two-step (server asks for re-connect incl. certificate) and the transfer of small files works without problems. For large files the transfer is reset (just before the end) and starts again. Then at 100% the transfer ends with an SSL error and the file disappear.

It seems that not the size of the transfer is crucial but the actual time. If we throttle the small file (so that the transfer takes longer) then the small file also fails with the same error message.

The logfile is attached!
Error is shown in line 1413 @ 2021-01-19 14:55:46.718

I also added a screen capture (mp4) of the transfer. You can see that the whole transfer resets at ~80% and starts again before the final error message is shown. The video only shows the transfer of the 2nd (large) file, the logfile includes the whole session (login with small and large file transfer).

Thanks for any help!