SSL

The CA System is Intractably Broken

Tuesday, July 21, 2015 

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.

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.

Posted at 00:53:59 GMT-0700

Category: FreeBSDPrivacySecuritytechnology

Making Chrome Less Horrible

Saturday, June 13, 2015 

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.

It is a private network, you idiots

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.
  • etc.

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 “--ignore-certificate-errors

Unfuck chrome a bit.

Once you’ve done this, chrome will open with a warning:

zomg: ignore certificate errors?  who doesn't anyway?

YAY.  Suffer my ass.

Java?  What happened to Java?

Bonus rant

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 “enable.”

Enable NAPI

Posted at 13:24:37 GMT-0700

Category: HowToSecuritytechnology

Superfish proves certs are useless for identification

Saturday, February 21, 2015 

Can we please, please stop with the stupid certificate verification warnings?

superfish logo

Dear security developers, your model is broken. It never worked. Stop warning people about certificate errors. Now. Forever.

Certificate errors serve two purposes:

  1. They make developers uncomfortable with using perfectly secure self-signed certs, and since commercial certs cost money, much of the web that could be encrypted remains unencrypted. That’s harm done to the public. Thanks.
  2. They happen so often, so relentlessly, for such trivial reasons (not even Google can keep their certs up to date) that users learn to ignore them, which makes an actual man-in-the-middle attack almost certain to succeed with most people, despite the warnings.

The Certificate Authority system is predicated on the idea that Certificate Authorities are flawless and trustworthy. They are neither. The Lenovo/Superfish problem shows another obvious flaw: hardware vendors (and actually any trusted software installer) has to be trustworthy too or client-side MITM is easy. And CA’s simply can’t verify against that.

This whole idiocy creates massive problems for something so basic as LAN administration. Even before wireless became pervasive, LAN coms should always be encrypted when passwords or any meaningful data is moving. Current security settings create a massive avalanche of useless errors for “untrustworthy certs” on one’s own network (the obvious fix is to automatically trust all certs on private networks, duh).

This is an issue that bothers me a lot. It gets in my way constantly and makes real security and encrypted communications way harder and way more complicated than it needs to be and the only beneficiaries at all are the certificate Mafiosi. This is just stupid. Superfish proves, again, how broken it is. Can we stop pretending now?

Also, this most recent of many certificate flaws comes with a bonus feature: the MITM cert Superfish uses is apparently really pathetically insecure, aside from using broken crypto, their software had their passwords in it, making it easy for crackers to develop tools to harvest additional data from the victims of the Superfish/Lenovo attack.It probably hurts more to find out your vendor hacked you, but the penalty is that the hack also destroyed the security of all of your communications. Thanks. This is why we can’t have nice things. It is also why any back door, no matter what the motive, compromises security.


 

Update: Superfish is, apparently, out of business.  While that sucks for the people at the company, who were probably very happy with their Lenovo OEM deal and instead got a big sock of coal, one might naively hope for an upside that companies considering a model based on stealing people’s data might take notice of the cautionary tale of superfish.

Unfortunately – that won’t happen, not in the current valley climate. While it is economically advantageous to hire cheap kids who have no life and will work long hours for meagre pay, they come with a downside: they are all ignorant idiots. I don’t mean they’re not smart or capable (though the smart barrel was long ago drained and the vast majority of brogrammers sauntering around SF really are stupid), rather that they are foolish as in the opposite of ‘wise.”  Wisdom comes from experience, and experience only comes with time, an immutable dimension.  This superfish debacle was only from Feb 2015, but this year’s batch of idiot brogrammers weren’t around to see it and as they gather in self-congratulatory clusters in posh, VC-funded collaborative spaces, company barrista-brewed latte in one hand and social-media-distraction feeding portable device in the other, they’ll be high-fiveing and fist-bumping the brilliance of their brand-new idea for getting around SSL so they can collect marketing data and better target advertising.  Yay.


 

How to fix Superfish:

Install Perspectives. And support them.

Also, this bugs the crap out of me:

Overthrow the Cert Mafia!

SSL for Authentication Sucks

Unbreaking Firefox SSL Behavior

The CA System is Intractably Broken

Posted at 02:45:41 GMT-0700

Category: Securitytechnology

SSL for Authentication Sucks

Wednesday, November 26, 2014 

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.

And, of course, agitate for rationality: Perspectives and the CACert root should ship with every browser install.

Footnotes   [ + ]

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.
Posted at 15:50:20 GMT-0700

Category: technology

Xabber now uses Orbot: OTR+Tor

Sunday, November 3, 2013 

As of Sept 30 2013, Xabber added Orbot support. This is a huge win for chat security. (Gibberbot has done this for a long time, but it isn’t as user-friendly or pretty as Xabber and it is hard to convince people to use it).

The combination of Xabber and Orbot solves the three most critical problems in chat privacy: obscuring what you say via message encryption, obscuring who you’re talking to via transport encryption, and obscuring what servers to subpoena for at least the last information by onion routing. OTR solves the first and Tor fixes the last two (SSL solves the middle one too, though Tor has a fairly secure SSL ciphersuite, who knows what that random SSL-enabled chat server uses – “none?”)

There’s a fly in the ointment of all this crypto: we’ve recently learned a few entirely predictable (and predicted) things about how communications are monitored:

1) All communications are captured and stored indefinitely. Nothing is ephemeral; neither a phone conversation nor an email, nor the web sites you visit. It is all stored and indexed should somebody sometime in the future decide that your actions are immoral or illegal or insidious or insufficiently respectful this record may be used to prove your guilt or otherwise tag you for punishment; who knows what clever future algorithms will be used in concert with big data and cloud services to identify and segregate the optimal scapegoat population for whatever political crises is thus most expediently deflected. Therefore, when you encrypt a conversation it has to be safe not just against current cryptanalytic attacks, but against those that might emerge before the sins of the present are sufficiently in the past to exceed the limitations of whatever entity is enforcing whatever rules. A lifetime is probably a safe bet. YMMV.

2) Those that specialize in snooping at the national scale have tools that aren’t available to the academic community and there are cryptanalytic attacks of unknown efficacy against some or all of the current cryptographic protocols. I heard someone who should know better poo poo the idea that the NSA might have better cryptographers than the commercial world because the commercial world pays better, as if the obsessive brilliance that defines a world-class cryptographer is motivated by remuneration. Not.

But you can still do better than nothing while understanding that a vulnerability to the NSA isn’t likely to be an issue for many, though if PRISM access is already being disseminated downstream to the DEA, it is only a matter of time before politically affiliated hate groups are trolling emails looking for evidence of moral turpitude with which to tar the unfaithful. Any complacency that might be engendered by not being a terrorist may be short lived. Enjoy it while it lasts.

And thus (assuming you have an Android device) you can download Xabber and Orbot. Xabber supports real OTR, not the fake-we-stole-your-acronym-for-our-marketing-good-luck-suing-us “OTR” that Google hugger-muggers and caromshotts you into believing your chats are ephemeral with (of course they and all their intelligence and commercial data mining partners store your chats, they just make it harder for your SO to read your flirty transgressions). Real OTR is a fairly strong, cryptographically secured protocol that transparently and securely negotiates a cryptographic key to secure each chat, which you never know and which is lost forever when the chat is over. There’s no open community way to recover your chat (that is, the NSA might be able to but we can’t). Sure, your chat partner can screen shot or copy-pasta the chat, but if you trust the person you’re chatting with and you aren’t a target of the NSA or DEA, your chat is probably secure.

But there’s still a flaw. You’re probably using Google. So anyone can just go to Google and ask them who you were chatting with, for how long, and about how many words you exchanged. The content is lost, but there’s a lot of meta-data there to play with.

So don’t use gchat if you care about that. It isn’t that hard to set up a chat server.

But maybe you’re a little concerned that your ISP not know who you’re chatting with. Given that your ISP (at the local or national level) might have a bluecoat device and could easily be man-in-the-middling every user on their network simultaneously, you might have reason to doubt Google’s SSL connection. While OTR still protects the content of your chat, an inexpensive bluecoat device renders the meta information visible to whoever along your coms path has bought one. This is where Tor comes in. While Google will still know (you’re still using Google even after they lied to you about PRISM and said, in court, that nobody using Gmail has any reasonable expectation of privacy?) your ISP (commercial or national) is going to have a very hard time figuring out that you’re even talking to Google, let alone with whom. Even the fact that you’re using chat is obscured.

So give Xabber a try. Check out Orbot, the effortless way to run it over Tor. And look into alternatives to cloud providers for everything you do.

Posted at 08:50:47 GMT-0700

Category: FreeBSDself-publishingtechnology

Overthrow the Cert Mafia!

Friday, January 4, 2013 

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.
cert_stupidity_google_perspectives.JPG
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.

no secure encryption unless you pay the cert mafia

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.

Akamai certs error har har.JPG

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.

cert_stupidity_google.JPG

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.

cert_stupidity_google_cross_bear.JPG

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.

Posted at 15:18:25 GMT-0700

Category: technology

TLS 1.0 Hatin’ the Game

Wednesday, June 1, 2011 

After much reading and interpreting, it became clear there was no more advice for configuration variations to get client cert login working. It seemed Chrome was doing it right, IE not even trying, and Firefox failing. No advice as to why and setting LogLevel to debug didn’t add much in the way of useful hints.

TLS_bad.JPG

Jared Davenport, for reasons that would never have occurred to me, tried turning off TLS 1.0 in firefox as an allowed protocol. PCI compliance requires turning off a bunch of weaker/compromised protocols and ciphers anyway, so I already had:

SSLProtocol -ALL +SSLv3 +TLSv1

A quick test of

SSLProtocol -ALL +SSLv3

solved the problem with firefox. IE still refuses to talk to SSL, but IE is a stupidhead anyway. OK, it annoys me as the same client cert works on CACert.org’s site so something there is working right that isn’t on my box, but as I never use IE, I think I can let it go

no_tls_good.JPG
Posted at 01:21:25 GMT-0700

Category: FreeBSDLinux

Awesome SSL client cert fun

Tuesday, May 31, 2011 

Client cert authentication is oddly elusive given the practical value. I found a neat bug:

with
SSLVerifyClient optional
SSLVerifyDepth 3
SSLCADNRequestPath /usr/local/openssl/certs/clientcerts/

I get a request for identification in firefox, no problem. If I choose the right certificate to respond with I get an instant child pid 61501 exit signal Bus error (10). Every click on the “OK” button gets another seg fault. Yay. Magic.

client_cert.jpg

signal_bus_error.jpg
Posted at 00:36:09 GMT-0700

Category: FreeBSDtechnology

Unbreaking FireFox SSL Behavior

Sunday, January 24, 2010 

I used to love firefox, but then somebody decided that users were way too stupid to make it through web browsing without an endless parade of  warnings about SSL certs.  The premise seems to be that:

  • Valid certs are meaningful.
  • Self-Signed or expired certs are indicative of a problem.

Neither is true.

(To a statistical certainty.  Some user somewhere will be validly warned away from a phishing site someday.)

Valid certs mean next to nothing since the users that these warnings are targeted to (and me too) will never ever notice if they’re going to bankofamerica.com (or whatever BofA’s legitimate URL is) or bankomerica.com (assuming bankomerica isn’t a valid bank of america domain).  Thus bankomerica can dupe bankofamerica’s website and get a perfectly valid cert and if users were dumb enough to believe that a lack of warnings indicated validity as the huge scary warnings effectively convey, then they’d be easy prey.

The only valid purpose of SSL is to secure communication between a server and a client so you can check your web mail at a cafe without worrying about being snooped and a self-signed cert does that just as well as one issued by the cert mafia.  Sure, sure the giant cert authorities would love to take your $1,000 a year to give a your user’s some sort of guarantee that you’re really who you say you are, but that doesn’t make any difference at all in practice.

As for DNS hijacking so amazon.com goes to a spoof site where the transaction security is compromised (and in theory the self-signed cert would be a give-away) just mod-rewrite to http then redirect to amazoncheck0utservices.com and get a valid cert for it.

Besides, after users have been forced to dismiss a zillion intra-net “invalid” certs, they’ve learned to completely ignore the warnings and so automatically click through the scary and almost always pointless warnings FireFox generates. Or, like many people, users stop abandon the scary, irritating browser and go back to IE.  Win.  Oh wait… FAIL.

Secure DNSSEC is smart, but forget warning people into oblivion over self-signed certs, the net effect is to make the web less secure because site admins have to choose between absurd fees for certs or turning certs off.  Until FireFox fixes this counterproductive behavior, there are two things that help.  First, browse to about:config and set browser.ssl_override_behavior to “2”.

FIX SSL config in FireFox

I’ve also found the Persepectives Plugin useful to reduce the number of pointless and irritating error warnings Firefox generates when it sees a cert that hasn’t fully paid up the protection racket extortion fees by using a polling mechanism, effectively saying (to a collection of referee sites) “ya’ll think this cert is ok?” and if they say “yeah…” then you get no error.

Perspectives_plugin

There fixes are helpful for those of us sufficiently skilled to use them, but unfortunately they won’t prevent users abandoning the endlessly “WOLF!” crying FireFox for IE.

Posted at 19:18:52 GMT-0700

Category: technology

26c3 Berlin

Thursday, December 31, 2009 

26c3 was a blast, as was Berlin. It’s a good conference in the olde school hacker style: mostly younger people, mostly wearing black. There weren’t a lot of women, but Carolyn, Isabella, and Meredith tried to even out the ratio a bit.

Some of the best lectures included one by some German engineers working on the lunar x-prize. They had their prototype rover with them and gave a great talk about the various challenges.

Another great one was Dan Kaminski’s talk on PKI. I don’t agree with the premise that SSL should be a reliable method for identifying the owners of websites as people just can’t tell the difference between bankofamerica.com and bancomerica.com and so it doesn’t make anyone safer if the bankofamerica site is super green if bancomerica.com is also super green, and so the complexities of getting an accepted certificate simply reduce the use of secure connections and the overall security of the internet. But he had some pretty great attacks on the security of SSL that causes problems no matter what.

We enjoyed fuzzing the phone as well. It was a very entertaining talk on attacking phones with crafted SMSes. The method of creating the attacks was very clever – rooting the phone, redirecting the radio to a wifi link to a CPU so they could try zillions of SMS and see what would happen. In the process they discovered they could remotely root the communications manager (which runs as root). And %n to specific windows phones and they’ll crash and fail to reboot until the SMS is cleared out of the inbox.

Berlin is a great city and it was fun working in the shadow of the TV tower.

We made reservations for lunch but we could tell it wasn’t going to be a great day. In the end it was a very intimate lunch with pretty clouds pressing against the glass.

The fog lifted but was replaced by snow, which is a lot of fun in a city when you don’t have to drive.

IMG00220-20091228-0842.jpg

IMG00224-20091229-1405.jpg

IMG00225-20091229-1438.jpg

IMG00226-20091230-1303.jpg

IMG00230-20091230-1653.jpg

IMG00214-20091228-0802.jpg
Posted at 11:42:34 GMT-0700

Category: cell phonesEventsFreeBSDLinuxphotoplacestechnologytravelweather