search

nextcloud / passman-android

:key: Android app for Passman.
https://passman.cc
GNU General Public License v3.0
93 stars 30 forks source link

Https with self signed certificates #25

Closed Sulumar closed 3 years ago

Sulumar commented 7 years ago

Hey,

I am hosting my nextcloud server on my home network using a https connectyion with a self signed certificate. The thing is designed to be a hub for houshold members while being at Home only So no making it accessible from the internet exept through a vpn for me, while im away.

now i installed a self signed certificate to use a https connection. Since that moment the Passmann amdroid app refuses to connect to the server claiming SSL Handshake failed

Main nextcloud app works fine Importing the ssl certificate into my phone, Androis 7.1, didnt help The app works if i disable https on the server. Is there a way to make it understand a self signed cert ?

animalillo commented 7 years ago

You could import the certificate into android, i might check in the future about self signed certs, but i would advise against using self signed certs, specially having tools like lets encrypt.

As of now, i don't think we support self signed certs on the app.

Sulumar commented 7 years ago

problem is that with letsencrypt ill have to make everything accessible from the internet, wich is what i am trying to prevent

animalillo commented 7 years ago

Just for the certificate generation, then you can choose it again

Sulumar commented 7 years ago

Tried that, now my webserver isnt starting up anymore and i have no clue how letsencrypt messed with the config. Great. Everything was working fine except for the passman app. Guess ill try fixing it tomorrow

brantje commented 7 years ago

Hi @Sulumar, I'm sorry to see you're having this much trouble. Can you post the following things:

Don't post the logs direct here, but use something like pastebin.

Sulumar commented 7 years ago

Ok, so i rebuild the whole thing. For as long as i route the nextcloud instance to the exterior and grab it via its dyndns name everythig works. If i stop routing it and try to grab it on the internal network via its ip, passman app and notes app stop working the certificate for the https connection is a Letsencrypt Cert so im basically exactly where i started.

also its running on a Lighttpd

animalillo commented 7 years ago

Hmm https is domain based, so you need a domain name, you could set up a simple dns resolver on your net.

Otherwise the ssl handshake check is probably going to fail, as with the self signed cert.

I might check this out tomorrow if i have some time, depending on how hard it is to detect and add an alert and save the ferry as an exception and that stuff.

lwinch2006 commented 7 years ago

@animalillo I will mention that I have the same issue. Passman for android shows "Network error: Handshake failed".

I'm using also self signed certificate issued by my own CA. All nextcloud infrastucture meant to be run at home on local network without need to connect to Internet. Devices are synchronized when I'm at home and they connected to home WiFi. To connect to server I'm pointing to IP address of the server, not a domain name, like https://x.x.x.x:port/nextcloud/

Also can say that other Nextcloud related apps like "Nextcloud Dev", "Nextcloud SMS", "Davdroid" working fine on such setup. So I hope that it will be also possible to use Passman for Android in such conditions in the end :-)

axs77 commented 7 years ago

Same here with the self signed cert. It would be nice if it can be implemented in the coming up versions.

Edit: It works. Own cert installed on my Android device. Nice.

lwinch2006 commented 7 years ago

@axs77: Can you explain in more detail what you did to make it work. Have you installed your root CA certificate on Android?

lwinch2006 commented 7 years ago

Update: for me it also worked. I needed to:

LouisOuellet commented 6 years ago

I think, in all cases, the best solution would be to setup a local dns server on your local network. Although yes nexcloud/owncloud supports the use of a direct IP they also recommend you have a DNS record that points to your server. There is a few reasons to this, one self figned certificates are defenetly not the easiest to implement in any network as they create more problems then they solve, second it is much easier for everyone to remember a url compared to an IP.

as far as home setups, I recommend you have a look at your router configurations as most support a local dns database. Thus it can act as your local DNS server. I still strongly recommend you temporarely add a forwarding rule to setup letencrypts. once the certificate is generated, simply disabled the rule. also make sure to create a dns record that matches your dydns record or any other dynamic dns service such as noip.

brantje commented 6 years ago

For home setups i suggest pihole. You will also get DNS based ad blocking.

IBBoard commented 5 years ago

I've just started getting this problem. Passman on Android used to work fine using a custom CA (which is installed on my phone). Now, I get "Network error: java.security.cert.CertPathValidatorException: Trust anchor for certification path no found."

I did generate and install new certs the other day, but Firefox on the desktop is showing the same CA fingerprints as the one in my trust store and the new certs should be more compatible (because I include the DNS name, which Chrome has started requiring)!

LouisOuellet commented 5 years ago

I've just started getting this problem. Passman on Android used to work fine using a custom CA (which is installed on my phone). Now, I get "Network error: java.security.cert.CertPathValidatorException: Trust anchor for certification path no found."

I did generate and install new certs the other day, but Firefox on the desktop is showing the same CA fingerprints as the one in my trust store and the new certs should be more compatible (because I include the DNS name, which Chrome has started requiring)!

Sounds like you still have the older certificat in your cache. Have you tried to reboot your phone/computer ? Or clear your browser cache. There is a lot of tutorial online to do so.

LouisOuellet commented 5 years ago

I'd like to add that Let's Encrypt would allow you to validate a certificate for free. I suggest you have a look at it. https://letsencrypt.org/

IBBoard commented 5 years ago

I've force-quit Passman for Android and cleared its cache and data several times. Not tried a reboot yet.

Firefox and Chrome on my phone are okay with the cert, though.

LouisOuellet commented 5 years ago

I've force-quit Passman for Android and cleared its cache and data several times. Not tried a reboot yet.

Firefox and Chrome on my phone are okay with the cert, though.

Is your certificate self signed or are you using a validator such as let's encrypt ?

IBBoard commented 5 years ago

Neither (technically). It's self-signed CA that signs the cert. That CA is in my Android trust store (and Firefox, because I think it has its own store) and has been there for a few years. Passman has been working for months, until just recently. The CA didn't change, but the cert did.

As for LE - I use that for my public domains, but all of my "admin" stuff is still on self-signed (partly for historic reasons, because I was SSLing things WAY before Let's Encrypt, and partly because I've got Apache config on some of the admin sites that may not play nicely with their normal confirmation method).

[Edit] Sorry - I just checked the SSL Server Test (https://www.ssllabs.com/ssltest/analyze.html?d=pim.ibboard.co.uk) and noticed that it's being served TWO certificates for some reason (one of which is for a different domain that I run)! I'll look in to that and see whether it fixes it. Not sure why that would have changed, though.

LouisOuellet commented 5 years ago

I would suggest you regenerate a new certificate for it. I would recommend you use something like Certbot (https://certbot.eff.org/) with Let's Encrypt to automate the regeneration of your SSL certificate for your Nextcloud Server. Instead of using a self-signed CA. As this may cause even more problems in the futures. Plus LE & Certbot are free and open source and saves you tons of work in trying to automate the generation of your SSL certificates.

I've been using this solution for a few years now. And so far haven't encounter any problems. Also Let's Encrypt is a well known CA. Thus trust comes easy with browsers and OSes.

Right now your certificate doesn't look trusty due to the fact that your CA has the CN and O with the same name as your domain name. This causes trusts issues for obvious reasons. Lastly as far as the second certificate, I do not see any issues with it. It simply means that bot domains are most likely directed on the same webserver. Apache2 will provide the app and browser the certificate related to the domain name used AKA ServerName. Thus multiple certificate can be used on the same Web Server.

IBBoard commented 5 years ago

As I said, I'm already using Let's Encrypt for my main domains. I've been using it for about two years now. The automating part isn't a concern for my few private domains (I've got a script to generate it), "trustworthiness" isn't important as I'm the only one using them, and it's not a big issue if I forget and they expire because only I use it. Even if I switched these certificates to LE then I'd still be generated SMTP and IMAP certs under my CA, so it's not a big problem for me.

My understanding is that a self-signed CA shouldn't cause any problems once the CA is installed. At that point then it's effectively indistinguishable from a system CA. That's how it has behaved for me for the last five and a bit years that I've used a self-signed CA, and more importantly it's how Passman was behaving until a few days ago!

Is there a way to get debug logging out of Passman on Android? As it's an SSL failure then I'm not seeing any connections in the server logs.

I've checked the SSL Labs test and I think that was a red herring - the second cert chain for the wrong domain was the "non-SNI" version (which is expected).

IBBoard commented 5 years ago

I've tried a few bits of research and checking config but can't find anything obvious yet.

Could it be that I've got a 4096 byte SHA256 certificate?

SSL Labs thinks it should be supported by Android (I'm on 8.1.0 on a OnePlus 5) but the only changes between the commands that made my old and new certs are that I include the "DNS" entry (which Chrome requires) and I now explicitly generate SHA256. I think 4096 byte must be coming from a default somewhere.

LouisOuellet commented 5 years ago

I've tried a few bits of research and checking config but can't find anything obvious yet.

Could it be that I've got a 4096 byte SHA256 certificate?

SSL Labs thinks it should be supported by Android (I'm on 8.1.0 on a OnePlus 5) but the only changes between the commands that made my old and new certs are that I include the "DNS" entry (which Chrome requires) and I now explicitly generate SHA256. I think 4096 byte must be coming from a default somewhere.

From my external perspective, when I try to get your certificate, I get ET::ERR_CERT_AUTHORITY_INVALID Which points to an issue with your CA. As far as the 4096 byte SHA256 encryption, those are usually the default encryption settings for SSL. Thus I doubt the issue is coming from there. Unfortunately, my experience with SSL Certificates ends at LE & Self Signed Certificate. The only CAs I've been using were Windows ADDC. As far as Passman, I had fixed this issue simply by using a LE Certificate for my subdomain (https://cloud.laswitchtech.com) which works great for me. I prevents me from going into the trouble of setting up a CA. Sorry if I couldn't be more helpful and wish you good luck. I will continue to follow this thread as I am curious about how you will manage to solve the issue.

IBBoard commented 5 years ago

You'll get ERR_CERT_AUTHORITY_INVALID because you don't have my CA installed/trusted. Download it from https://ibboard.co.uk/ibboard_ca.crt and install it and you should then have a trust root for the certificate.

[Edit] Trying to get my understanding of the 4096 bit (not byte - my mistake) thing right.

4096 bit isn't common yet because it's too strong and won't work on some systems BUT my existing key is only 2048 bit, so I'm still poking bits to understand it. Maybe I mis-read and that was the signatures size rather than the key size.

animalillo commented 5 years ago

Could you please share your android version, app version, server flavour (nginx, apache, ...), and ssl cypher suites selected on said server along with the nc version + passman version server side so we can properly diagnose the issue?

IBBoard commented 5 years ago

I've tried swapping to certs that use my older way of generating them, but that hasn't made a difference, so it doesn't appear to be a problem with broken certs or changes in adding the v3 extensions. The certificates work fine in Chrome and Firefox (desktop and mobile).

animalillo commented 5 years ago

If i have time this afternoon i will take a look. Being it a 4096 bits key shouldn't affect at all, I use this key size on all my tests and it work nicely, i will try with your selected cypher suit and will try to set up an vm with that version of android.

It could be an issue with the library we use to handle http api calls, idk, it happened in the past that just publishing an update with a new version fixed the issue, this is annoying tbh.

IBBoard commented 5 years ago

Are there any old builds of the app available so that I could test to see whether it's a version related thing?

I've definitely had it working before, and I've tried to rule out the recent certificate updates that I made (which use the same CA) but the only tests I can think of now are old app tests or more complete debugging information (like a stack trace, or a list of the CAs that the app trusts)

animalillo commented 5 years ago

I'm sorry, but i didn't have time to take a look into it, and i won't be nearby my computer until 2019 will try to test it then. As for old passman versions i can get you version 0.13 from the app store history.

passman0.13-nightly.apk.zip

I've attached it .zip as it is the only way github would let me upload it seems.

IBBoard commented 5 years ago

That seems to work enough to log in and list my vaults (and it shows today as the latest access) but then I get "network error" when trying to open the vault.

developerfromjokela commented 5 years ago

Developer should implement AlertDialog to skip SSL check and it will run again login request. It is possible to skip it on httpURLConnection. I am using this method in my apps and is working very well. If I can contribute to this app, I will add it.

developerfromjokela commented 5 years ago

Any server side changes will not be necessary. Only app needs some tweaks.

IBBoard commented 5 years ago

But that misses the underlying problem here: The custom CA should be trusted. It's in the phone's trust root and works everywhere else (Chrome, Firefox, older versions of the app). Just not in Passman.

Skipping SSL checks should be an absolute last resort!

animalillo commented 5 years ago

@developerfromjokela if you are willing to create such a merge request I'll be more than happy to review and merge it!

animalillo commented 5 years ago

@IBBoard you are right about that too, but having that feature as a fall back is also nice i think, though, SSL handshake error would happen being trusted or untrusted cert, it looks like an error in one of the libraries in use on the network layer. Will check your issue when I get some time.

IBBoard commented 5 years ago

If there is going to be a "ignore failed certificates" option then I'd strongly recommend that you ignore a single fingerprint and don't make it an "ignore ALL failed certificates without any further warnings" option.

Ignoring all errors leaves a gaping hole for someone to "Man in the Middle" the connection without being noticed. Even doing it for a single fingerprint opens a small hole (someone could make a targeted cert that collides with your self-signed-without-a-CA cert), but that's a somewhat smaller risk.

developerfromjokela commented 5 years ago

@IBBoard Yes, that is good. If we implement that we can skip single SSL signature but not all of them.

IBBoard commented 5 years ago

I'd still rather have a fix that trusts the trust roots that my phone has set up (as other apps seem to do)!

IBBoard commented 5 years ago

Has anyone been able to investigate this, recreate it themselves, or find a fix? I'm currently having to log in to the web app from my phone, which isn't the greatest interface for mobile!

pasdVn commented 5 years ago

I am also using a self signed certificate and imported my CA certificate into android. Although some users reported it to work, for me it does not :-(. I get the following exception with logcat:


9041 14235 W System.err: javax.net.ssl.SSLHandshakeException: Handshake failed
9041 14235 W System.err:    at com.android.org.conscrypt.OpenSSLEngineImpl.unwrap(OpenSSLEngineImpl.java:441)
9041 14235 W System.err:    at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:1270)
9041 14235 W System.err:    at com.koushikdutta.async.AsyncSSLSocketWrapper$5.onDataAvailable(AsyncSSLSocketWrapper.java:194)
9041 14235 W System.err:    at com.koushikdutta.async.Util.emitAllData(Util.java:23)
9041 14235 W System.err:    at com.koushikdutta.async.AsyncNetworkSocket.onReadable(AsyncNetworkSocket.java:152)
9041 14235 W System.err:    at com.koushikdutta.async.AsyncServer.runLoop(AsyncServer.java:821)
9041 14235 W System.err:    at com.koushikdutta.async.AsyncServer.run(AsyncServer.java:658)
9041 14235 W System.err:    at com.koushikdutta.async.AsyncServer.access$800(AsyncServer.java:44)
9041 14235 W System.err:    at com.koushikdutta.async.AsyncServer$14.run(AsyncServer.java:600)
9041 14235 W System.err: Caused by: java.security.cert.CertificateException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.
9041 14235 W System.err:    at com.android.org.conscrypt.TrustManagerImpl.checkTrustedRecursive(TrustManagerImpl.java:549)
9041 14235 W System.err:    at com.android.org.conscrypt.TrustManagerImpl.checkTrusted(TrustManagerImpl.java:401)
9041 14235 W System.err:    at com.android.org.conscrypt.TrustManagerImpl.checkTrusted(TrustManagerImpl.java:375)
9041 14235 W System.err:    at com.android.org.conscrypt.TrustManagerImpl.getTrustedChainForServer(TrustManagerImpl.java:318)
9041 14235 W System.err:    at android.security.net.config.NetworkSecurityTrustManager.checkServerTrusted(NetworkSecurityTrustManager.java:102)
9041 14235 W System.err:    at android.security.net.config.RootTrustManager.checkServerTrusted(RootTrustManager.java:104)
9041 14235 W System.err:    at com.android.org.conscrypt.Platform.checkServerTrusted(Platform.java:202)
9041 14235 W System.err:    at com.android.org.conscrypt.OpenSSLEngineImpl.verifyCertificateChain(OpenSSLEngineImpl.java:666)
9041 14235 W System.err:    at com.android.org.conscrypt.NativeCrypto.SSL_do_handshake_bio(Native Method)
9041 14235 W System.err:    at com.android.org.conscrypt.OpenSSLEngineImpl.unwrap(OpenSSLEngineImpl.java:426)
9041 14235 W System.err:    ... 8 more
9041 14235 W System.err: Caused by: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.
9041 14235 W System.err:    ... 18 more```

Other Apps like davdroid or the nextcloud app are working, so there is definitely no problem with my certificate and/or CA.
Lets Encrypt is no general solution for self-hosted, private clouds, because many users (like me) use a dynamic DNS (I think this is not supported by Lets encrypt and generally would be not secure imo).
tom-ch1 commented 4 years ago

@animalillo : Any chance to integrate this fix anytime soon? @pasdVn : in the meantime, I'd like to test it, how can I do that? How can I build this app into an apk?