In the current state of the world, we're all dependent on CA signatures for each connection we make to a website. TACK is a layer of indirection away from CA certificates, such that we'd only be dependent on CA signatures the very first time we contacted a website. It doesn't introduce any new authorities or change the default UX at all.
After the Comodo breaches a few years ago, I put together a talk about these types of attacks, where the fundamental problems lie, and why approaches like DANE are similarly ineffective:
If you don't pay much attention to how TLS works, you should know that NSA (presumably) does not have a magic ability to inject new certs into your root cert repository. If you remove every CA cert from your browser and selectively allow certs, they can't MITM that. The CAs aren't baked into TLS! They're a software configuration detail. And when MITM certs appear on the wire, for them to be honored, they have to somehow chain to a specific CA.
What things like pinning and TACK do is give us the opportunity to discover MITM certificates and start tracing them. If that capability becomes widespread enough, it can potentially foreclose on dragnet TLS MITM attacks, because there will be too much of a risk that deploying a dragnet MITM net will result in the death penalty for the implicated CA.
TACK (and the related efforts) are hugely more important than I think most people think they are. If you want to advocate for something in the wake of the NSA debacle, I think TACK is a great choice.
Unfortunately, ditching the root CAs is way harder than it should be, and flat out impossible in a lot of environments. Compulsory trust isn't trust.
The question I have then is, what happen if look at TACK as an IDS. What is its false positive rate? Can it be lowered? Maybe it should inform the website owner as a way to inform both side of the communication that something eerie is happening.
Let's say that the NSA would like to track bitcoin transactions through MtGox. I don't know how easy it would be for them to plug a backdoor into a server in Japan, and let's assume that the NSA can't break the RC4 crypto their web server is configured to use ..
Since MtGox uses Google Analytics, and possibly pull other scripts from Google's CDN, they could either eavesdrop on whatever data comes back from them by default -- or insist that changes are made to ... pick up more.
Analytics, however, will remain something I'm not overly fond of. For many sites it's unnecessary. For others it's something they could nearly just as easily license and deploy to their own servers. Pulling scripts in from Google Analytics, Statcounter and others -- and especially into privacy concerned apps -- is downright irresponsible.
As I noted here: https://2x.io/read/would-the-nsa-infiltrate-cdns-to-circumve..., even Norway's tax returns site (which hosts info I'd rather not have in any foreign company's hands) use external analytic scripts. They and 90% of the rest of the internet.
No wonder the NSA claim they can circumvent most HTTPS encryption.
I'm curious who build that? Can they not count the filed docs.
As part of my Matasano internship, I've been working on a patch to NSS (Mozilla's crypto library, used by both Firefox and Chrome for TLS) that will give the necessary hooks needed for browsers that use NSS to implement TACK. I'll hopefully be submitting that for review soon (you can see it on bugzilla and fresher in-progress GitHub).
At this point, it mostly makes sense for me to finish that (though I'll have a lot less time when I go back to school, so there might be some work that needs to get done when the review comments come back that I can't get to for awhile, so someone to power that to the finish might be helpful).
But once that's in, we'll need to work on getting patches into the Firefox and Chrome that actually integrate TACK. There's also some other work to do, especially for some other longterm ideas we have (eg. securing communication between mail servers with TACK).
If you're interested in helping, either email Trevor (email is on his website), or email me (danielj@matasano for the next week, personal email in my profile).
"I generally do not connect to web sites from my own machine, aside from a few sites I have some special relationship with. I fetch web pages from other sites by sending mail to a program (see git://git.gnu.org/womb/hacks.git) that fetches them, much like wget, and then mails them back to me. Then I look at them using a web browser, unless it is easy to see the text in the HTML page directly. I usually try lynx first, then a graphical browser if the page needs it.
I also browse from other people's computers, with their permission. Since I don't identify myself to the sites I visit, this browsing can't be connected with me.
One consequence of this method is that most of the surveillance methods used on the Internet can't see me.
Another consequence is that I never pay for anything on the Web. Anything on the net that requires payment, I don't do.
I would not mind paying for a copy of an e-book or music recording on the Internet if I could do so anonymously, and it were ethical in other ways (no DRM or EULA). But that option almost never exists. I keep looking for ways to make it happen."
Also, how does TACK relate to certificate pinning? The introduction has a few differences (e.g. tack expiration), but the two techniques seem pretty similar, am I missing something?
Regarding certificate pinning: TACK is a different "style" of pinning, it lets you pin to a self-managed signing key instead of certificate keys. So it gives you more control and security than CA pinning, if you're willing to assume more key management responsibilities (storing a TACK private key, and using it to sign new TLS keys).
I think there's room for both approaches: I'd like to see CA pinning be made easy enough that most sites could deploy a fairly safe, simple pin to popular CAs, while high-security sites make use of TACK pins.
But we'll see how things go.
I will read the spec for more information (e.g. what prevents the MITM from becoming my CA?) but it sounds very interesting, thanks again.
The "pin activation" algorithm is intended to make it difficult for a MITM to foist bad pins on clients, and to limit the lifetime of such pins.
It's not a big deal to rebuild nginx/apache but I would think that getting TACK to ship default with OpenSSL would go a long way in getting more adoption.
It will hopefully appear in OpenSSL 1.0.2. We'll be submitting Apache patches for it shortly. Daniel Jackoway (in this thread somewhere) is working on the NSS (client-side) corollary.
TACK is certainly a must-have and I'm really looking forward it being a native part of browsers, but there will still be likely a lot of (high-profile) websites that won't play along :-/
Now that you mentioned it, are those safe from say a government agency having access to the companies that serve as certificate authorities? Or is it all a house of cards, as it is now?
Which is why nothing serious happens to Comodo and Verisign when they get hacked: anybody knowledgeable is already aware that a certificate means very little on its own, and we can't stop the internet anyway, so hey, life goes on.
An attacker who is able to sit in the middle with their own trusted cert is simply going to not bother passing the stapled OCSP response along. The victims browser will do an OCSP lookup (or not...) for the trusted cert the attacker provided, and that will succeed.
I'm not sure how OCSP caching is implemented in the browsers that implement OCSP in the first place (is there a spec for caching?), but as it's a method for checking the revocation status of certs, it can't be cached long.
openssl test reports
OCSP Response Status: successful (0x0)
Cert Status: good
This Update: Sep 8 xx:xx:xx 2013 GMT
Next Update: Sep 10 xx:xx:xx 2013 GMT
Not Before: Aug 22 xx:xx:xx 2013 GMT
Not After : Oct 2 xx:xx:xx 2013 GMT
NSA in their eagerness to do rampant spying on everyone have had quite some collateral. They have decided to compromise the one thing which allows us to communicate securely on the internet: trust.
Right now we need to find out which (root?) CAs are compromised by the NSA. Long term it would probably be a very wise decision to revoke any US-based CA from the default trusted-list of browsers and OSes.
We cannot have untrustworthy CAs in a system based on trust. That's simply not an option.
Edit: As I've been pondering for a while (and which was also pointed out on reddit) we now have a situation where self-signed certs are more secure than CA-issued ones. They are the only ones you know can't be faked. How backwards is that?
The NSA is ruining the internet one piece at a time. The NSA needs to be dismantled.
Note that the associated bug is private (https://code.google.com/p/chromium/issues/detail?id=173460).
There's a good explanation of the "bad_static_spki_hashes" parameter here: http://ritter.vg/blog-cas_and_pinning.html
Because strong encryption can be so effective, classified N.S.A. documents make clear, the agency’s success depends on working with Internet companies — by getting their voluntary collaboration, forcing their cooperation with court orders or surreptitiously stealing their encryption keys or altering their software or hardware.
N.S.A. documents show that the agency maintains an internal database of encryption keys for specific commercial products, called a Key Provisioning Service, which can automatically decode many messages. If the necessary key is not in the collection, a request goes to the separate Key Recovery Service, which tries to obtain it.
How keys are acquired is shrouded in secrecy, but independent cryptographers say many are probably collected by hacking into companies’ computer servers, where they are stored. To keep such methods secret, the N.S.A. shares decrypted messages with other agencies only if the keys could have been acquired through legal means. “Approval to release to non-Sigint agencies,” a GCHQ document says, “will depend on there being a proven non-Sigint method of acquiring keys.”
Sounds like there are plenty of possibilities: they have agents working at verisign/they broke into verisign (either physically or electronically)/they just asked and verisign said ok/they used legal processes.
They used a secret legal process. There, fixed that one for you!
Quoting Julian Assange: I have been told actually that VeriSign... has actually given keys to the US government. Not all, but a particular key.
> We cannot have untrustworthy CAs in a system based on trust. That's simply not an option.
The entire CA trust model is broken. In the trust model, any CA can issue certs for any domain; so a Chinese CA could issue Google certs, or a US CA could issue certs for the Dutch government.
Self-signed certs with certificate pinning are indeed more likely to be secure than CA certs. Of course, you can do both; CA signed certs (which does add a small amount of trustworthiness, as the CA is at least supposed to do a little work to verify a real-world identity), and use certificate pinning to avoid this kind of attack.
The only advice if any of it were true would be to scrap it all and start over. Scrap multiple decades of work by really smart people due to a few "bad seeds" being planted during the harvest? Unfortunately that's the only true remedy unless someone can really unwind the rootkit in our lives that is the NSA. It's an analogy of a computer being infected with a virus. Do we try to go back to a backup we hope isn't compromised or do we reformat and start over? We're all trying the former because I don't think anyone really has a grasp on or even wants to think about the latter (I certainly don't).
Given that basically all CAs people actually use (even in Europe) are owned by US companies, I would estimate something close to 100% of them have cooperated with the NSA at some point. Obviously there are non-US CAs like China's CNNIC but most of them won't actually sell you a certificate.
I wrote a semiparanoid rant about this a couple of days ago ... but didn't think I'd be this close to the truth.
This means that The Netherlands was a high-level target with Diginotar, and they hit the frickin' jackpot.
Just for reference, read this: http://nl.wikipedia.org/wiki/Hack_bij_DigiNotar
The Diginotar hack basically exposed all of the information about the Dutch that NSA could ever want to digg through: Information about licenseplates (RDW) Tax info (DigiD) Phone records (OPTA) and the complete dutch encrypted government infrastructure (PKI Overheid)
Let's see what traction this new info will get now in The Netherlands...
Although the NSA certainly has reason to spy on Iran, why risk discovery this way? They can legally compel Google to give them the email of foreigners in a foreign country.
So maybe NSA had DigiNotar's key, but the hack that shut it down was done by someone else.
> They can legally compel Google to give them the email of foreigners in a foreign country.
They can, but they may wish to be more subtle than that. For example, if they were engaged in economic espionage, they might not want that story to break, and would be worried that someone at Google may leak the story. If they had to ask Google, there would be more people who would know about what's going on.
The NSA, on the other hand, would prefer there to be no audit trail so there's no evidence of the inevitable abuses.
They likely have the access to all the data they want. They use the legal vectors for requests just to see what the companies would give them on the request, and can compare the difference between the provided data vs the slurped data.
Moxie Marlinspike and others have been talking about this for years. Its a recognized problem, and thats why apps that are serious about protecting communications have been moving to a pinning model.
Obviously this sucks at the browser level, though Chrome protect does this with Google properties (and others?) at the CA level now, but at the app level it's very doable and should be something you're implementing.
Also see Moxie's comment in this very thread. 
Schneier's credibility makes a lot of difference.
Large-scale MITM attacks, i.e. ones against a huge section of the population, really have a lot of disadvantages. First, there are always cautious people who check certs religiously, sometimes with browser addons to help (in fact I see that peterwwillis linked to some below). So, if you execute a large-scale MITM effort, you run the risk of being discovered. Note that if the NSA can compel Google to turn over its secret key(s), this isn't an issue, but I am operating under the assumption that we don't want to give away our MITMing easily.
Second, broad MITMs require a lot of resources to be effective. To MITM all of Google's traffic requires network capacity equivalent to Google's, no small thing (though I suspect very much within the power of the NSA if it were deemed necessary). There's a lot of data on the internet at any one time.
Third, the fact that you must have physical servers on physical networks sitting between Google and the target means that the MITM server's IP address will be the one that targeted clients appear under. That is, if you have a single server MITMing thousands of requests, all of them will appear from the same IP address. That's another risk of being discovered if the MITM is too broad and the servers are too beefy. Although, this assumes that people on the other end are doing some sort of analytics --- maybe not true. But intel agencies are pretty paranoid, so whatever.
Fourth, it still pretty much gets the job done anyway, with less cost: passively sniff traffic for, say, DNS requests to resolve suspicious domains, or plaintext connections that have suspicious contents. Passive sniffing requires less computational power than actual MITMs, and it can be done without raising any red flags. Plus, even if you miss someone suspicious, just get a NSL for Google to hand over all the data anyway in the worst case.
Fourth, if an investigation ever were launched about my breaking of TLS, targeted attacks look great. See, we don't target the American people --- only specific connections that are "suspicious" are targeted. Broad-scale MITMs seem very illegal-wiretap-y, but the targeted connections look very legitimate, at least in comparison.
So, these reasons are why I've always held the belief that the government is not executing large-scale MITM/dragnet collection of encrypted communications ... and hence TLS is effective, so long as you're not the one being targeted.
Certificate Patrol (notifies you when certs change) https://addons.mozilla.org/en-us/firefox/addon/certificate-p...
Force-TLS (force websites to always use HTTPS) https://addons.mozilla.org/en-us/firefox/addon/force-tls/
Perspectives (compare certs with peers to verify authenticity) https://addons.mozilla.org/en-us/firefox/addon/perspectives/
In theory yes, but not more than 10 minutes ago Cert Patrol noticed that Amazon have changed the CA for the SSL cert for an image server.
What am I supposed to do? It is interesting info, but if I reject the cert then I can't be sure my connection is secure. If I accept it... I can't be sure my connection isn't MiTMed.
The human factor is always the weak link.
HTTPS Everywhere (preset list of sites to use only HTTPS on) https://www.eff.org/https-everywhere
Safe (shows you when a site might not or isn't using HTTPS) https://addons.mozilla.org/en-US/firefox/addon/safe/
If you want to keep your information private, don't put anything on an internet-connected device that wasn't encrypted on an airgapped computer first.
It seems to me that their intent to be as clandestine as possible makes them distinctly non-terroristic.
Yeah, I'll admit that's an arguable point. I haven't even made up my own mind on the "intent" aspect.
All told, labeling them a "criminal" organization would probably be better, but I think it would be wrong to overlook the role they play in allowing the US government to use fear as a tool of control.
You could call what they do criminal, but it's not terroristic.
> Another screenshot  implies is that the 2011 DigiNotar hack was either the work of the NSA, or exploited by the NSA.
I doubt that those 2 documents are original slides or screenshots from NSA material. They both are written with the familiar rounded font that Globo uses for all its text 
Because in order to pull that MITM off, they either need to have the target service's CA - or they have the ability to fake any certificate. My guess is on the latter.
And that means at least one commonly accepted CA certificate is effectively compromised.
the economy side of things will be fine. the economy of what the internet is used for isn't really the concern, here. arguably, even with rampant MITM attacks going on, e-commerce is loads more secure that what we've had for in place for the past 5,000 years.
this is much more than an economic issue.
1) Chrome(and some plugins) pin's certificates and would notice a man in the middle attack(unless it was done with google's key). Sure, most corporate targets probably use IE, but if anyone uses chrome on or one of these plugins on the network, you've both alerted your target and exposed a presumably tightly guarded ability. Hell, if it get's reported, you've probably burned the ability. Of course, you might be able to filter out both the plugins and chrome, but it's a risk.
2) NSA could legitimately just ask for the company's emails from Google. Petrobras is a Brazilian company in Brazil staffed by Brazilians and as such a legally allowed target for Foreign Surveillance without either the NSA's twisted definitions of search and who is a US national. Google is legally required to hand over the information by the Foreign Intelligence Surveillance Amendment Act of 2008. Why authorize an operation that could reveal both the CA's you have in your pocket and you network penetration exploits?
As a side note, the cited slide looks nothing like anything else we have seen and lack security/ handling information (e.g the prominent TS/SCI/ORCON/NOFORN on the top of the prism slides).
Imagine if some foreign service, that is outside of an NSL's reach, has communication that the NSA wants to snoop on. If they can't break the crypto, but that service happens to load jQuery off of Google's CDN, or use Google Analytics, the NSA could pull a MITM attack and manipulate the content of the requested scripts.
Those scripts could rather easily act as proxies for the NSA or others, and either hijack sessions or pull data straight out of the protected services.
I'm tooting my own horn here, but that's exactly the kind of thing this blog post speculates on: https://2x.io/read/would-the-nsa-infiltrate-cdns-to-circumve...
Unless things changed since I last checked.
In contrast, "real" "certificate pinning" as done in some mobile apps (IIRC Twitter) involves storing the hash of the certificate itself in the app. No other certificate, even from the same CA, will be accepted.
Also, a March 2010 research paper by Christopher Soghoian and Sid Stamm "in which they present evidence that certificate authorities (CAs) may be cooperating with government agencies to help them spy undetected on 'secure' encrypted communications."
More details on that from the EFF but if we assume that the government can obtain Google's private keys then they could almost certainly carry this out undetected, IMO.
I'm not saying NSA doesn't have the ability, just the implication that it was used against Brazil is likely wrong.
That's what I understand as well but I don't think they pin much more than that -- and certainly not every SSL certificate on every site one might connect to.
HOWEVER, there is plenty of other legislation enabling the NSA to spy on non-US parties in different circumstances.
They're merely on the same presentation describing attacks and targets
Which CA did they use to get those certs, they should be obliterated from trust networks.
1 - http://en.wikipedia.org/wiki/Interlock_protocol
It is irresponsible on behalf of the rest of the world to allow this behavior to continue. Maybe after US businesses have experienced enormous economic damages they will change their way.
The easiest way to snoop on all internal company data is to sniff those MPLS links at ISPs.
So... maybe this was only needed or relevant before have direct access ?
Then I understand better the relevance. Thanks.
Encrypt Outbound ==> Decrypt Inbound
at Source at Destination
Decrypt Inbound <== Encrypt Outbound
at Source at Destination
Encrypt Outbound ==> Decrypt/Intercept --> Re-Encrypt ==> Decrypt Inbound
at Source at Attacker at Attacker at Destination
Decrypt Inbound <== Re-Encrypt <-- Decrypt/Intercept <== Encrypt Outbound
at Source at Attacker at Attacker at Destination
Bigger targets are always more interesting for mass surveillance, because, by definition, they have more users.
And that's what the recent revelations are all about: Mass surveillance.
Obviously, bitter targets are also more interesting for private/non-NSA/non-state hackers.
The size of the email provider wouldn't make any difference.
It would be a huge pain in the ass to cover all the smaller providers.
Do you have any idea how many such hardware blackboxes lie between any two locations on the net? All that would be needed is a single vulnerable/backdoored one in that path, configure it to DNAT & SNAT through your MITM host ..
I highly doubt there're very many places out of that reach. Especially not smaller providers.