Re: [cryptography] Another data point on SSL "trusted" root CA reliability (S Korea)
The way you position yourself in the network infra-structure is of very importance when doing data collection. Users of a given ISP may have rogue certificates while others at the same country but another ISP may not. We as researchers need to position ourselves at different network scopes in order to detect more efficiently rogue certificates and thus identifying more effectively doubtful CA's or even individual persons beings monitored. All users reaching the same endpoint should have the same certificate. So this is an important technical aspect that must be addressed carefully. The best way I think would be making users from those countries run some probe (as volunteers) to get their "Certificates" View. Actually EFF partially advocates this by telling people how to run their SSL Observatory but at the same time they suggest doing it in a Cloud Environment, thus distorting the main purpose of sitting ourselves at different network locations when collecting data. On Thu, Sep 22, 2011 at 5:30 PM, Ralph Holz wrote: > Hi, > >> study this more carefully and sooner as possible. SSL Observatory from >> EFF is a step forward but we need more. > > Their distributed observatory is probably going to help much here, but I > can offer the data sets from our paper. I'll put the paper online > tomorrow and paste the link here. > >> 1 - We need data on the details of certificates obtained from >> different geographic/government locations when pointing to popular >> endpoints such us google, facebook and so on > > We did not find any differences in the top 200 or so, and the rest did > not seem suspicious. See the links in the previous mail for the set of > differing certs. > >> 2 - We need to map/take_in_account clustered endpoints, like google, >> when doing this, since certificates differ in the clusters. > > We did not observe that too often (Microsoft did it, not sure about > Google), but yes, we would need to crawl such clusters. > >> 3 - Sitting ourselfs in different geographic locations when performing >> data collection should be done using different methods (use of >> proxy's, people from different countries submitting their certificates >> views..???). > > Sorry, I don't quite get that? > > Ralph > > -- > Dipl.-Inform. Ralph Holz > I8: Network Architectures and Services > Technische Universität München > http://www.net.in.tum.de/de/mitarbeiter/holz/ > > > ___ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography > > ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Another data point on SSL "trusted" root CA reliability (S Korea)
Hi, > study this more carefully and sooner as possible. SSL Observatory from > EFF is a step forward but we need more. Their distributed observatory is probably going to help much here, but I can offer the data sets from our paper. I'll put the paper online tomorrow and paste the link here. > 1 - We need data on the details of certificates obtained from > different geographic/government locations when pointing to popular > endpoints such us google, facebook and so on We did not find any differences in the top 200 or so, and the rest did not seem suspicious. See the links in the previous mail for the set of differing certs. > 2 - We need to map/take_in_account clustered endpoints, like google, > when doing this, since certificates differ in the clusters. We did not observe that too often (Microsoft did it, not sure about Google), but yes, we would need to crawl such clusters. > 3 - Sitting ourselfs in different geographic locations when performing > data collection should be done using different methods (use of > proxy's, people from different countries submitting their certificates > views..???). Sorry, I don't quite get that? Ralph -- Dipl.-Inform. Ralph Holz I8: Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Another data point on SSL "trusted" root CA reliability (S Korea)
Let's be honest, without any methamatical/design/architectural assumptions, about the current PKI practical context. One of the weakest links of PKI is trust delegation to some sort of governement based legislated system. As said, somewhere on this maling list, CA's are companies in those same legislative ecosystems. This should be seen if you study the current "View of certificates" you get from popular endpoints using different geographic locations. Cross correlating this with the current PKI CA's/Delegations Trust network should give us an hint that effectively governments are monitoring the People. I think we should make an effort, in name of freedom, and study this more carefully and sooner as possible. SSL Observatory from EFF is a step forward but we need more. 1 - We need data on the details of certificates obtained from different geographic/government locations when pointing to popular endpoints such us google, facebook and so on 2 - We need to map/take_in_account clustered endpoints, like google, when doing this, since certificates differ in the clusters. 3 - Sitting ourselfs in different geographic locations when performing data collection should be done using different methods (use of proxy's, people from different countries submitting their certificates views..???). On Thu, Sep 22, 2011 at 10:38 AM, Ralph Holz wrote: > Hi, > > Sorry, but this is too good. This is the Bavarian tax office, and ELSTER > is the government's tax software: > > C=DE, ST=Bayern, L=Muenchen, O=Bayerisches Landesamt fuer Steuern - > Dienststelle Muenchen, OU=ELSTER, CN=Elster HTTPS-Client, 41 > > I seem to live in the country of offenders. > > Ralph > -- > Dipl.-Inform. Ralph Holz > I8: Network Architectures and Services > Technische Universität München > http://www.net.in.tum.de/de/mitarbeiter/holz/ > > > ___ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography > > ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Another data point on SSL "trusted" root CA reliability (S Korea)
Hi, Sorry, but this is too good. This is the Bavarian tax office, and ELSTER is the government's tax software: C=DE, ST=Bayern, L=Muenchen, O=Bayerisches Landesamt fuer Steuern - Dienststelle Muenchen, OU=ELSTER, CN=Elster HTTPS-Client, 41 I seem to live in the country of offenders. Ralph -- Dipl.-Inform. Ralph Holz I8: Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Another data point on SSL "trusted" root CA reliability (S Korea)
Hi, > Oh, now it makes sense, those are mostly router certs (and various other certs > from vendors who create broken certs like the Plesk ones). You won't just > find them in Korea, they're everywhere, in vast numbers, but (at least for the > router certs) they're usually only visible from the LAN interface. I just had a look in our monitoring data - i.e. data of real SSL connections that users make. Those cannot be router certs. I find CA:TRUE in 0.8% of certificates (of 200k connections) in Sep 2010; and in 1.15% in Apr 2011 (of 950k connections). Here are some noteworthy issuers and counted occurrences: CN=localhost.localdomain/emailAddress=root@localhost.localdomain, 585 (ok, boring) CN=undermine.corp/emailAddress=vzh...@yahoo-inc.com, 480 (more interesting) CN=confixx/emailAddress=i...@confixx.com, 206 (ok) CN=Administration Server, ST=Moscow, L=RU, C=RU/emailAddress=supp...@kaspersky.com, O=Kaspersky Lab, 114 (oh) C=DE, ST=Bayern, L=Vilshofen, O=Internet Widgits Pty Ltd, CN=quetzalcoatl.dyndns.org/emailAddress=webmas...@quetzalcoatl.dyndns.org, 105 (h) And, to my dismay :-), my own university seems to be messing up: C=DE, ST=Bavaria, L=Munich, O=Technische Universitaet Muenchen, OU=LSR Institute of Automatic Control Engineering, CN=*.lsr.ei.tum.de, 62 C=DE, ST=Bavaria, L=Freising, O=Wissenschaftszentrum Weihenstephan TUM, OU=InformationsTechnologie Weihenstephan, CN=phoenix.wzw.tum.de/emailAddress=ce...@wzw.tum.de, 54 Ralph -- Dipl.-Inform. Ralph Holz I8: Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Another data point on SSL "trusted" root CA reliability (S Korea)
Randall Webmail writes: >Does this warkitting require physical access to the router? No, it's all remotely done. (This is why I have two different routers from different vendors between me and the public internet, and have had this setup for about a decade now). Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Another data point on SSL "trusted" root CA reliability (S Korea)
From: "Peter Gutmann" To: cryptography@randombit.net Sent: Monday, September 19, 2011 2:32:21 PM Subject: Re: [cryptography] Another data point on SSL "trusted" root CA reliability (S Korea) Ralph Holz writes: >In terms of warkitting routers, they're pretty much all vulnerable [0], so all >you'd need to do after that is exploit the "CA" certs. OTOH if you can warkit >a router you can also drop sslstrip on it, and at that point it's game over >for the user whether you have a CA cert or not. Does this warkitting require physical access to the router? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Another data point on SSL "trusted" root CA reliability (S Korea)
Ralph Holz writes: >I am wondering if we can't get our hands on such a router and do a proof-of- >concept. Anyone in? In terms of warkitting routers, they're pretty much all vulnerable [0], so all you'd need to do after that is exploit the "CA" certs. OTOH if you can warkit a router you can also drop sslstrip on it, and at that point it's game over for the user whether you have a CA cert or not. Peter. [0] "All" meaning that every brand that researchers could get their hands on proved vulnerable. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Another data point on SSL "trusted" root CA reliability (S Korea)
Hi, > Why do we assume that government spies will go to such lengths to get > at an individual's data, when a downloaded root-kit on the target PC > suffices? Because some governments like spying on Gmail accounts. I would agree with you if your goal is to snoop on a dissident, there are easier procedures there. But if you want to detect dissent in your population, Gmail, Facebook and Twitter is what you want to check. Ralph -- Dipl.-Inform. Ralph Holz I8: Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Another data point on SSL "trusted" root CA reliability (S Korea)
Hi, >> http://www.meleeisland.de/issuer_ca_on_eff.csv > > Oh, now it makes sense, those are mostly router certs (and various other certs > from vendors who create broken certs like the Plesk ones). You won't just Hm. I agree that many are router certs, certainly those with brand names of networking equipment in the CN, but mostly? For example, are the 550,000+ ones with "CN=localhost.localdomain" also router certs? I guess the only way would be to rescan them and get the HTML they deliver. I did that, BTW, for about 60k certs with "Plesk" as CN. Mostly, the sites redirected to port 80, but in about a quarter of cases we found the typical Plesk portal sites. Given that you can google the default password, this seems a weak configuration. We'll report on that in our upcoming IMC paper, too [1]. > find them in Korea, they're everywhere, in vast numbers, but (at least for the > router certs) they're usually only visible from the LAN interface. It would certainly explain why they show up so often in the EFF scan, but not in our scan of the Top 1M (EFF: 13%, ours: 3%). But, even in the Top 1M, we get about 30k such certs, and they are not router certs. > So all you need to do is warkit a router via one of a seemingly endless > series > of vulns that SOHO routers have and you've got a trusted root cert that can > MITM all traffic through it. That would be very bad, truly. I am wondering if we can't get our hands on such a router and do a proof-of-concept. Anyone in? [1] http://conferences.sigcomm.org/imc/2011/program.htm Ralph -- Dipl.-Inform. Ralph Holz I8: Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Another data point on SSL "trusted" root CA reliability (S Korea)
Ralph Holz writes: >I don't think so. Here is a list of "COUNT(issuers), issuers" from the EFF >dataset. Only those counted that appeared > 200 times. > >http://www.meleeisland.de/issuer_ca_on_eff.csv Oh, now it makes sense, those are mostly router certs (and various other certs from vendors who create broken certs like the Plesk ones). You won't just find them in Korea, they're everywhere, in vast numbers, but (at least for the router certs) they're usually only visible from the LAN interface. So all you need to do is warkit a router via one of a seemingly endless series of vulns that SOHO routers have and you've got a trusted root cert that can MITM all traffic through it. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Another data point on SSL "trusted" root CA reliability (S Korea)
Hi, >> In the EFF dataset of the full IPv4 space, I find 773,512 such certificates. > > Could these be from the bizarro Korean DIY PKI (the NPKI) that they've > implemented? Could you post (or email) some of the certs? I don't think so. Here is a list of "COUNT(issuers), issuers" from the EFF dataset. Only those counted that appeared > 200 times. http://www.meleeisland.de/issuer_ca_on_eff.csv Let me know if you want a few of those certs. BTW, that cert by Gov of Korea is found this often in the EFF data set: 1694 | C=KR, O=Government of Korea, OU=GPKI, CN=CA134040001 Should be in the CSV above. Ralph signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Another data point on SSL "trusted" root CA reliability (S Korea)
Ralph Holz writes: >In the EFF dataset of the full IPv4 space, I find 773,512 such certificates. Could these be from the bizarro Korean DIY PKI (the NPKI) that they've implemented? Could you post (or email) some of the certs? Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Another data point on SSL "trusted" root CA reliability (S Korea)
Hi, True, we found about 80 distinct certificates that had subject "Government of Korea" and CA:TRUE [1]. In our full dataset from April 2011, however, we found about 30k certificates with this property. None of them had valid chains to the NSS root store. The numbers do not seem to change over time: in Nov 2009, it was about 30k, and about the same in Sep 2010. In the EFF dataset of the full IPv4 space, I find 773,512 such certificates. *Distinct* ones - and the EFF dataset has 5.5m distinct certs. It is a wide-spread problem. For the case of Korea, @KevinSMcArthur found that the issuing certificates have a pathlen of 0, which makes it impossible for the end-host cert to operate as a CA *as long as the client actually checks that extension*. I don't know which ones do, but it would be a question to ask the NSS developers. As of now, I don't think these are really attacker certs, also because the overall numbers seem to point more at some CA software that creates certs with the CA flag on by default. Although your article seems to indicate something bad is going on over there... [1] If you want to check, CSVs at: www.meleeisland.de/korean_hosts_CA_on.csv www.meleeisland.de/korean_hosts_CA_on_fullchains.csv www.meleeisland.de/scan_apr2011_ca_on_issuers_not_selfsigned.csv Ralph On 09/18/2011 03:37 AM, Marsh Ray wrote: > > Been seeing Twitter from @ralphholz, @KevinSMcArthur, and @eddy_nigg > about some goofy certs surfacing in S Korea with CA=true. > > via Reddit http://www.reddit.com/tb/kj25j > http://english.hani.co.kr/arti/english_edition/e_national/496473.html -- Dipl.-Inform. Ralph Holz I8: Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Another data point on SSL "trusted" root CA reliability (S Korea)
On 2011-09-18 1:18 PM, Arshad Noor wrote: Why do we assume that government spies will go to such lengths to get at an individual's data, when a downloaded root-kit on the target PC suffices? The government has less ability, but no more ability, to rootkit your computer than do ten thousand Nigerian scammers. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Another data point on SSL "trusted" root CA reliability (S Korea)
On 09/17/2011 08:01 PM, James A. Donald wrote: On 2011-09-18 12:03 PM, Arshad Noor wrote: Why is it the most plausible assumption? Isn't it far easier to replace the cryptographic libraries on PCs with one that has a "wrapper" that copies all payloads before encryption and after decryption, and transmits the payload to the snooper? That is a black bag job. State security would have to sneak in, sneak out. Might get jumped, beaten up, attacked by dogs. Government employees are important people who do not expose themselves to such lowly hazards. Why do we assume that government spies will go to such lengths to get at an individual's data, when a downloaded root-kit on the target PC suffices? Arshad Noor StrongAuth, Inc. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Another data point on SSL "trusted" root CA reliability (S Korea)
On 2011-09-18 12:03 PM, Arshad Noor wrote: Why is it the most plausible assumption? Isn't it far easier to replace the cryptographic libraries on PCs with one that has a "wrapper" that copies all payloads before encryption and after decryption, and transmits the payload to the snooper? That is a black bag job. State security would have to sneak in, sneak out. Might get jumped, beaten up, attacked by dogs. Government employees are important people who do not expose themselves to such lowly hazards. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Another data point on SSL "trusted" root CA reliability (S Korea)
On 09/17/2011 09:03 PM, Arshad Noor wrote: On 09/17/2011 06:37 PM, Marsh Ray wrote: It's not entirely clear that a trusted CA cert is being used in this attack, however the article comes to the conclusion that HTTPS application data is being decrypted so it's the most plausible assumption. Why is it the most plausible assumption? Did you read the article? It goes on at length about this being a network-level attack. There is no mention of a compromised endpoint computer and to the contrary it says they deemed "conventional search and seizure would be insufficient". Isn't it far easier to replace the cryptographic libraries on PCs with one that has a "wrapper" that copies all payloads before encryption and after decryption, and transmits the payload to the snooper? Sure, if you have an exploit all the target's computers. Investigators have been known to do this at times. But if that were the case, why wouldn't the security service have just said "yeah we hacked his PC and installed a keylogger"? If you were a security service, wouldn't you prefer to admit to using ye olde everyday keylogger rather that disclosing your ability to "conduct packet tapping" on HTTPS connections? Why go through the hassle of breaking a cipher when all you have to do is replace a few files on the target's PC to get what you want? I never suggested anyone was breaking a cipher. I said the most plausible attack was that a trusted CA was being used as the article seems to describe. I found the timing particularly interesting as it surfaced at the same time as Holtz's detection of the kooky certs in S Korea. - Marsh ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Another data point on SSL "trusted" root CA reliability (S Korea)
On 09/17/2011 06:37 PM, Marsh Ray wrote: It's not entirely clear that a trusted CA cert is being used in this attack, however the article comes to the conclusion that HTTPS application data is being decrypted so it's the most plausible assumption. Why is it the most plausible assumption? Isn't it far easier to replace the cryptographic libraries on PCs with one that has a "wrapper" that copies all payloads before encryption and after decryption, and transmits the payload to the snooper? Why go through the hassle of breaking a cipher when all you have to do is replace a few files on the target's PC to get what you want? Arshad Noor StrongAuth, Inc. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography