Hacker News Reader

Comment by deftnerd | Hacker News Reader

I would rather see the OS let people load the cert but then require the user enter their PIN, password, or unlock drawing. Then the cert can be signed by the PIN/etc and trusted.

This would allow certs to be added, but prevent them from being silently side-loaded by an admin or malware. Changing your PIN would invalidate the cert but you could just be prompted to resign them.

View on HN

This is a bit confusing to me: "apps that target API level 24 will—by design—not honor such CAs unless the app explicitly opts in."

So the app opts in?

Seems strange to me. What you're suggesting makes a lot more sense.

After reading the article, I think what you describe can easily be implemented -- at the _app_ level.

The big change is that Android no longer provides an ability to add a CA for all apps on the device ("device global CA"). There is only one "global CA store" now, the one shipped with Android.

Device updates can update the CA store, and the article talks about how to get your CA included.

And how can I add the CA of my university, for example, which is required for some university networks?

Especially because it has to be in the global store?

Or how am I supposed to use my legal right to reverse and understand the functionality and APIs of software I have installed?

EDIT (as I can’t create new comments for the next hour): The certificate is not used for HTTPS – but for TLS for IMAP, for example, and for some internal services, eduroam, etc. Obviously, that means that the Email-App needs to use the cert, too, in addition to the Android system, and a bunch of other apps.

Accepting a university cert seems like a terrible idea. I would look into a mobile hotspot or, even better, transferring to a different university.

https://security.stackexchange.com/questions/104576/my-colle...

MIT has its own CA 0_o

ca.mit.edu

Do you trust your university more, or "TÜRKTRUST Elektronik Sertifika"?

Who is that, you ask? That is precisely my point. I have no idea, none at all. I do happen to know what my university was (and why it was running its own CA). Yet, this one is doubleplusgood for me. Trust Google, it knows best.

(I went to my Android's builtin trusted CA list, this was the very first one - out of a list of about 100, or maybe 200)

I don't particularly trust either, but:

1. The university is explicitly asking to MITM your traffic, so that's an automatic no-go on any of my devices for me. At least other CAs will be punished if caught.

2. I'm fairly certain these university certs are not subject to certificate transparency, and even if they were, since they are explicitly designed to MITM traffic, I'm not sure that it would raise any red flags if someone other than the university was issuing these certs for inappropriate domains. At least TÜRKTRUST Elektronik Sertifika issuing inappropriate certificates are much more likely to get caught doing anything fishy (with high profile sites, anyway).

3. What you're really trusting is the vendor of whatever security gateway, not the university itself. If you look at the Security.SE thread I linked, there was an actual issue with at least one of the black box vendors. I don't think the other vendors are considerably better.

So, all-in-all, I would not accept an MITM certificate on any device that I used for anything personal, full stop.

You do realize a CA can be limited to be trusted only for some things, yet not for others?

For example, many such university certificates are not trusted as CAs for HTTPS?

I was talking about MITM certificates. I don't really understand why a university is not just getting a certificate from a CA in the trusted store, but I would have many fewer qualms about something that is not a general MITM certificate. That said, my experience is that generally applications that have a legitimate reason for a limited-use self-signed certificate don't need to be in the general store. For example, it's common to set up OpenVPN with a self-signed certificate, but I've never had to add a certificate to the general store for that - it's always app-specific.

It seems likely the email app would opt in to user certificates.

Once the university (and their providers) have modified their apps to opt in, the user sees a net benefit. I guess it might be hilariously optimistic to expect the university and all of their providers to actually fix their software, but that's the other way of looking at that specific problem.

It’s not a university email app. I’m using K9 with that.

Others are using GMail, or AOSP mail, etc.

You can’t seriously expect every single Android app to add the feature back, do you?

And even then, I still get no benefit – I have to update my own fork of AOSP mail, too, I have to update a bunch of system apps, I can’t use eduroam properly anymore, and I can’t MitM the traffic of my own device anymore. The only thing this does is my life worse.

Every single Android update since KitKat has done that. Made my life worse. Removed features, killed AOSP stuff, moved code into proprietary apps, and prevent people from modifying their own device.

I only expect the apps where a user certificate is useful for normal operation to add the feature back. Other apps get better security by not enabling user certificates.

Use Xposed as root, inject the settings to trust your own CA

That is already the requirement if you have a lock set up for your device, except for the last part about changing the lock code removing all the user-added certs.

Reply on news.ycombinator.com