Public key certificate
I’m dealing with the hassle of setting up certs for a new site over the last few days. It means using startcom’s certs because they’re pretty good (only one security breach) and they have a decently low-hassle free certificate that won’t trigger BS warnings in browsers marketing fake cert mafia placebo security products to unwitting users. (And the CTO answers email within minutes well past midnight.)
And in the middle of this, news of another breach to the CA system was announced on the heels of Lenovo’s SuperFish SSL crack, this time a class break that resulted in a Chinese company being able to generate the equivalent of a lawful intercept cert and provided it to a private company. Official lawful intercept certificates are a globally used tool to silently crack SSL so official governments can monitor SSL encrypted traffic in compliance with national laws like the US’s CALEA.
(aww, someone liked this: https://news.ycombinator.com/item?id=5858538)
But this time, it went to a private company and they were using it to intercept and crack Google traffic, and Google found out. The absurdity is to presume that this is an infrequent event. Such breaches (and a “breach” isn’t a lawful intercept tool, which are in constant and widespread use globally, but such a tool in the “wrong” hands) happen regularly. There’s no data on the ratio of discovered breaches to undiscovered breaches, of course. While it is possible that they are always found, seemingly accidental discoveries suggest far wider misuse than generally acknowledged.
The cert mafia should be abolished. Certificate authorities work for authoritarian environments in which a single entity is trusted by fiat as in a dictatorship or a company. The public should trust public opinion and a tool like Perspectives would end these problems as well as significantly lower the barrier to a fully encrypted web as those of us trying to protect our traffic wouldn’t need to choose between forking over cash to the cert mafia for fake security or making our users jump through scary security messages and complex work-arounds.
Google’s Chrome is a useful tool to have around, but the security features have gotten out of hand and make it increasingly useless for real work without actually improving security.
After a brief rant about SSL, there’s a quick solution at the bottom of this post.
Chrome’s Idiotic SSL Handling Model
I don’t like Chrome nearly as much as Firefox, but it does do some things better (I have a persistent annoyance with pfSense certificates that cause slow loading of the pfSense management page in FF, for example). Lately I’ve found that the Google+ script seems to kill firefox, so I use Chrome for logged-in Google activities.
But Chrome’s handling of certificates is abhorrent. I’ve never seen anything so resolutely destructive to security and utility. It is the most ill-considered, poorly implemented, counter-productive failure in UI design and security policy I’ve ever encountered. It is hateful and obscene. A disaster. An abomination. The ill-conceived excrement of ignorant twits. I’d be happy to share my unrestrained feelings privately.
I’ve discussed the problem before, but the basic issues are that:
- The certificate authority is NOT INVALID, Chrome just doesn’t recognize it because it is self-signed. There is a difference, dimwits.
- This is a private network (10.x.x.x or 192.168.x.x) and if you pulled your head out for a second and thought about it, white-listing private networks is obvious. Why on earth would anyone pay the cert mafia for a private cert? Every web-interfaced appliance in existence automatically generates a self-signed cert, and Chrome flags every one of them as a security risk INCORRECTLY.
- A “valid” certificate merely means that one of the zillions of cert mafia organizations ripping people off by pretending to offer security has “verified” the “ownership” of a site before taking their money and issuing a certificate that placates browsers
- Or a compromised certificate is being used.
- Or a law enforcement certificate is being used.
- Or the site has been hacked by criminals or some country’s law enforcement.
A “valid” certificate doesn’t mean nothing at all, but close to it.
So one might think it is harmless security theater, like a TSA checkpoint: it does no real harm and may have some deterrent value. It is a necessary fiction to ensure people feel safe doing commerce on the internet. If a few percent of people are reassured by firm warnings and are thus seduced into consummating their shopping carts, improving ad traffic quality and thus ensuring Google’s ad revenue continues to flow, ensuring their servers continue sucking up our data, what’s the harm?
The harm is that it makes it hard to secure a website. SSL does two things: it pretends to verify that the website you connect to is the one you intended to connect to (but it does not do this) and it does actually serve to encrypt data between the browser and the server, making eavesdropping very difficult. The latter useful function does not require verifying who owns the server, which can only be done with a web of trust model like perspectives or with centralized, authoritarian certificate management.
How to fix Chrome:
The damage is done. Millions of websites that could be encrypted are not because idiots writing browsers have made it very difficult for users to override inane, inaccurate, misleading browser warnings. However, if you’re reading this, you can reduce the headache with a simple step (Thanks!):
Right click on the shortcut you use to launch Chrome and modify the launch command by adding the following “
Once you’ve done this, chrome will open with a warning:
YAY. Suffer my ass.
Java? What happened to Java?
Java sucks so bad. It is the second worst abomination loosed on the internet, yet lots of systems use it for useful features, or try to. There’s endless compatibility problems with JVM versions and there’s the absolutely idiotic horror of the recent security requirement that disables setting “medium” security completely no matter how hard you want to override it, which means you can’t ever update past JVM 7. Ever. Because 8 is utterly useless because they broke it completely thinking they’d protect you from man in the middle attacks on your own LAN.
However, even if you have frozen with the last moderately usable version of Java, you’ll find that since Chrome 42 (yeah, the 42nd major release of chrome. That numbering scheme is another frustratingly stupid move, but anyway, get off my lawn) Java just doesn’t run in chrome. WTF?
Turns out Google, happy enough to push their own crappy products like Google+, won’t support Oracle’s crappy product any more. As of 42 Java is disabled by default. Apparently, after 45 it won’t ever work again. I’d be happy to see Java die, but I have a lot of infrastructure that requires Java for KVM connections, camera management, and other equipment that foolishly embraced that horrible standard. Anyhow, you can fix it until 45 comes along…
To enable Java in Chrome for a little while longer, you can follow these instructions to enable NPAPI (which enables Java). Type “
chrome://flags/#enable-npapi” in the browser bar and click “
One of the most horrible mistakes made in the early days of the internet was to use SSL (an “HTTPS” connection) for both securing a connection with encryption and verifying that the server you reach matches the URL you entered.
Encryption is necessary so you can’t be spied on by anyone running wireshark on the same hotspot you’re on, something that happens all the time, every day, to everyone connecting to public wifi, which means just about everyone just about any time they take a wifi device out of the house. It is pretty certain that you – you yourself – have thwarted cybercrime attempts thanks to SSL, not just once but perhaps dozens of times a day, depending on how often you go to Starbucks.
The second purpose, attempting to guarantee that the website you reached is served by the owner of the domain name as verified by some random company you’ve never heard of is an attempt to thwart so-called “Man in the Middle” (MITM) and DNS poisoning attacks. While these are also fairly easy (especially the latter), they’re both relatively uncommon and the “fix” doesn’t work anyway.
In practice, the “fix” can be detrimental because it gives a false sense of security to that sliver of the population that knows enough to be aware that the browser bar ever shows a green lock or any other indicator of browser trust and not aware enough to realize that the indicator is a lie. It is beyond idiotic that our browsers make a big show of this charade of identity verification with great colorful warnings of non-compliance whenever detected to order to force everyone to pay off the cert mafia and join in the protection racket of pretending that their sites are verified.
I’ve written before why this is counterproductive, but the basic problems is that browsers ship with a set of “root” certificates1You can review a list of the certificates of trusted Certificate Authorities here. Note that the list includes state-agency certificates from countries with controversial human rights records. that they trust for no good reason at all except that there’s a massive payola racket and if you’re a certificate issuer with a distributed accepted CA certificate you can print money by charging people absurd fees for executing a script on your server which, at zero cost to the operator, “signs” their certificate request (oh please, please great cert authority sign my request) so that browsers will accept it without warning. It isn’t like they actually have the owner of the site come in to their office, show ID, and verify they are who they say they are. Nobody does that except CACert; which is a free service and, surprise, their root cert is not included in any shipping browser.
Users then will typically “trust” that the site they’re connecting to is actually the one they expected when they typed in a URL. Except they didn’t type a URL, they clicked on a link and they really have no idea where there browser is going and will not read the URL in the browser bar anyway and bankomurica.com is just as valid as bankofamerica.com, so the typical user has no clue where the browser thinks it is going and a perfectly legit, valid cert can be presented for a confusing (or not really so much) URL. Typosquatters and pranksters have exploited this very successfully and have proven beyond any doubt that pretending that a URL is an unambiguous identifier is foolish and so too, therefore, is proving that the connection between the browser and the URL hasn’t been hijacked.
Further, law enforcement in most countries require that service providers ensure that it is possible to surreptitiously intercept communications on the web: that is do the exact thing we’re sold that a “valid” certificate makes “impossible.” In practice they get what are called “lawful intercept” certificates which are a bit like fireman’s key that doesn’t compromise your security because only a fireman would ever, ever have one.. Countries change hands and so do these. If you think you’re a state-level target and certificate signing has any value, you’re actually putting your life at risk. This is an immense disservice because there will be some people at risk, under surveillance, who will actually pay attention to the green bar and think it means they are safe. It does not. They may die. Really.
Commercial certs can cost thousands of dollars a year and they provide absolutely zero value to the site visitor except making the browser warnings go away so they can visit the site without dismissing meaningless and annoying warnings. There is absolutely no additional value to the site operator for a commercial cert over a completely free self-signed cert except to make the browser warnings go away for their visitors. The only entity that benefits from this is the certificate vendor from the fees they charge site operators and for the browser vendor for whatever fees are associated with including their certificates in the browser installer. You, the internet user, just lose out because small sites don’t use encryption because they can’t afford certs or the hassle and so your security is compromised to make other people rich.
There are far better tools2The hierarchical security model that browsers currently use, referencing a certificate authority, does work well for top-down organizations like companies or the military (oddly, the US Military’s root certificates aren’t included in browsers). In such a situation, it makes sense for a central authority to dictate what sources are trusted. It just does not make sense in an unstructured public environment where the “authority” is unknown and their vouch means nothing. that use a “Web Of Trust” model that was pioneered by PGP back in the early 1990s that actually does have some meaning and is used by CACert, meaning CACert certificates actually have some meaning when they indicate that the site you’re visiting is the one indicated by the URL, but since CACert doesn’t charge and therefore can’t afford to buy into the cert mafia, their root certs are not included in browsers, so you have to install it yourself.
The result is that a small website operator has four options:
- Give up on security and expose all the content that moves between their server and their visitors to anyone snooping or logging,
- Use a self-signed cert3If you’re running your own web services, for example a web-interface to your wifi router or a server or some other device with a web interface, it will probably use a self-signed cert and you’ve probably gotten used to clicking through the warnings, which at least diminishes the blackmail value of the browser warnings as people get used to ignoring them. Installing certificates in Firefox is pretty easy. It is a major hassle in Chrome or IE (because Chrome, awesome work Google, great job, uses IE’s certificate store, at least on Windows). Self-signed certs are used everywhere in IT management, almost all web-interfaced equipment uses them. IBM has a fairly concise description of how to install the certs. Firefox wins. to encrypt traffic that will generate all sorts of browser warnings for their visitors in an attempt to extort money from them,
- Use one of the free SSL certificate services that become increasingly annoying to keep up to date and provide absolutely zero authentication value but will encrypt traffic without generating warnings,
- Use CACert and ask users to be smart enough to install the CACert root certificate and thus actually encrypt and reasonably securely prove ownership.
|↑1||You can review a list of the certificates of trusted Certificate Authorities here. Note that the list includes state-agency certificates from countries with controversial human rights records.|
|↑2||The hierarchical security model that browsers currently use, referencing a certificate authority, does work well for top-down organizations like companies or the military (oddly, the US Military’s root certificates aren’t included in browsers). In such a situation, it makes sense for a central authority to dictate what sources are trusted. It just does not make sense in an unstructured public environment where the “authority” is unknown and their vouch means nothing.|
|↑3||If you’re running your own web services, for example a web-interface to your wifi router or a server or some other device with a web interface, it will probably use a self-signed cert and you’ve probably gotten used to clicking through the warnings, which at least diminishes the blackmail value of the browser warnings as people get used to ignoring them. Installing certificates in Firefox is pretty easy. It is a major hassle in Chrome or IE (because Chrome, awesome work Google, great job, uses IE’s certificate store, at least on Windows). Self-signed certs are used everywhere in IT management, almost all web-interfaced equipment uses them. IBM has a fairly concise description of how to install the certs. Firefox wins.|
The certificate system is badly broken on a couple of levels and the most recent revelation that Turktrust accidentally issued two intermediate SSL CAs which enabled the recipients to issue presumptively valid arbitrary certificates. This is just the most recent (probably the most recent, this seems to happen a lot) compromise in a disastrously flawed system including the recent Diginotar and Comodo attacks. There are 650 root CAs that can issue certs, including some CA‘s operated by governments with potentially conflicting political interests or poor human rights records and your browser probably trusts most or all completely by default.
It is useful to think about what we use SSL certs for:
- Establishing an encrypted link between our network client and a remote server to foil eavesdropping and surveillance.
- To verify that the remote server is who we believe it to be.
Encryption is by far the most important, so much more important than verification that verification is almost irrelevant, and fundamental flaws with verification in the current CA system make even trying to enforce verification almost pointless. Most users have no idea what what any of the cryptic (no pun intended) and increasingly annoying alerts warning of “unvalidated certs” mean or even what SSL is.
Google recently started rejecting self-signed certs when attempting to establish an SSL encrypted POP connection via Gmail, an idiotically counterproductive move that will only make the internet less secure by forcing individual mail servers to connect unencrypted. And this is from the company who’s cert management between their round-robin servers is a total nightmare and there’s no practical way to ever be sure if a connection has been MITMed or not as certs come randomly from any number of registrars and change constantly.
What I find most annoying is that the extraordinary protective value of SSL encrypted communication is systematically undermined by browsers like Firefox in an intrinsically useless effort to convince users to care about verification. I have never, not once, ever not clicked through SSL warnings. And even though I often access web sites from areas that are suspected of occasionally attempting to infiltrate dissident organizations with MITM attacks, I still have yet to see a legit MITM attack in the wild myself. But I do know for sure that without SSL encryption my passwords would be compromised. Encryption really matters and is really important to keeping communication secure; anything that adds friction to encryption should be rejected. Verification would be nice if it worked.
Self-signed certs and community verified certs (like CAcert.org) should be accepted without any warnings that might slow down a user at all so that all websites, even non-commercial or personal ones, have as little disincentive to adding encryption as possible. HTTPSEverywhere, damnit. Routers should be configured to block non-SSL traffic (and HTML email, but that’s another rant. Get off my lawn.)
Verification is unsolvable with SSL certs for a couple of reason, some due to the current model, some due to reasonable human behavior, some due to relatively legitimate law-enforcement concerns, but mostly because absolute remote verification is probably an intractable problem.
Even at a well run notary, human error is likely to occur. A simple typo can, because registrar certs are by default trusted globally, compromise anyone in the world. One simple mistake and everybody is at risk. Pinning does not actually reduce this risk as breaks have so far been from generally well regarded notaries, though rapid response to discovered breaches can limit the damage. Tools like Convergence, Perspectives, and CrossBear could mitigate the problem, but only if they have sufficiently few false positives that people pay attention to the warnings and are built in by default.
But even if issuance were somehow fixed with teams of on-the-ground inspectors and biometrics and colonoscopies, it wouldn’t necessarily help. Most people would happily click through to www.bankomerica.com without thinking twice. Indeed, as companies may have purchased almost every spelling variation and point them all toward their “most reasonable” domain name, it isn’t unreasonable to do so. If bankomerica.com asked for a cert in Ubeki-beki-beki-stan-stan, would they (or even should they) be denied? No – valid green bar, invalid site. Even if misdirections were non-SSL encrypted, it isn’t practical to typo-test every legit URL against every possible fake, and the vast majority of users would never notice if their usual bank site came up unencrypted one day with a DNS attack to a site not even pretending to fake a cert (in fact, studies suggest that no users would notice). This user limitation fundamentally obviates the value of certs for identifying sites. But even a typo-misdirection is assuming too much of the user – all of my phishing spam uses brand names in anchortext leading to completely random URLs, rarely even reflective of the cover story, and the volume of such spam suggests this is a perfectly viable attack. Verification attacks don’t even need to go to a vaguely similar domain let alone go to all the trouble of attacking SSL.
One would hope that dissidents or political activists in democracy challenged environments that may be subject to MITM attacks might actually pay attention to cert errors or use perspectives, convergence, or crossbear. User education should help, but in the end you can’t really solve the stupid user problem with technology. If people will send bank details to Nigeria so that a nationality abandoned astronaut can expatriate his back pay, there is no way to educate them on the difference between https://www.bankofamerica.com and http://www.bankomerica.com. The only useful path is to SSL encrypt all sites and try to verify them via a distributed trust mechanism as implemented by GPG (explicit chain of trust), Perspectives (wisdom of the masses), or Convergence (consensus of representatives); all of these seem infinitely more reliable than trusting any certificate registry, whether national or commercial and as a bonus they escape the cert mafia by obviating the need for a central authority and the overhead entailed; but this only works if these tools have more valid positives than false positives, which is currently far from the case.
Further, law enforcement makes plausible arguments for requiring invisible access to communication. Ignoring the problematic but understandable preference for push-button access without review and presuming that sufficient legal barriers are in place to ensure such capabilities protect the innocent and are only used for good, it is not rational to believe that law enforcement will elect to give up on demanding lawful intercept capabilities wherever possible. Such intercept is currently enabled by law enforcement certificates which permit authorized MITM attacks to capture encrypted data without tipping off the target of the investigation. Of course, if the US has the tool, every other country wants it too. Sooner or later, even with the best vetting, there is a regime change and control of such tools falls into nefarious hands (much like any data you entrust to a cloud service will sooner or later be sold off in an asset auction to whoever can scrape some residual value out of your data under whatever terms suit them, but that too is a different rant). Thus it is not reasonable for activists in democracy challenged environments to assume that SSL certs are a secure way to ensure their data is not being surveilled. Changing the model from intrinsic, automatic trust of authority to a web-of-trust model would substantially mitigate the risk of lawful intercept certs falling into the wrong hands, though also making such certs useless or far harder to implement.
There is no perfect answer to verification because remote authentication is Really Hard. You have to trust someone as a proxy and the current model is to trust all or most of the random, faceless, profit or nefarious motive driven certificate authorities. Where verification cannot be quickly made and is essential to security, out of band verification is the only effective mechanism such as transmitting a hash or fingerprint of the target’s cryptographic certificate via voice or postal mail or perhaps via public key cryptography.
Sadly, the effort to prop up SSL as a verification mechanism has been made at the compromise of widespread, low friction encryption. False security is being promoted at the expense of real security.
That’s just stupid.
- South Lake Tahoe Caldor Fire Timelapse
- Save your email! Avoid the Thunderbird 78 update
- Compile and install Digikam on Ubuntu 20.04 Focal
- Tagging MP3 Files with Puddletag on Linux Mint
- Never put important data on anyone else’s hardware. Ever.
- EZ rsync cheat sheet
- Favicon generation script
- CoreELEC/Kodi on a Cheap S905x Box
- WebP and SVG
- Dealing with Apple Branded HEIF .HEIC files on Linux
- Recent Comments
- Post History
September 2021 M T W T F S S 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30