1. Computer problem? Tech Support Guy is completely free -- paid for by advertisers and donations. Click here to join today! If you're new to Tech Support Guy, we highly recommend that you visit our Guide for New Members.

State subversion of SSL

Discussion in 'Tech-Related News' started by Mumbodog, Apr 15, 2010.

Thread Status:
Not open for further replies.
Advertisement
  1. Mumbodog

    Mumbodog Thread Starter

    Joined:
    Oct 3, 2007
    Messages:
    7,889
    Episode 243



    Christopher Soghoian is a Ph.D. candidate in the School of Informatics and Computing at Indiana University. And he's partnered up with Sid Stamm, S-t-a-m-m, who is a Ph.D., also he got his Ph.D. at IU, currently employed by Mozilla. One of them was at a conference where they saw in sort of the trade show portion of the conference a very disturbing booth from a company called Packet Forensics. Packet Forensics was advertising a little turnkey network appliance which was able to perform SSL man-in-the-middle attacks.

    Now, we know that SSL man-in-the-middle attacks could be pursued based on the previous problem with SSL where renegotiating sessions had a bit of a hole in them, such that it was possible for a man in the middle to perform some little chicanery, but nothing that was of too much concern. Well, these guys put together a 19-page PDF. If our listeners Google "ssl-mitm.pdf," as in man in the middle, "ssl-mitm.pdf," Google will take you to a bunch of instances of this. It's at files.cloudprivacy.net/ssl-mitm.pdf. You can also find it at cryptome.org/ssl-mitm.pdf.


    What this means is that it would be entirely possible for any governmental agency to essentially proxy SSL connections. And if connections are going through some sort of device which is not going to an IP of Google, it just lets them pass. But when it sees that a connection is going to the IP of Google, it proxies that SSL connection, meaning it pretends to be Google, that is, the device does, which it can now do because it has a certificate for Google.com signed by someone our browser trusts. So instead of our connection actually terminating at Google, it terminates at this device.

    Our browser gets a certificate from the device, checks to see if it's a trusted - if it's been signed by someone it trusts. It has been because it's been signed, not by VeriSign, but any of a number of these hundreds of certificate authorities, and the browser's happy. Then the device connects to Google.com, and we can't tell the difference.

    If we examined the certificate ourselves, we would see, oh, look, it's been signed by the Hong Kong Post Office. That seems suspicious, that Google would have their certificate signed by the Hong Kong Post Office as opposed to maybe VeriSign. I wouldn't be surprised if that's who Google did have their certificate signed by. I haven't looked. But, you know, that's the nature of this problem. But it's much worse, as I will explain in a second. I wanted to read what these guys have done from their research, or said about the nature of compelled assistance.

    They say, "Many governments routinely compel companies to assist them with surveillance. Telecommunications carriers and Internet Service Providers are frequently required to violate their customers' privacy, providing the government with email communications, telephone calls, search engine records, financial transactions, and geolocation information. In the United States, the legal statutes defining the range of entities that can be compelled to assist in electronic surveillance by law enforcement and foreign intelligence investigators are remarkably broad. Examples of compelled assistance using these statutes include the secure email provider that was required to place a covert backdoor in its product in order to steal users' encryption keys" - and there's a reference here to this in this document, so, I mean, they back all this up with references - "and a consumer electronics company that was forced to remotely enable the microphones in a suspect's automobile dashboard GPS navigation unit in order to covertly record the conversations being held in their car. Outside the United States and other democratic countries, specific statutory authority may be even less important."

    LEO: Do they say who these companies are? Or did they just kind of generically, I mean...

    STEVE: Well, in the references. There's reference no. 18 in the PDF to the second instance and reference no. 2 to the stealing of the email...

    LEO: So who was the consumer electronics company? Who was the email company?

    STEVE: I didn't look. Let me see.

    LEO: I guess we can leave that as an exercise for the reader. But, I mean, it does make one wonder.

    STEVE: Yeah. Well, and I like this because they're raising the point that this has happened. But I have another quote in a second that I'll read.

    LEO: Okay, go ahead.

    STEVE: "The Chinese government, for example, has repeatedly compelled the assistance of telecommunications and technology companies in assisting it with its surveillance efforts. Just as phone companies and email providers can be forced to assist governments in their surveillance efforts, so, too, can SSL Certificate Authorities. The compelled certificate creation attack, which is what these guys have named this, is thus one in which a government agency requires a domestic Certificate Authority to provide it with false SSL certificates for use in surveillance." And I've skipped a bit.

    And then they continue, saying, "When compelling the assistance of a CA, a Certificate Authority, the government agency can either require the CA to issue it a specific certificate for each website to be spoofed; or, more likely, the CA can be forced to issue an intermediate CA certificate that can then be reused an infinite number of times by that government agency without the knowledge or further assistance of the Certificate Authority."

    So just to finish with one quote, and then I want to talk more about the technology. They have a section called "Evidence," where they describe this device and the device's marketing material. And during this conference, one of the authors of this PDF, this research paper, says, "The company's CEO, Victor Oppleman, confirmed in a conversation with the author at the company's booth the claims made in their marketing materials: 'That government customers have compelled certificate authorities into issuing certificates for use in surveillance operations which are used by their hardware.' While Mr. [Oppleman] would not reveal which governments have purchased the 5-series devices, he did confirm that it has been sold both domestically and to foreign customers."

    So the idea that an entity could compel the creation of an intermediate certificate is what is most compelling for me because of what such a capability means when installed into a piece of a hardware. Here's how this works. And what this does is, it allows every single - every single - SSL connection to be eavesdropped on.

    LEO: This is the kind of thing that maybe an ISP might do, a company might do, a school might do. Basically a man-in-the-middle attack.

    STEVE: Well, it wouldn't be a school. It would be, for example, we know, post 9/11 attacks on the United States, that there was extremely broad interpretation of the legal rights of the government to eavesdrop on telecommunications.

    LEO: Although I just saw a news story that Gerald Ford approved warrantless wiretaps in the '70s. So...

    STEVE: Yeah. Well, and remember that a number of telecommunications companies refused to comply.

    LEO: But most did.

    STEVE: But most went along with it. So what we're talking about there, that's an example of the government compelling a company to allow it to eavesdrop on their data flow. So imagine hypothetically that the FBI, by court order, compels a trusted Certificate Authority, any of them, to create an intermediate Certificate Authority certificate. So what that means is that the FBI now owns an intermediate certificate signed by a trusted root Certificate Authority. That intermediate certificate is installed in a device which functions as follows. And say that, for example, this was in an Internet caf. And in fact the brochure for this device says, for example, "This solves the Internet caf problem," as if privacy is a problem in an Internet caf. But, you know, to the spooks it is.

    LEO: A problem for them.

    STEVE: To the three-letter initial people, yes - NSA, CIA, FBI, and so forth. So the way this works is a user somewhere, anywhere, not necessarily in an Internet caf. I don't mean to restrict it. This could be installed in an ISP's facility so that any customer of an ISP working at home initiates a secure connection to anywhere. Anywhere. The packet comes in to this device, to port 443, which is the SSL port. That gives the device the IP that the user is trying to connect to. The device doesn't even have to know what domain this is. And in fact at this point it doesn't know. All it has to do, a SYN packet comes in, trying to initiate an SSL connection. This device sends its own TCP SYN packet to that IP to establish its own connection to wherever the user is connecting to.

    What happens then is that the remote server connected to provides its certificate for the SSL connection to the device, to the client that initiated the connection. Now the client, this device, man-in-the-middle device, has the website's certificate. So it now knows exactly what certificate is expected by the originator of this connection. But it knows that, but now it takes advantage of the fact that it is an authentic intermediate CA to build a certificate which it signs on the fly in order to close, to accept the connection originated by the ISP's customer.

    So the point is, this is a real-time, practical, man-in-the-middle device which, armed with a trusted intermediate CA certificate, is able to decrypt all SSL connections. And no warnings of any sort ever are displayed on the user's browser. And if they looked at the certificate chain, they would see something they would likely see anyway, which is we often now see, for example, intermediate CAs. And if you followed it back, it would be trusted by somebody you trust. So this is an entirely practical attack, practical right now, presumably going on right now, based on the fact that governments have, we believe, compelled certificates to be issued, and hardware exists for the sole purpose of pursuing this sort of attack. And that's all it has to do.

    What I just described is the way this would work. And Microsoft has a PDF document, Leo, which I know you have opened at your end, which is a list of the root certificate program members as of November 24, 2009, so about five months ago, which - and these are the participants in this database that Microsoft maintains. And, you know, there are names. We have the government of Brazil, the government of India, outfit in Spain, Entrust in Canada, Internet Publishing Services in Spain, C-COM Trust Systems in Japan. Another...

    LEO: You've got to figure many, at least a few of these are fronts for national security organizations of various countries. I mean, if I'm the NSA, I'm going to set up a certificate root authority.

    STEVE: Precisely. And you're going to get it installed in the browser.

    LEO: Yeah, under a fake name.

    STEVE: That's a very good point, Leo.

    LEO: And it's done, we're done.

    STEVE: You know, A-Trust in Austria. Bypass, a nice name for one, in Norway.

    LEO: And maybe you trust the NSA. But do you trust, you know, the Spanish security authorities, the Czech Republic security authorities? We don't know who these people are.

    STEVE: Well, and we've been talking...

    LEO: Bulgaria?

    STEVE: We've been talking recently about, yes, exactly, we've been talking recently about China seeming to be behind a number of, well, for example, Google is convinced that China was behind the pervasive attacks against it and a number of other countries. Well, there's a China Internet Network Information Center, CNNIC. They've got a root CA trusted by Windows which is good until 2027.

    LEO: Here's one good through 2037 for the Shanghai Electronic Certification Authority, SHECA.

    STEVE: And we trust, I mean, here's the point, is that all you have to do is get an intermediate certificate signed by one of these organizations. I mean, we're trusting them all. And it means basically everyone listening to this podcast now pretty much needs to assume that at some level these communications are not private. I don't think schools can do this. This is, lord knows, we hope these devices don't get loose and to the point where a school is able to do this. The schools could compel the installation of a certificate in the browsers. So, for example, that's the way the corporate proxies work, where anyone using SSL has to trust the corporate proxy. And that's done by essentially installing the corporate root certificate in the employee's browser. That allows corporations to proxy and monitor SSL connections. But absent that, just using noncorporate, nonemployee browsers, just the browsers we're using now, you need to somehow have the certificates signed by someone you trust.

    Unfortunately, it's very clear now that trust has gone completely out of control. I mean, we're trusting everybody on this list. And all any one of them has to do, I mean, this comes back to what I have pounded on our listeners about, which is the bad news about security is, one mistake is all it takes. The entire chain of trust, the entire fabric of security requires perfection. And so one defect is all it takes. And unfortunately we've got 264 possible sources of defects in the fundamental trust anchorage of SSL communications. And thanks to the fact that there is this notion of intermediate Certificate Authorities, once an intermediate Certificate Authority has been signed by a root Certificate Authority whom we trust, then, as I've just demonstrated, it is possible to create a simple device which is able to eavesdrop on all SSL communications virtually without detection.

    LEO: That's not good.

    STEVE: That's not good.

    LEO: No. So what do we do? I mean, you need certificates. You need root authorities. I mean, even if it were three, even if it were VeriSign and, you know, I mean, it'd still be this issue of them being subverted. As you just said, the government can order them basically to subvert it.

    STEVE: Yes. I mean, exactly. Under court order, the law is such that a company can be compelled to provide what the government wants.

    LEO: We're stuck with it. It's not - what are we going to do?

    STEVE: Yes. It is anchored, it is literally rooted in our trusting of the people that sign the certificates for our web servers and who sign the intermediate certificates. Unfortunately, it's become so popular that everybody wants in on signing. In this document these guys explain that it's reasonable that, for example, some country that uses PKI-signed national ID cards might not want to outsource the signing of their ID cards to some other organization. So they set up their own root CA and convince Microsoft and Apple and Mozilla to trust their root CA. And here of course the problem is the weaker it gets, the weaker it becomes because they're able now to say, well, look at everybody else you trust. Why don't you trust Squamzilla? And it's like, now we've got 264 people that Windows trusts. I mean, literally, anyone you could imagine is on this list.
     
  2. indianacarnie

    indianacarnie

    Joined:
    Nov 24, 2009
    Messages:
    191
    now that is truly scary!!!! i wonder why this has not been more widely reported?
     
  3. Mumbodog

    Mumbodog Thread Starter

    Joined:
    Oct 3, 2007
    Messages:
    7,889
    Yep, they have keys to the Kingdom now.

    Most people don't care about that kind of news, I am sure some news outlet will report on it in the next week or so.

    .
     
  4. tomdkat

    tomdkat Retired Trusted Advisor

    Joined:
    May 6, 2006
    Messages:
    7,148
    I'm floored. This really and truly does suck. Where did you find this transcript?

    Peace...
     
  5. Mumbodog

    Mumbodog Thread Starter

    Joined:
    Oct 3, 2007
    Messages:
    7,889
  6. tomdkat

    tomdkat Retired Trusted Advisor

    Joined:
    May 6, 2006
    Messages:
    7,148
    Thanks! (y)

    Peace...
     
  7. Mumbodog

    Mumbodog Thread Starter

    Joined:
    Oct 3, 2007
    Messages:
    7,889
  8. Sponsor

As Seen On
As Seen On...

Welcome to Tech Support Guy!

Are you looking for the solution to your computer problem? Join our site today to ask your question. This site is completely free -- paid for by advertisers and donations.

If you're not already familiar with forums, watch our Welcome Guide to get started.

Join over 733,556 other people just like you!

Thread Status:
Not open for further replies.

Short URL to this thread: https://techguy.org/917146

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice