Tiny Tiny RSS: Community

Android: RIP self-signed certificates

i want to replace HttpUrlConnection in android app with okhttp3, because it makes for much cleaner code, doesn’t depend on platform implementation that much, and I already use it anyway so having two http client libraries annoys me.

this brings me to self signed certificates, i.e. allowing to trust any certificate. this was implemented long before letsencrypt became a thing and we were generally all MITMed less. nowadays i think having this option is harmful because it provides an illusion of security to people who don’t know better, and in my experience, people generally don’t know better.

it’s been a while since i tried, but i think installing your own CA certificates is still a thing on android, if you don’t want to use letsencrypt or other platform-trusted SSL certificate vendor.

therefore, i want to remove this whole trusting anything thing for the okhttp rewrite. comments?

oh and before anyone asks, i think installing your own certificates in the app is redundant and it’s not going to happen.

Will that in any way effect connecting to a hidden/onion-site?

Any chance of getting a proxy configuration settings with the rewrite?

this strikes me as redundant too tbh.

e: app-specific proxy settings that is

that depends on whether your site has a self-signed certificate, i guess

I think leaving support for self signed is OK, if you did it differently, like firefox does. no check box in settings but on first access warn the user about possible security issue and if they accept, allow the site.

I don’t use a standard port and also have all access protected via basic auth. At one point lets encrypt only supported 80/443 as ports. also they didn’t work with my dynamic dns provider.

i want to remove bloat, not add to it. i wouldn’t even merge a PR for this.

this, and other similar issues, should be solved by having a custom CA, with certificate installed in the phone.

unless, of course, google managed to remove this already for our collective “safety” or w/e.

That is only needed for the challenge process, and there are other ways to answer the challenge. Once you have the certificate you can use it just like any certificate.

good point, there’s dns challenge now that you must use anyway instead of http for wildcard certificates

fox: that is what I will do. the capability appears to still be there.

randompherret: I did know that, but thanks for the assist.

I’ve switched to certbot rfc 2136 long ago

So just out of curiosity: how would the setup look like, if I just wanted to set up in my own lan environment, no access from outside.

Is there even any other way than using a self signed certificate?
Also, any “normal” certificate would not work anyway (I assume) since Android cant resolve .local addresses due to mDNS.
So I have to use the IP to connect to my tt-rss instance and I wont be able to get a cert on an IP.

So if the Android app cant connect to tt-rss via IP, then I would not be able to use it.

You use something like https://github.com/OpenVPN/easy-rsa and import the ca cert into Android. Settings->security->encryption & credentials-> install from storage.

You can use self signed certs, you just have to tell Android to trust them.

I use a LetsEncrypt cert for locally hosted services by keeping a domain that doesn’t point anywhere, obtaining the cert using DNS challenges, and using a rewrite rule in my local DNS server to point that domain to the local server (I use Adguard for this, but pi-hole or any other will work, too). That gives me a cert that Android trusts, without having to import anything or expose anything to the big bad internet.

This is what I do and it works fine. I’m using iOS versus Android but after installing the root CA everything just works for all my self-hosted domains (both local and remote).

The .local thing sort of depends on your network; I don’t really bother with it myself and just use IPs. If you’re using a certificate signed by your own CA you can use an IP address, you just have to specify it in the SAN (subject alt. name) as IP:192.168.0.101 when you’re creating the certificate. If you’re using the EasyRSA scripts it can handle all that for you via command line options.