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

No HTTPS SNI support due to upstream #23

Closed
zealot128 opened this issue May 8, 2016 · 7 comments
Closed

No HTTPS SNI support due to upstream #23

zealot128 opened this issue May 8, 2016 · 7 comments
Assignees
Labels

Comments

@zealot128
Copy link
Contributor

First, thanks for the (OpenSource) work so far on that app!

I tried using the https version of my server (I times of Letsencrypt also a common thing, IMO), but that fails. Seems to be a issue of android-async-http.

android-async-http/android-async-http#224

For what it's worth, some people in the issue recommend another library, okhttp.

@stephanepechard
Copy link
Member

Hi,
I know android-async-http is not perfect, but it does not seem to me it is the root of your problem. In fact, I successfully use Let's Encrypt HTTPS certs on my server with PB.

Do you have more information about your problem? What does the app says? What does the server says? What's your config? etc.

Thanks for using PB (or trying at least...)

@stephanepechard stephanepechard self-assigned this May 8, 2016
@zealot128
Copy link
Contributor Author

zealot128 commented May 8, 2016

Do you have only one SSL certificate on that server?
As far as I know, that problem only occurs if your server provides multiple certificates for different domains (SNI), in that case, the app, if it doesn't support SNI, will just use a "random" certificate (maybe first or last of the server config I guess, depends on the server).

When using ssl i can't activate the service; "test" will fail with a generic error as far as I remember. I am not in possession of the phone right now :) I will report back if I have any more information.

Here my concrete example:

$ openssl s_client -connect pics.stefanwienert.de:443
[...snip...]
---
Certificate chain
 0 s:/CN=fahrrad-filter.de
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---

I just receive any certificate (for another of my domains fahrrad-filter.de).

@stephanepechard
Copy link
Member

No, I have at least 10 SSL certificates on this server. I'm far of an expert in SSL-related matter, but I made it work quite easily iirc. What server do you use to redirect to PB? I use Nginx as a proxy with the following conf. I even make it work with Basic Auth (not used here).

server {
    listen                      80;
    server_name                 pb.s13d.fr;
    return                      301 https://$server_name$request_uri; # redirection 
}

server {
    listen                      443 ssl;
    listen                      [::]:443 ssl;
    server_name                 pb.s13d.fr;

    keepalive_timeout           5;

    client_max_body_size        25M;

    location / {
        proxy_pass              http://127.0.0.1:8420;
        proxy_redirect          default;
        proxy_set_header        X-Real-IP $remote_addr;
        proxy_set_header        Host $http_host;
    }
}

@zealot128
Copy link
Contributor Author

I've checked the error; it's just the generic Toast with "check you server configuration".

Regarding your domains: that works, because you have only one SSL certificate for all your domains:

Common names    s13d.fr
Alternative names   cozy.s13d.fr cp.s13d.fr gogs.s13d.fr ha.s13d.fr hia.s13d.fr munin.s13d.fr pb.s13d.fr s13d.fr w.s13d.fr www.s13d.fr yt.s13d.fr

So, if http clients without SNI contact that server, they always will receive the right certificate.

This doesn't work, if your server has more than one SSL certificate (e.g., you share the server with other people, like in my case, or you are using different certificate authorities, or you hit the rate limit of Letsencrypt, or ...).
SNI is an RFC that is widely implemented; only on Java 1.6, IE on WinXP, and Android 2.3 browser, it doesn't work. It works in Chrome and in Firefox since 6+ years. So it is an ancient standard.

https://en.wikipedia.org/wiki/Server_Name_Indication#Support

(I have the same problem with other Android software, like a feed-reader (ttrss) and the app I used before PhotoBackup -> AutoShare, all of those have the same problem and can't support SNI 😞 )

I think there is not much we can do here (besides waiting for upstream fix or ripping out android-async, which is probably not reasonable).

@stephanepechard
Copy link
Member

Can you try the last commit to tell me if this is fixed?
I didn't make an APK, do you need one?
Thanks

@zealot128
Copy link
Contributor Author

Sounds great!

I just tried it, works now with my SSL config! :D

Also saw the User Agent: PhotoBackup Android Client v0.8.1-dev

So I guess, the SNI issue is fixed. Thank you!

@stephanepechard
Copy link
Member

whoah, it's the first time I close two issues in one lunch :-)
I'll publish a proper APK to Google Play after more testing (especially Basic Auth that I couldn't test)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants