Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OS X Client 4.2.7/4.2.8 HTTP sync doesn't work with TLS 1.2, only with insecure TLS 1.0 #676

Closed
MacLemon opened this issue Jul 21, 2015 · 4 comments

Comments

@MacLemon
Copy link

Summary:

When using HTTP sync with HTTPS and TLS 1.2 only OS X Client fails to sync due to a problem with libcurl.

Steps to Reproduce:

Configure Seafile Server 4.2.3 on Debian 7 with HTTPS behind nginx 1.9.2 with HTTPS and a valid certificate. Seafile Client 4.2.7/4.2.8 can't sync anymore where 4.1.6 would fall back to the old synching protocol but already had the same bug.

Expected Results:

Client 4.2.8 should use HTTP synching with seafile server configured to only use TLS 1.2.

Actual Results:

Client 4.2.8 should use HTTP synching but fails at fetching the version number:
[07/21/15 19:06:01] http-tx-mgr.c(641): libcurl failed to GET https://seafile.example.com/seafhttp/protocol-version: SSL connect error.
This is due to the fact that libcurl only supports the deprecated TLS 1.0 and not the current TLS 1.2. This may be related to libcurl being linked to a very old libcrypto/libssl. Like from OpenSSL 0.9.8 instead of OpenSSL 1.0.2.

Regression:

When temporarily configuring the server to also support insecure TLS 1.0 the client is able to connect. Using HTTPS with TLS below 1.2 is not secure and thus not acceptable to use. This was not caught earlier by me due to the fallback to the old proprietary synching protocol in older Clients like 4.1.6.
The problem that HTTPS sync only works up to TLS 1.0 is likely present in all OS X Clients 4.0 and up. I haven't checked any other platforms' clients.

Notes:

The server is correctly configured to use HTTPS synching and verified. Manually probing
https://seafile.example.com/seafhttp/protocol-version results in a {"version": 1}response.

Detailed Version Info:

Server: 4.3.2
OS: Debian Wheezy 3.14-1-amd64 #1 SMP Debian 3.14.7-1 (2014-06-16) x86_64 GNU/Linux
nginx 1.9.2 built with OpenSSL 1.0.2c 12 Jun 2015, TLS SNI support enabled
Server config uses TLS 1.2 only
Certificate: Issued by StartSSL, deployed with full chain and valid according to OS X.

@HDC67
Copy link

HDC67 commented Jul 22, 2015

I can confirm seeing this issue too. Works if I allow TLS v1 but not if TLS v1.2 only.

TLS v1.2 only works fine on a Windows client and Android too.

@lins05
Copy link
Contributor

lins05 commented Aug 10, 2015

Thanks for reporting this! We'll fix this soon.

@yason
Copy link

yason commented Sep 17, 2015

Hi!.
I' have similar report about owncloud-client. My research shows that Qt4 lacks support of TLS>v1.0. This was solved upstream for Qt5. They decided that Qt4 is almost dead and doesn't need such tweaks. I cant send you a proof in Qt developement archives for that, sorry. Not now at least.
There was a patch somewhere which adds support for TLSv1.1 and 1.2, not sure this will help and not sure this will be accepted by packagers of major Linux/BSD didtriburions.

@lins05
Copy link
Contributor

lins05 commented Sep 18, 2015

Seafile client 4.4.0 would be released soon and would fix this problem.

@killing killing closed this as completed Feb 28, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants