Kind reminder you soon won't be able to install anything from f-droid anyway, without Google's signature, due to the new restrictions on "side loading".
Only applies to Google certified devices
"Only"? Isn't this most of the Android phones?
F-Droid site certificate expired
101–110 of 115 posts
Re: F-Droid site certificate expired
#102Earlier quoted context omitted.
Would not surprise me. Although it looks like F-Droid is hosted with Hetzner, I have encountered more than one failure to rotate certificates on account of Linode API changes, requiring manual update of the Python Linode API client to resolve.
> API changes This should be an oxymoron. We've forgotten the point of an API as a profession and it's downright shameful when something this important breaks needlessly. Would it have been that hard to just keep supporting whatever API calls were in existence as e.g. "v1" and put their new stuff in "v2"?
Maybe in this context the I in API stands for Implementation detail, so no guarantees are made.
Re: F-Droid site certificate expired
#103Re: F-Droid site certificate expired
#104Re: F-Droid site certificate expired
#105Re: F-Droid site certificate expired
#106Earlier quoted context omitted.
It is, if your objective is to closely centralize the web. If you make https mandatory, via scare tactics, only people with certificates will have websites. If you make ephemeral certificates mandatory by taking advantage of a monopoly, then only big SSL providers who can afford it will survive. Then, when you have only two or three big SSL providers, it's way easier to shut someone off by denying them a certificate,…
There should be an option to go without a recognized CA by publishing your website TLS certificate details via DNSSEC. I don‘t see any disadvantages over automatically issued certificates.
(1) It doesn't work reliably, because middleboxes don't pass DNSSEC/TLSA records reliably, so there has to be a downgrade path, so it's strippable.
(2) It's much slower than the TLS WebPKI.
(3) There's no transparency log and never will be, both because it hasn't been designed and because Google and Mozilla basically had to mug the WebPKI CA's in a dark alley to make CT happen.
(4) It requires you to set up DNSSEC, which is so error prone that some of the largest engineering teams in the world have managed to take their sites (and also countries) offline.
The thing about DNSSEC is that once you turn it on, it's a king-hell pain in the ass to turn it off without incurring an outage. DNS providers know this, and they know ops teams are terrified of DNSSEC, so they push it as a kind of account lock-in tool. There's a reason that the overwhelming majority of large site don't use it.
Re: F-Droid site certificate expired
#107Earlier quoted context omitted.
Again, this is an incredibly naive and uninformed take. Yes. You can spend hundreds of dollars to make one attempt at malicious activity, and yeah, that could also be fixed by tweaking EV requirements. (More than likely by putting a country flag on the EV banner.) One person as an example managing to get a problematic EV cert is not a sign of a broken system, it's a sign of a working system that only a few edge case…
> that could also be fixed by tweaking EV requirements. (More than likely by putting a country flag on the EV banner.) Wrong. Company names are not guaranteed to be unique per-country. The main issue you are missing is that putting undeserved trust in things like DV / EV flags greatly increase the value of such attacks. If users are trained to blindly trust that shiny green bar, the odd attacker will be able to walk…
The extreme majority of criminals aren't doing Ocean's 11-style grand plan attacks here (usually, because... they don't work, the cost is high, and there's too many ways they can fail leaving you out of money with nothing to show for it). Removing the EV bar because you're afraid one attacker might find a way to exploit it becomes an incredible gift to the 99.9999% of attackers who have a much, much easier job to do.
Like, you need to realize most phishing scammers are perfectly happy to make a bankofamericaaa.glitch.me page, because it's free, and without any good indicators for the legitimate bank to use like EV, really doesn't look that much different to the nontechnical customer than bankofamerica.com.
Re: F-Droid site certificate expired
#108Earlier quoted context omitted.
Would not surprise me. Although it looks like F-Droid is hosted with Hetzner, I have encountered more than one failure to rotate certificates on account of Linode API changes, requiring manual update of the Python Linode API client to resolve.
> API changes This should be an oxymoron. We've forgotten the point of an API as a profession and it's downright shameful when something this important breaks needlessly. Would it have been that hard to just keep supporting whatever API calls were in existence as e.g. "v1" and put their new stuff in "v2"?
In Python land API stands for Another Pointless Incompatibility
Re: F-Droid site certificate expired
#109Earlier quoted context omitted.
And all of the ones that work with banks and other apps people absolutely need to have, in order to function in society. It's bad.
There are bank apps that work on non-certified devices
Thats great but I need my bank app to work not some random one
Re: F-Droid site certificate expired
#110Earlier quoted context omitted.
No, it doesn't. It makes the registrar the CA. Which makes sense, they already authorize who owns which domain. They should absolutely do so cryptographically in some fashion. What's weird is that the major registrars never even tried to enter the PKI business. It would have made sense. It would even have hastened the adoption of much needed TLS extensions.
The registrar is not equivalent to a CA in DANE. - A CA validates requests, signs CSRs, publishes cert revocation, issues certificates and trust anchors. - A registrar in DANE merely passes a DS record you created to the TLD, along with the promise that this record was created by the domain zone owner. It's basically the validation step. Nothing to do with establishing or securing data, key/record management, etc; th…
The registry, not the registrar (sorry, I managed to mistype above, despite trying to be careful about these terms). The comparison with the CA is apt. The registry signs the DS record.
The model you suggest is a variant of what I allude to in my second paragraph above. That is indeed both an obvious, simple, and much more secure model than the web PKI we use today. I tried to push for similar ideas several years before things like DANE but no one seems interested enough. I have no idea why this is, as the model is both trivial and obvious.