TLS certificate management on Android [LWN.net]

By Jonathan Corbet
March 2, 2016

In theory, the TLS certificate system increases security by letting users verify that they are connecting to the sites that they think they are. In practice it hasn't worked out as well as one might hope for a number of reasons; these range from intermediary sites that look like man-in-the-middle (MITM) attacks to inept and fraudulent certificate authorities. Sometimes it seems like the systems we use are set up in ways designed to make security difficult; Android's handling of user-supplied certificates is a case in point.

Whenever an application makes a TLS connection to another host, it should validate the certificate it receives from that host to be sure that the connection has not been intercepted. One aspect of that validation is ensuring that the certificate is issued to the expected site; many apps (on Android and beyond) tend not to bother with that step, assuming that any certificate they get is good enough. There is another important step, though: ensuring that the certificate has been signed by a certificate authority (CA) that the user trusts. After all, anybody can create a certificate that claims to belong to, say, lwn.net, but the established CAs are not supposed to sign them without having somehow convinced themselves that the requestor actually owns the name.

Verifying the provenance of a certificate requires a database of the CAs that are trusted to sign certificates. On full-fledged Linux distributions, that database often comes from Mozilla, with perhaps a few distribution-specific tweaks. On Android, the CA database is managed centrally, so the policies established by Google control the trusting of certificates for most Android apps.

A complicating factor is that certificates that are not signed by one of the "trusted" CAs are common and have many legitimate uses. In some cases, the operator of a web site may just not want to deal with the trouble and expense of getting a recognized certificate. In other cases, there may be a need to set up one's own trusted CA that can issue arbitrary certificates. That is often done in institutional environments to assist with the operation of web proxies and virtual private networks. Such a certificate can also enable just the sort of MITM attack that TLS was meant to thwart; some companies will use them to monitor traffic into and out of their networks, for example.

Android makes it possible for a user to import a new CA certificate; after that, the device will trust certificates that have been signed by that CA. There is just one little difficulty: Android insists on putting up a scary warning at each boot, saying that "a third party is capable of monitoring your network activity". This happens despite the fact that the user has already been through a multi-step, warning-heavy process to install the certificate. There is, it seems, no straightforward way to make it go away.

Unsurprisingly, Android users who have reason to install their own CA certificates find this annoying. Many of them, perhaps, have a dim view of the trustworthiness of some of the CA certificates provided out of the box, and don't like having to slog through warnings to use a certificate they actually do trust. There have been various bug reports filed regarding this problem, but Google's response has been clear: the system is working as intended:

The "User" portion of the trusted credential store is non-system CA certificates that have been installed and are trusted by the browser and other things that use the system Trusted Certificate Store. This warning is about protecting the user of the device. [...] Asking for exceptions does not make sense. There is a process for getting a CA into the trusted list of browsers and operating systems.

In other words, the only way to get a truly trusted CA certificate installed on Android is to go through the entire CA process for companies that want to sell certificates to the world as a whole. It seems likely that your typical user wanting to install their own CA certificate will balk at that idea.

There are a few unpleasant things that can result from this sort of policy. One is that users will become (even more) used to brushing aside scary warnings without thinking about them. If the system is forever crying wolf, it will be unsurprising if users are not paying attention the one time that there is a true wolf to worry about. Another outcome is that users have a stronger incentive to root their devices so that apps like movecerts, which directly manipulate the certificate store to make the warnings go away, can be run. Rooting the device and running privileged apps, even open-source ones, presents some obvious security hazards of its own.

Bringing security into a discussion often introduces strange distortions, and TLS is especially prone to that. Web browsers will frighten users over self-signed certificates, but have no objection to sites that don't use TLS at all. In the Android case, users who have attempted to make proactive choices about their security are bombarded with warnings, while those using apps that fail to validate certificates hear nothing. The security circus, it seems, is still playing in all three rings.

Index entries for this article
Security	Android
Security	TLS certificates

to post comments

TLS certificate management on Android

Posted Mar 3, 2016 5:59 UTC (Thu) by ptman (subscriber, #57271) [Link] (46 responses)

One reasonable, IMHO, suggestion was to remove the warning for CA certificates that limit their scope. E.g. "nameConstraints=permitted;DNS:example.com" to limit the CA to only signing certificates ending in example.com.

TLS certificate management on Android

Posted Mar 3, 2016 6:32 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

That might lead to... to... gasp... delegation!

Just imagine every mom&pop company paying only ONCE to get *.momandpopcompany.com certifcate and signing THEIR OWN!!! third-level certificates instead of going through Established CA Authorities.

That can't be let to stand. Nope.

TLS certificate management on Android

Posted Mar 3, 2016 10:38 UTC (Thu) by anselm (subscriber, #2796) [Link] (3 responses)

The Established CA Authorities will presumably continue charging an arm and a leg for certificates that have the required flags set to act as a sub-CA, so it's probably not a real problem as far as they are concerned.

TLS certificate management on Android

Posted Mar 3, 2016 20:13 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

You can't charge too much - there's going to be a race to the bottom. And really lucrative clients like ebay.com or amazon.com will easily pay any amount of money for it.

TLS certificate management on Android

Posted Mar 6, 2016 20:35 UTC (Sun) by tialaramex (subscriber, #21167) [Link] (1 responses)

Amazon is already cross-signed and is seeking independent inclusion in major trust stores (e.g. Mozilla) because they want their Amazon Web Service product to have a one button SSL service of the sort you get for free on a cheap virtual host these days but they don't (quite reasonably) want to pay an existing for-profit CA to issue those certs. So Amazon can issue a million certs tomorrow across the entire namespace, they wouldn't want a delegation.

The "delegation" pipe dream is just that. Today, in 2016, there are brand new SSL certificates being minted that still don't use the correct method to indicate which DNS names the certificate is for, but instead rely on bug compatibility between major browsers to "get away" with continuing to do things the way they did with Netscape Navigator (remember that?)

Huge parts of the x509 certificate spec are written off as unsuitable for any purpose for years and probably decades to come because either incompetently written software was allowed to spread into the wild that relies on nobody using that part of the spec, or, perhaps even worse, Certification Authorities (who are supposed to be experts) signed certs that mis-used those parts of the spec and which don't expire for many years. Delegation is one of those parts. I thought it sounded like a brilliant idea when I first heard about it, but it can't work for probably a decade or more after we get CAs to treat it as real, and we're nowhere near even that. Nobody wants to fight with them about something we probably will never get to see any use out of anyway.

TLS certificate management on Android

Posted Mar 6, 2016 21:25 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

> So Amazon can issue a million certs tomorrow across the entire namespace, they wouldn't want a delegation.
I should have been more clear - large companies need a lot of certificates for internal purposes and for user-facing services.

AWS already has one-click SSL for load-balancers.

> The "delegation" pipe dream is just that... Huge parts of the x509 certificate spec are written off as unsuitable for any purpose
The problem is not that parts of X509 are not accessible, but that it's a freaking mess. And TLS is a doubly freaking mess.

Writing a fully conformant TLS stack with all the options supported is pretty much impossible. We're still getting bugs discovered in the spec itself (all those downgrade attacks).

The correct course of action would be designing a completely new infrastructure, that can utilize advances like DNSSEC from the start. It's a pipe dream, but still....

TLS certificate management on Android

Posted Mar 3, 2016 11:30 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (37 responses)

Completely useless for people who use certificates to talk to proxies, since the proxy will proxify anything on the internet.

Of course they only do that because the browser devs refuse to define a secure proxy protocol, with the same security circus scary warnings the article complains of, that do not solve anything but feel good to their issuer.

You're not supposed to proxyfy Google or check the certs your phone accepts, you're here to consume the content Google felt is good for its bottom line.

TLS certificate management on Android

Posted Mar 3, 2016 15:44 UTC (Thu) by josh (subscriber, #17465) [Link] (36 responses)

> the browser devs refuse to define a secure proxy protocol

There is a secure proxy protocol already: it gives you a channel to port 443 on a remote server over which you can do HTTPS to get real security. A bit silly compared to a direct connection, but *shrug*. What browser developers refuse to support is an *insecure* proxy protocol that allows MITM of HTTPS connections.

TLS certificate management on Android

Posted Mar 3, 2016 16:11 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (35 responses)

So :

1. Where is the RFC ?
2. What browsers actually implement it ?
3. How do users authentify to the proxy ?
4. What happens when proxy auth expires while the user is browsing an HTTPS website ? Will the browser renew auth to continue browsing ?

TLS certificate management on Android

Posted Mar 3, 2016 16:33 UTC (Thu) by josh (subscriber, #17465) [Link] (34 responses)

CONNECT is covered in a few places:

https://tools.ietf.org/html/rfc2616#section-9.9

https://tools.ietf.org/html/rfc2616#ref-44

http://tools.ietf.org/html/draft-luotonen-web-proxy-tunne...

Possibly others I'm not familiar with, as well. Every major browser implements that, as do most HTTP libraries and command-line software.

I don't know where proxy authentication (username/password or similar) is documented or how good the handling of that is in browsers and libraries. But that's a separate issue from certificate handling for the site on the other side of the proxy.

TLS certificate management on Android

Posted Mar 3, 2016 19:05 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (33 responses)

Well the answer is, it's not good, it's not even bad, it's inexistent.

Which is why anyone who actually tries to run a proxy, injects a new CA root in the browser. Just to bypass the horrific browser TLS mess, which is more concerned with telling you how bad you are (in typical dilbertian information preventer mode), than actually helping you to connect securely to the proxy you chose to use.

So please do not pretend there are other solutions unless you've actually tried them with success.

TLS certificate management on Android

Posted Mar 3, 2016 19:35 UTC (Thu) by josh (subscriber, #17465) [Link] (32 responses)

CA roots are a *completely* different topic. You should not need a CA root just to run a proxy, unless that proxy is MITMing traffic.

And it's the browser's job to tell you that your network is making your connection insecure. It's more important to protect the majority of Internet users than to make life easier for corporate IT administrators trying to do things they shouldn't.

corporate IT administrators

Posted Mar 6, 2016 23:15 UTC (Sun) by tialaramex (subscriber, #21167) [Link] (30 responses)

As an example of those "corporate IT administrators" I give you the example of an internationally famous FTSE 100 Company which uses the McAfee Web Gateway to MITM proxy all its employees.

Out of the box, the McAfee Web Gateway's built-in CA certificate (used to sign certificates pretending to be Google, Amazon, LWN, HSBC, the British Government and so on) is of course not trusted by anybody. But you can force every corporate computer to add this CA cert to its trust store and so that's what this FTSE 100 Company have done. That way you shut up all the anti-MITM features. In fact (contrary to what you might expect if you believed Nim-Nim's rants) browser vendors go out of their way to allow this to work, because corporates insist upon it.

Having this single point of failure in your security infrastructure isn't a good idea, but in principle it /could/ work and not be that much more dangerous than not having the MITM proxy. There's really only one problem. McAfee Web Gateway isn't a custom solution developed for that one FTSE 100 Company, it's a commercial product, anybody can buy one (under a variety of names, the core software is the same). So the effect of adding "McAfee Web Gateway" to a computer's trust store is to allow anybody who has purchased the product, or who has obtained the private key from a legitimate purchaser's product, to impersonate literally any SSL site to all employees of the FTSE 100 Company.

To be fair to them, Intel / McAfee do document this problem in the product manual, and doubtless if any actual smart, security-minded people were buying MITM proxies they'd ask "So, how do we attach this to the HSM we use as a responsible corporation to do our PKI?" and have it all explained. But the average corporate IT administrator at a non-software company (even with a multi-billion dollar market cap) is happy that they spent a five figure sum of money on "securing web access" and they can check that off their Information Security checklist. If you explain to them that actually they've completely undermined a crucial element of the security infrastructure they'd be dumbfounded, they paid thousands of dollars, how can that not mean their security is better ?

corporate IT administrators

Posted Mar 7, 2016 13:04 UTC (Mon) by nim-nim (subscriber, #34454) [Link] (29 responses)

Some more disinformation

What corporates insist on is a way to hook browsers on their security gateways (aka proxies). Because they feel the cost of an intrusion is such the pain of those security gateways is more than worth it. And they actually trust their security provider more than any random website (surprise).

Browser authors, on the other hand, refuse to make their products work properly with those equipments except by adding a root CA to the trust store (tialaramex's § 2). And complain all year round how horrific this solution is (tialaramex's § 3 and 4). And offer vaporous alternatives that never actually solve anything when you take 5s to actually consider them¹.

Well, no corporate is in love with the technical solution either, and they'd drop it in a blink if something else was available.

But browser people do *not* make something else available. Because that would allow anyone to delegate the security of their accesses to the entity they, *not* the browser authors, chose. And freedom (when it means making your mind without browser "help"), is badforyourhealth®.

So they intentionally perpetuate an horrific technical solution, that forces impersonating websites, and forces disabling browser TLS checks, so they can attack it from a technical POW. And avoid stating plainly they want to keep their lock on HTTPS accesses. And refuse to help their users delegate the security of accesses to something else than browsers. They will happily relay your traffic right and left (pocket, google ad platforms, etc), but god forbid *you* chose to relay it to the security equipment *you* selected and paid for.

*None* of it is an actual technical requirement. Separating the proxy TLS checks from the browser TLS checks is not rocket science (just put proxy negotiation outside the website http headers). But no one can do it without browser cooperation. And browser people are happy to keep the statu quo ante. And harass proxy users. And complain of CAs that impersonate third parties.

¹ Case in point, you can add all the HSMs you want, browser behaviour will still force you to import the CA and make it impersonate Google & friends to make the proxy work, and they will still crucify you for this impersonation, and still FUD about the un-trustliness of the CA owner.

corporate IT administrators

Posted Mar 7, 2016 16:29 UTC (Mon) by josh (subscriber, #17465) [Link] (13 responses)

I don't see anything wrong with making it possible to trust a proxy's certificate separate from that of the traffic passing through the proxy; that seems like a good thing. That would secure traffic to the proxy itself, which does seem useful if authenticating to the proxy. But I don't think browsers should do *anything* to make it easier to MITM HTTPS traffic; no matter the path to the proxy, the proxy itself should continue using CONNECT or similar to pass through HTTPS traffic unmodified.

If anything, browsers need to make MITM attacks harder: when they see a site with a pinned certificate using a different certificate that's in the browser trust store, they should make that MITM visible to the user.

This isn't about browsers ceding their own control; this is about browsers keeping the user safe and in control.

For that matter, browsers have a long history of targeting the end user, not the corporate IT department; many people have fond memories of installing Firefox (or Mozilla before that) on systems that were "supposed" to run IE.

corporate IT administrators

Posted Mar 7, 2016 16:43 UTC (Mon) by nim-nim (subscriber, #34454) [Link] (4 responses)

If you want to make sure your malware proxy is not modifying traffic you need integrity, ie digital signatures. Hiding the traffic from the malware checker defeats its purpose.

corporate IT administrators

Posted Mar 7, 2016 19:22 UTC (Mon) by josh (subscriber, #17465) [Link] (3 responses)

That's an interesting concept that I haven't seen brought up in such discussions before. While I'd still never want to use such a network myself, it'd certainly be *interesting* to have a protocol that could support integrity protection that prevents MITM modification, while still allowing monitoring. That could be useful in an environment with regulatory compliance issues, and it'd be somewhat less problematic than allowing MITM.

That said, while such an approach might get some of the existing IT departments running MITM proxies to switch, it might also get IT departments that currently *don't* break HTTPS to try to use that interception mechanism when they would otherwise have had no such option. So I'm not entirely convinced that such an option would be a net positive.

corporate IT administrators

Posted Mar 8, 2016 2:17 UTC (Tue) by flussence (guest, #85566) [Link] (2 responses)

>While I'd still never want to use such a network myself, it'd certainly be *interesting* to have a protocol that could support integrity protection that prevents MITM modification, while still allowing monitoring.

SSL/TLS itself is already capable of that: the command `openssl ciphers -v 'eNULL:!aNULL'` will give you a list of cipher suites (including one in TLS 1.2) which send the data in clear text but cryptographically signed. Naturally, this won't work in a browser.

corporate IT administrators

Posted Mar 8, 2016 6:12 UTC (Tue) by josh (subscriber, #17465) [Link] (1 responses)

That would make it cleartext end-to-end, rather than encrypted from the site to the proxy and the proxy to the browser, and only cleartext-with-integrity-protection to the proxy itself.

corporate IT administrators

Posted Mar 8, 2016 17:59 UTC (Tue) by nybble41 (subscriber, #55106) [Link]

It should still be possible to implement cleartext-with-integrity-protection without changing TLS per se, though you would need an out-of-band protocol for communication between the client and the proxy. The client just needs to give the proxy the decryption key which it derives from the DH master secret. If it keeps the corresponding HMAC secret to itself then the proxy can decrypt the traffic, but not tamper with it; end-to-end authenticity would thus be preserved.

corporate IT administrators

Posted Mar 8, 2016 16:26 UTC (Tue) by raven667 (subscriber, #5198) [Link] (5 responses)

> But I don't think browsers should do *anything* to make it easier to MITM HTTPS traffic; no matter the path to the proxy, the proxy itself should continue using CONNECT or similar to pass through HTTPS traffic unmodified.

The purpose of the proxy is to inspect the cleartext to block malware, or network usage that violates the policy of the owner, when the same administrative entity owns the network and edge equipment. The problem is that anything which makes it easier to MITM for legitimate security reasons, also can be used by bad actors to transparently intercept traffic in ways that are difficult to detect for the average person. The browser vendors are making the policy decision that protecting people from repressive governments or criminal organizations is more important than enabling inspection by admin policy.

corporate IT administrators

Posted Mar 8, 2016 18:01 UTC (Tue) by nim-nim (subscriber, #34454) [Link] (4 responses)

Actually, they're not protecting anyone. It's easier to grandstand publicly than actually cut proxies and deal with the backlash of all their users. So they end up supporting the worst kind of MITM officiously, instead of working to make it as safe as possible and under user control.

And yes like any useful tech it can be used for evil purposes. Let's kill mail to put an end to spammers.

corporate IT administrators

Posted Mar 8, 2016 18:38 UTC (Tue) by raven667 (subscriber, #5198) [Link] (3 responses)

> Actually, they're not protecting anyone. It's easier to grandstand publicly than actually

If you can't even understand or acknowledge the perspective of the people you are arguing with, how do you expect to effectively communicate your point? Changing minds requires a dialog not a monologue.

corporate IT administrators

Posted Mar 8, 2016 22:19 UTC (Tue) by nim-nim (subscriber, #34454) [Link] (2 responses)

I'm sorry, but what exactly are you taking offense at?

Did I write anything but the truth?

Am I wrong when I state that despite vehement public opposition to the idea, browser people make sure year after year that it is possible to MITM connexions by importing CAs in their certificate stores? That is a fact and easily checked by consulting browser changelogs.

Am I wrong when I state that making standard communication with proxies obsolete, by refusing to overhaul it with the rest of the web stack, only pushed corporations and security providers to convert massively to the worst and most dangerous kind of MITM? Who targets anything else nowadays?

Am I wrong when I state the people browsers claim to "protect", actually use the tech browsers want to ban (proxies), to protect themselves (for example to bypass the great firewall of China)? That this technology is by no means as one-sided as the browser discourse wants you to believe?

Am I wrong when I state that refusing to give browser users the interfaces to check whom they are giving access to, only results in having this access taken without control?

What, exactly, is accomplished by continuing to push for an ideal state, while enabling its exact reverse year after year, since society is not ready for this ideal state today (will it ever be?) Would it be such a defeat to give browser users a middle ground solution now, instead of waiting for a complete victory that refused to happen for at least a decade?

And, BTW, I do not mean ideal in the positive sense. I mean ideal in the imaginary sense. We've left the point, when one could imagine connecting to the Internet, without firewalls and other security tools, a long time ago. Refusing to secure the network, because browsers have their own security, is irresponsible (first, all connexions are not made via browsers, and second, even if they were, why should we trust browsers absolutely?)

corporate IT administrators

Posted Mar 9, 2016 1:57 UTC (Wed) by raven667 (subscriber, #5198) [Link] (1 responses)

I wsnt taking any offence, I was providing advice on how to better communicate your point, which you seem to have completely missed, and kind of underlines what I was saying.

corporate IT administrators

Posted Mar 9, 2016 18:33 UTC (Wed) by nim-nim (subscriber, #34454) [Link]

Please realise, that taking the higher moral ground ("protecting people from repressive governments or criminal organizations") while refusing to discuss facts that contradict this manichean view, is highly inflammatory in itself.

corporate IT administrators

Posted Mar 9, 2016 16:46 UTC (Wed) by raven667 (subscriber, #5198) [Link] (1 responses)

> browsers need to make MITM attacks harder

I actually wanted to take another stab at this one, if the same entity owns the network, proxy and end-point host then they aren't a MITM, they are the owner, so funneling all traffic through a proxy to inspect the clear text is _not_ a MITM attack, it's a way for the owner of the machine to centralize security policy rather than requiring a plugin or extension to be run on every instance of the browser.

This kind of thing is only a problem when the middle box and end-point host are not owned by the same entity, in the case of a network allowing guest access or an ISP these kinds of technologies would be highly unethical, but the context does matter.

Maybe the real problem is in implementation, centralized middleboxes are the past and distributed software with centralized configuration management the future, and the best way to handle this kind of security problem is with centrally managed browser extensions that perform the same function as the malware scanning middle boxes. No matter what system you choose to do scanning you require a high level of administrative access on the end-point hosts, if you don't have that then you probably shouldn't be attempting this kind of inspection.

corporate IT administrators

Posted Mar 9, 2016 18:41 UTC (Wed) by nim-nim (subscriber, #34454) [Link]

Good luck deploying your distributed software on all the nodes that do https today. Starting with all the iot stuff.

Centralized middleboxes exist because any generalized deployment on a non-trivial network parc is harder than hell. gmail, facebook, all the current web giants, exploit the economies of scale of centralizing processing.

corporate IT administrators

Posted Mar 9, 2016 15:08 UTC (Wed) by tialaramex (subscriber, #21167) [Link]

It's not disinformation, I was simply reporting the facts. Facts which you didn't address at all. Because they make your whole stance look as feeble as it actually is. You trust "corporate IT administrators" as proxies for difficult security problems. That's a terrible joke, as I illustrated.

I want to underscore that I wasn't giving a vague example of what might happen, I was describing reality, as it was when I wrote about it, on the ground, at a regulated financial company with a multi-billion dollar market capitalisation.

corporate IT administrators

Posted Mar 10, 2016 9:24 UTC (Thu) by paulj (subscriber, #341) [Link] (13 responses)

You're complaining that the browsers are somehow refusing to reasonably act in providing a MITM vector friendly to corporate proxies to monitor traffic of users' who are contractually (and lawfully) obliged to agree to such monitoring. The problem is there no known way to implement this that doesn't also give bad guys a MITM vector.

Please explain exactly how a browser, acting on behalf of a user, is supposed to distinguish between a MITM proxy that the user /should/ allow and one it should not?

It has to be technically possible and implementable, otherwise you're just howling at the moon.

corporate IT administrators

Posted Mar 10, 2016 13:37 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (12 responses)

How do you recognize anything on the Internet ? You show the user the proxy URL, you show the user the proxy cert, and you ask if he authorizes proxying by this entity.

And you give him a console to check what he authorized in the past so he can revoke at need.

No different from GPG, ssh, all the other secure systems on earth.

What you do *not* do is decide on behalf of the user. That's *his* data stream *his* decision, not yours.

corporate IT administrators

Posted Mar 10, 2016 19:39 UTC (Thu) by flussence (guest, #85566) [Link]

This far into the circus act I'm beginning to wonder whether you actually have no clue what a corporate network and IT infrastructure is, and why its requirements (legal and technical) require proxies. The other possibility is that you're being paid to misunderstand everything being explained to you, which makes your employer/sponsor look like a bit of an idiot.

corporate IT administrators

Posted Mar 10, 2016 20:59 UTC (Thu) by paulj (subscriber, #341) [Link] (10 responses)

And how will the net security effect of that approach be any different to the current "install a root cert and let the proxy MITM everything" approach of today?

corporate IT administrators

Posted Mar 10, 2016 21:25 UTC (Thu) by bronson (subscriber, #4806) [Link] (5 responses)

A permissions dialog is going to pop up on every new connection? It sounds like the net security effect is mostly in making it unusable.

I'd hazard that approximately 100% of network owners wouldn't want this, and 99.9% of network users wouldn't want it either.

corporate IT administrators

Posted Mar 11, 2016 12:13 UTC (Fri) by nim-nim (subscriber, #34454) [Link] (4 responses)

Sure, let's implement it the dumbest way possible, and then remove it because the implementation is dumb.

corporate IT administrators

Posted Mar 13, 2016 3:49 UTC (Sun) by bronson (subscriber, #4806) [Link] (3 responses)

Isn't that exactly what you proposed?

> You show the user the proxy URL, you show the user the proxy cert, and you ask if he authorizes proxying by this entity.

corporate IT administrators

Posted Mar 14, 2016 14:09 UTC (Mon) by nim-nim (subscriber, #34454) [Link] (2 responses)

I never proposed "A permissions dialog is going to pop up on every new connection"

In fact I explicitly wrote about needing an UI to handle revocations, ie the browser remembering the permissions till the user revokes them.

corporate IT administrators

Posted Mar 14, 2016 19:24 UTC (Mon) by bronson (subscriber, #4806) [Link] (1 responses)

Curious then, how else are you going to show the proxy URL and cert, and wait for permission? (Gnome and KDE experience has shown that notifications aren't enough.)

corporate IT administrators

Posted Mar 16, 2016 15:29 UTC (Wed) by nim-nim (subscriber, #34454) [Link]

Sure you need to show the "do you trust xxxx to proxify your traffic" dialog. But once not every time you connect.

I won't say that's trivial, but that's not *that* hard. Browsers do such messages all the time when there is something they don't like (dns, cert, etc).

On an ideal properly integrated desktop that would go on the network connexion widget like wifi passwords and vpns (from a functional POW a proxy is a pure HTTP/s VPN)

corporate IT administrators

Posted Mar 11, 2016 12:10 UTC (Fri) by nim-nim (subscriber, #34454) [Link] (2 responses)

Please, do not discuss security matters if you have no understanding of why making permissions explicit, auditable, and revocable, matters.

corporate IT administrators

Posted Mar 11, 2016 21:52 UTC (Fri) by paulj (subscriber, #341) [Link] (1 responses)

Good way to answer the question...

corporate IT administrators

Posted Mar 14, 2016 14:16 UTC (Mon) by nim-nim (subscriber, #34454) [Link]

"Let's ignore all the content in a (long) thread, and restart from the beginning". Is that really a question?

corporate IT administrators

Posted Mar 22, 2016 17:58 UTC (Tue) by nye (guest, #51576) [Link]

>And how will the net security effect of that approach be any different to the current "install a root cert and let the proxy MITM everything" approach of today?

It would mean that all of the original TLS information is available to the browser, which can verify it and present it to the user in the usual way, rather than being stripped by the proxy and replaced with something else as is currently necessary because the only way to proxy https is nasty MITM shenanigans.

TLS certificate management on Android

Posted Mar 22, 2016 17:50 UTC (Tue) by nye (guest, #51576) [Link]

>It's more important to protect the majority of Internet users than to make life easier for corporate IT administrators trying to do things they shouldn't.

When the fuck did "provide a caching proxy for the use of clients configured to trust it, at home, at work, or otherwise" become "corporate IT administrators trying to do things they shouldn't"?

How did we reach this state where obvious brokenness is defended by invoking rampant mindless paranoia, and otherwise seemingly intelligent people swallowing the bullshit?

I guess caching proxies are used by terrorists, or paedophiles, or communists, or something? I bet Hitler would have used one if the technology had been available, so it must be the worst form of devilry, right?

Congratulations, you've rendered me insensible with rage.

TLS certificate management on Android

Posted Mar 3, 2016 12:42 UTC (Thu) by robbe (guest, #16131) [Link]

Did you (or anyone else reading this) get nameConstraints working across a solid majority of browsers? I couldn’t… and I’d really like to have our own internal CA constrained to internal names.

These intranet services are the main holdouts here that don’t have Letsencrypt certs on them. The other being stupid appliances where automation is neigh-impossible, and you’d have to click through a daft web-interface every three months to update the certificate.

TLS certificate management on Android

Posted Mar 3, 2016 15:52 UTC (Thu) by josh (subscriber, #17465) [Link] (1 responses)

So many TLS stacks fail to honor nameConstraints that allowing such a certificate today would be quite dangerous.

TLS certificate management on Android

Posted Mar 3, 2016 15:54 UTC (Thu) by josh (subscriber, #17465) [Link]

That said, while nameConstraints doesn't yet work in enough software to deploy this widely, I'd be interested in the ability to manually tell a browser or other software "allow this root CA, but *only* for subdomains of this domain, not all sites despite what the cert says". That would work nicely for Intranet sites that use a common CA root.

TLS certificate management on Android

Posted Mar 3, 2016 21:08 UTC (Thu) by flussence (guest, #85566) [Link] (1 responses)

I've found the best workaround is to use programs that ignore the system CA store and implement a TOFU policy for all certificates.

Somewhat ironically, Google itself has done the best job of conditioning me to click through TLS warnings with its GMail IMAP certs, which feel like they change on a daily basis.

TLS certificate management on Android

Posted Mar 4, 2016 18:52 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

They seems to rotate every other week or so. But it isn't a hard deadline; I've gotten the previous cert's fingerprint after a new cert fingerprint showed up.

TLS certificate management on Android

Posted Mar 4, 2016 20:39 UTC (Fri) by RogerOdle (subscriber, #60791) [Link]

I see a persistent problem is that it is up to the application developers to decide security policy. "Should all certs be checked against root CA. Should some be exempt?" These are the province of the system administrator, not the developer. OpenSSL, or what ever system is used, needs to serve the purposes of the system first and the application last. It seems to me that the API needs to be changed to force the applications to go through the system and get permission according to established policy and not to decide action on its own.

I think that distros can help by either not allowing non-compliant security libraries to be installed or to provide versions of the common libraries (OpenSSL, NSS, ssh...) that work with the system and not independently.

TLS certificate management on Android

Posted Mar 5, 2016 13:09 UTC (Sat) by acathrow (subscriber, #13344) [Link]

This article reminded me of a session at last year's RSA conference about root Certificates on mobile devices.
The slides are on line but the firm behind them also made a blog which is easier reading
https://bluebox.com/questioning-the-chain-of-trust-invest...

Let's Encrypt

Posted Mar 6, 2016 14:41 UTC (Sun) by tialaramex (subscriber, #21167) [Link] (2 responses)

"In some cases, the operator of a web site may just not want to deal with the trouble and expense of getting a recognized certificate"

This case shouldn't be any trouble or expense now, because we have Let's Encrypt. Indeed having Let's Encrypt allowed me to remove the CA cert I'd manually generated and installed on my personal Android devices to protect my own sites.

For example, I have some sites hosted by Dreamhost, a cheap virtual hosting provider. I can click "Secure Hosting", click on a site, check the box saying I'll use Let's Encrypt thanks, agree to the T&C box and I'm done. Dreamhost sort everything out. It's actually a LOT easier than setting up my own CA was. Maybe 5 seconds per domain once, versus an hour for setup, plus 5 minutes per domain every year.

It's true that _some_ web hosts don't offer Let's Encrypt, preferring instead of hawk an affiliated CA's products. Some still, in 2016, won't let you use SSL with their virtual hosting at all because they're worried your customers on Internet Explorer for Windows XP will be confused (it does seem likely that customers using Windows XP are confused, I'd be confused if I was stuck with Windows XP in 2016) but these are problems with a provider, and I think we can expect them to dwindle away.

CT logs allow us to see that Let's Encrypt is now issuing more certificates than the entire for-profit Certificate Authority market. They also, perhaps not coincidentally allow us to see that Let's Encrypt are one of the few big CAs whose certificates aren't riddled with technical mistakes, CABforum compliance errors and other things you'd like to think a "professional" outfit wouldn't let out the door‡. Turns out that to issue tens of thousands of certificates every day fully automatically you have to get rid of steps like "manually transcribe information from this field into this other field" that cause the for-profit CAs to constantly screw stuff up.

‡ Recently CABforum voted on whether the CAs ought to report "mis-issuance" publicly. This would include both the sort of technical errors I alluded to above, and numerous other types of mistake. The browser vendors voted "Yes", the CAs voted "No" (or in some cases abstained) and so the proposal was dead. Turns out if you constantly screw up it's way easier to just not tell anybody than to investigate why you keep screwing up. Huh.

Let's Encrypt

Posted Mar 8, 2016 7:04 UTC (Tue) by jezuch (subscriber, #52988) [Link] (1 responses)

> Turns out if you constantly screw up it's way easier to just not tell anybody than to investigate why you keep screwing up. Huh.

Huh indeed. There are some industries where safety is so critical that they voluntarily adopted disclusure policies stating that if you disclose your failures, nobody wll blame you for them. Aviation industry is one of those, I think. Turns out that this makes everyone safer and, notably, it does *not* reduce public trust in the industry. Quite the contrary in fact. Will the CAs see the light eventually? Who knows?...

Let's Encrypt

Posted Mar 9, 2016 16:20 UTC (Wed) by tialaramex (subscriber, #21167) [Link]

For the CAs the situation with web browsers is a bit weird. I wrote a long thing here originally but here's the short version:

CAs existed before the World Wide Web, and when SSL was invented and they were given a role on the Web they probably expected to outlive it. So CA roots aren't, as we might think of them today, the root of a hierarchy filled entirely with stuff about web sites. Instead along with the millions of web sites are VISA payment terminals, Exchange mail servers, Government tax IDs, Pay-per-view movie systems for Cable TV, and so on. Today it seems crazy to put all this stuff in one hierarchy, but that situation sneaked up on them and so far we're stuck with it, mostly with negative consequences.

I think we're at a turning point right about now, for a number of reasons which I'll list below, which means we might see some hard choices actually made and stop kicking some of the security cans down the road.

* The trust / don't trust / kinda-sorta-trust metrics (and less importantly UI) in browsers have become more sophisticated, offering a middle ground where you can threaten to mark a CA's certificates as less trusted than its competitors without causing a tidal wave of user dissatisfaction. Google have already done this for EV for example. If your CA doesn't obey Google's extra rules for EV your EV certs still work as SSL certs, but they don't give the EV "green bar" effect in Chrome.

* Sunlight. CA/Browser forum was originally a darkened room affair. Almost all business now (since mid-2012) takes place in public, and anything which is done privately has to be ratified in public, giving anybody who'd rather it hadn't happened in the dark an opportunity to up-end the can of worms and force it to be re-examined in the light.

* Let's Encrypt. Previously the for-profit CAs made up such an overwhelming majority of all certificates issued that if they stood together the browser vendors had no option but to put up with whatever they offered. But since late-2015 there's a non-profit that could take up a lot of the slack overnight. Abolishing for-profit CAs isn't on the roadmap, but for-profit CAs can no longer just insist it's their way or the highway.

TLS certificate management on Android

Posted Mar 10, 2016 10:05 UTC (Thu) by simosx (guest, #24338) [Link]

There is an Xposed module to hide that Android warning,
http://repo.xposed.info/module/it.skarafaz.xposed.nwmonbl...