Re: [cryptography] this house believes that user's control over the root list is a placebo
Hi, Any model that offers a security feature to a trivially tiny minority, to the expense of the dominant majority, is daft. The logical conclusion of 1.5 decades worth of experience with centralised root lists is that we, in the aggregate, may as well trust Microsoft and the other root vendors' root list entirely. Or: find another model. Change the assumptions. Re-do the security engineering. You have avoided the wording find a better model - intentionally so? Because such work would only be meaningful if we could show we have achieved an improvement by doing it. Which brings us to the next point: how do we measure improvement? What we would need - and don't have, and likely won't have for another long while - are numbers that are statistically meaningful. On moz.dev.sec.policy, the proposal is out that CAs need to publicly disclose security incidents and breaches. This could actually be a good step forward. If the numbers show that incidents are far more frequent than generally assumed, this would get us away from the low frequency, high impact scenario that we all currently seem to assume, and which is so hard to analyse. If the numbers show that incidents are very rare - fine, too. Then the current model is maybe not too bad (apart from the fact that one foul apple will still spoil everything, and government interference will still likely remain undetected). The problem is that CAs object to disclosure on the simple grounds that public disclosure hurts them. Even Startcom, otherwise aiming to present a clean vest, has not disclosed yet what happened on June, 15th this year. Mozilla seems to take the stance that incidents should, at most, be disclosed to Mozilla, not the general public. While understandable from Moz's point of view - you don't want to hurt the CAs too badly if you are a vendor - it still means researchers won't get the numbers they need. And the circle closes - no numbers, no facts, no improvements, other than those subjectively perceived. Ralph signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] this house believes that user's control over the root list is a placebo
Hi, The most common security breach is probably that a government or powerful private group launches a man in the middle attack. Are CAs going to report that? Seems unlikely. The key word in your sentence is probably. Just how much is that? I'm not saying I'm not with you in the general argument, but I am saying that in order to compare one model with another, we need more facts, and less belief. Ralph signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] ssh-keys only and EKE for web too (Re: preventing protocol failings)
Hi, On 07/13/2011 01:34 PM, Ian G wrote: Is there any reason why the ssh client-side can't generate the key, take the password from the user, login and install the key, all in one operation? Hm, I think there's actually a tool to do just that, although I don't remember the name. You'd probably still have to disable password access. 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] An appropriate image from Diginotar
Hi, --- @nocombat writes: SSL Observatory: select count(Subject) from valid_certs where Issuer like '%diginotar%' â01 --- They've only issued 700-odd SSL certs? Wow, that's low. OTOH since their gravy train is mainly built around the Dutch government's PKI letter of marque [0], I could imagine that their generic SSL cert business doesn't get much attention. I have some values from our own scans - scans conducted against hosts on the Alexa Top 1M list [1]. Here are the domains they have certified on that list, almost exclusively .nl: pki_crawl=# SELECT DISTINCT ON(hashcert) host FROM certificates_28mar2011_nosni WHERE issuer ILIKE '%DigiNotar%'; host -- www.ebita.nl www.notaris.nl www.ind.nl overijsselkiest.nl spijkenisse.nl www.salland.nl www.vwa.nl atom86.net nuon.nl vlaardingen.nl www.liander.nl www.studielink.nl senternovem.nl cbpweb.nl akd.nl overheid.nl www.rdw.nl www.haarlemmermeer.nl www.mijnpensioenoverzicht.nl nijmegen.nl rechtspraak.nl officielebekendmakingen.nl www.rijkswaterstaat.nl www.funprice.nl www.digid.nl www.norrod.nl www.woningnet.nl www.zuid-holland.nl www.bloemendaal.nl (29 rows) [1] We'll make the datasets public soon-ish. 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
[cryptography] Symantec gets it wrong
Hi, I (still) cannot believe how Symantec reacts to the DigiNotar breaches - basically ignoring the known shortcomings: http://www.symantec.com/connect/blogs/why-your-certificate-authority-matters Marketing department speaking, no doubt. 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] Symantec gets it wrong
Hi, http://www.symantec.com/connect/blogs/why-your-certificate-authority-matters To be contrarian for a moment [...] This isn't to say it justifies or supports the marketing campaign, but perhaps there is a real message hidden in there after all? That would be a really far-sighted campaign, but yes, it's a point. However, what I meant is that the blog entry ignores the fact that as long as there is a weakest link in the root store, protection of your domain certification is exactly as strong as that weakest link. Sure, you can go to VeriSign to get a certificate, but it won't help you if DigiNotar is hacked afterwards and certificates for your domain issued. I am no good at predicting customer behaviour, but why should customers opt for the more expensive solution then? 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] Let's go back to the beginning on this
Hi, Is anyone aware of any up-to-date data on this btw? I've had discussions with the browser makers and they have some data, but I wonder whether anyone else has any data at scale of how often users really do run into cert warnings these days. They used to be quite common, but other than 1 or 2 sites I visit regularly that I know ave self-signed certs, I *never* run into cert warnings anymore. BTW, I'm excluding mixed content warnings from this for the moment because they are a different but related issue. I run into it quite regularly, often on sites of non-commercial organisations. Like universities. My favourite page so far said Please ignore the warning that will appear when you click next (that was FU Hagen, I believe). That said, I can see in our monitoring data that about 20-60% of certification chains are broken, and these are sites that people do access (it is passive monitoring data from a large regional ISP). In our scanning data, we find that only about 18% of certificates have both a valid chain plus the correct hostname (wildcarded or not) in their CNs or SANs. 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] Let's go back to the beginning on this
Hi, Interesting. Are you pulling the server-certs out of the SSL handshake and then checking if they validate against any browser store? Yes, with the second operation offline and validating against the NSS root store. I don't have a MS one at the moment, it would be interesting (how do you extract that from Win? The EFF guys should know) (Here's a privacy disclaimer, though: only statistics leave our monitor, no certs, no connection data, etc.) In our scanning data, we find that only about 18% of certificates have both a valid chain plus the correct hostname (wildcarded or not) in their CNs or SANs. This data, while interesting, doesn't tell us much about how often users encounter those sites. I much prefer data instrumented from actual web browsers, or network traffic. Well, yes, but it is the Alexa Top 1 million list that is scanned. I can give you a few numbers for the Top 1K or so, too, but it does remain a relative popularity. 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] Let's go back to the beginning on this
Hi, HTTPS Everywhere makes users encounter this situation more than they otherwise might. A week or three ago, I got cert warnings - from gmail's page. (Yes, I'm using HTTPS Everywhere). When _that_ happens, please tell Google and EFF. I'm sure both organizations would be fascinated. I would also be very interested to hear from where that happened, and if you can give us a traceroute... 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
[cryptography] MD5 in MACs in SSL
Hi, I'm wondering about the use of MD5 in SSL MACs. We see that quite often here. What is your take on it? Given that SSL includes replay protection for its session keys, it does not seem to give an attacker any useful time window, but am I missing something maybe? 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] Let's go back to the beginning on this
Hi, Yes, with the second operation offline and validating against the NSS root store. I don't have a MS one at the moment, it would be interesting (how do you extract that from Win? The EFF guys should know) You might look at https://www.eff.org/files/ssl-observatory-code-r1.tar_.bz2 in the microsoft_CAs directory. Yes, I found that, but it seemed to contain a snapshot of PEMs from the time of the EFF crawl in 2010, so it might be outdated. I would like to obtain a fresh copy. How did you go about it, did you compile it manually or is there a software kind of way to extract it directly from Windows, maybe polling MS? 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] Let's go back to the beginning on this
Hi, Well, yes, but it is the Alexa Top 1 million list that is scanned. I can give you a few numbers for the Top 1K or so, too, but it does remain a relative popularity. How many of those sites ever advertise an HTTPS end-point though? Maybe users are extremely unlikely to ever see a link, etc. that points to their HTTPS endpoint. Maybe, but I don't have any numbers on that. However, if someone wants to do it: a simple way would be to download a site's start page and check for HTTPs links in the HTML. Then go to that site, download the cert and do the validity checks. Obviously, you're likely not in the top 1 million sites anymore then. Actually, I think Ivan Ristic has done something similar for login forms: http://blog.ivanristic.com/2011/05/a-study-of-what-really-breaks-ssl.html Although his presentation doesn't give any numbers how often the encountered certificates were valid (chain, host name) for the thus protected login site. 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] Math corrections
Hi, Are there weaknesses in PKI? Undoubtedly! But, there are failures in every ecosystem. The intelligent response to certificate manufacturing and distribution weaknesses is to improve the quality of the ecosystem - not throw the baby out with the bath-water. And how do you propose to go about it? The incentives seem all wrong - the famous race to the bottom. RapidSSL (2009), Comodo (2008, 2011), StartSSL (2008, 2011), DigiNotar (2011). With the exception of StartSSL and RapidSSL (Kurt Seifried only intended to test their systems), all these attacks have been more or less successful. There are about 160 root certificates in NSS. Last I looked a few dozen were in the queue. By how many do you propose to reduce the number? Or do you propose name restrictions? If so, for whom? DigiNotar might have had an additional incentive, as a CA that was also chosen by a government. What did they make of it? I am not opposed to PKI as in the generic meaning of the term, but how do you propose to rescue today's eco system? I don't really believe in that. 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)
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)
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
[cryptography] Data sets: certificates that are different from two scanning locations
Good day, We have just uploaded the following data sets we mention in our IMC paper. Certificates found different between location China-1 and TUM, Apr 2011 Certificates found different between location China-2 and TUM, Apr 2011 Certificates found different between location Moscow and TUM, Apr 2011 Certificates found different between location UCSB and TUM, Apr 2011 All from university networks (PlanetLab). The data sets contain host name, cert as seen from remote location, cert as seen from TUM. The download location is: http://pki.net.in.tum.de/ We did not have the time to go through the many hosts and certs, although we did take a thorough sample (and found nothing clearly suspicious). We have promised in the paper to offer these data sets to other researchers so they can have a look. I thought this list is a good place to start. Ralph signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Data sets: certificates that are different from two scanning locations
Hi, On 09/20/2011 12:02 PM, Ben Laurie wrote: Where's the paper? From what I understand, it seems we are allowed to send it to individuals and publish it on our homepage if we cite the DOI. I am currently verifying that and waiting for the DOI, and will then upload it to our site. Ralph On Mon, Sep 19, 2011 at 11:18 PM, Ralph Holz h...@net.in.tum.de mailto:h...@net.in.tum.de wrote: Good day, We have just uploaded the following data sets we mention in our IMC paper. Certificates found different between location China-1 and TUM, Apr 2011 Certificates found different between location China-2 and TUM, Apr 2011 Certificates found different between location Moscow and TUM, Apr 2011 Certificates found different between location UCSB and TUM, Apr 2011 All from university networks (PlanetLab). The data sets contain host name, cert as seen from remote location, cert as seen from TUM. The download location is: http://pki.net.in.tum.de/ We did not have the time to go through the many hosts and certs, although we did take a thorough sample (and found nothing clearly suspicious). We have promised in the paper to offer these data sets to other researchers so they can have a look. I thought this list is a good place to start. 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, 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] fyi: another TLS/SSL certs-in-the-wild survey (Holz et al)
Hi, I wanted to write a mail last night to this list, but you got there first. :-) Yes, we put the paper online; as soon as I am back from my vacation we'll start releasing all remaining data sets. PS: What I hope for is if people can find anything that we missed. Say, in the data sets from, e.g., China, Russia and a few other places. For that, they'll need the ones from TUM to be able to compare. Ralph On 09/29/2011 07:01 PM, =JeffH wrote: http://www.net.in.tum.de/fileadmin/bibtex/publications/papers/imc-pkicrawl-2.pdf The SSL Landscape - A Thorough Analysis of the X.509 PKI Using Active and Passive Measurements Ralph Holz, Lothar Braun, Nils Kammenhuber, Georg Carle Technische Universität München -- 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] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
Hi, Hypothetical question: assume enough people get educated how to spot the MitM box at work/airport/hotel. Let's say few of them post the MitM chains publicly which point to a big issuing CA. It was said (by Peter I think) that nothing would likely happen to big issuing CAs (too-big-to-fail). Would the MitM-ing sub-CAs take the fall? (lose license and invested funds) We're actually about to release a little tool that does exactly that, report the encountered MitM for further scrutiny. 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] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)
Hi, We're actually about to release a little tool that does exactly that, report the encountered MitM for further scrutiny. Great! I had some ideas how to implement and spread it, awesome to hear that that you beat me to it :-) :) It was actually Kai Engert who made the initial suggestion, and we've just followed up on it. We've proposed a talk at berlinsides, let's see if that works out. :-) 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] so can we find a public MitM cert sample? (Re: really sub-CAs for MitM deep packet inspectors?)
Hi, I have to say I have my doubts that either Boingo or Sheraton hotels, or other providers would be doing MitM for advertising/profiling or whatever reasons to their respective wifi services. Absent certs showing this, its a significantly controversial claim, and there are many many reasons you can see something that appears suspicious at a glance. Multiple certs for the same domain (load balancers), legitimately changed certs, different certs for different server farms in different geographic locations, cert warnings before you login because of the HTTP intercept, cached/delayed versions of the previous, localhost anti-spam/anti-virus proxies that are doing transparent proxying, VPN routing to a MitM corporate box? There are a lot of things that can do unexpected things. I could imagine such attacks happen more frequently in hotels in certain countries with a high inclination towards wiretapping. Industrial espionage could be one motivation. On an unrelated note, there was a report of a Tor exit node doing a MitM on SSL connections running through it. Of course, it was years ago and I didn't pay much attention to it then, and have no URL that I could provide. :-/ 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
[cryptography] Another CA hacked, it seems.
As I said, at this rate we shall have statistically meaningful large numbers of CA hacks by 2013: http://translate.google.com/translate?sl=autotl=enjs=nprev=_thl=enie=UTF-8layout=2eotf=1u=http%3A%2F%2Fwebwereld.nl%2Fnieuws%2F108815%2Fweer-certificatenleverancier-overheid-gehackt.htmlact=url 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 CA hacked, it seems.
Hi, Did they successfully hack the CA functionality or just a web site housing network design documents for various dutch government entities? From what survives google translate of the original dutch it appears to be the latter no? Too early for a definite call. But there is also this report that 1,000 certs have been revoked in the past 2-3 months. http://translate.google.com/translate?hl=nlsl=nltl=enu=http%3A%2F%2Fwebwereld.nl%2Fnieuws%2F108829%2Fspoeddebat-over-ingetrokken-kpn-certificaten-.html Might also be some routine revocation for replaced certs, though; reasons are not given it seems. And if Kerckhoff's principle was followed what does it matter if some network design docs were leaked. You would hope they dont contain router passwords or such things. Yes, with respect to the hope part. Although, personally, I wouldn't dream of running phpmyadmin if I were a CA. I'd hestitate calling that a CA hacked even if the web site was a web site belonging to someone who operates a CA. Is there more detail? Not yet, I think. So let's not call it hacked, if you want, but just seriously embarassed. And I keep looking over towards the popcorn, tea biscuits stand. :-) 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] Chrome to drop CRL checking
Hi, The security argument itself seems very weak. There is no evidence yet that the alternative strategy that Google proposes, namely letting them control the CRL list (and thus another part of the internet infrastructure), is any safer for the user in the long run. The point is that using this mechanism means Chrome always has an up-to-date revocation list - as it is now, revocation checking can be blocked and Chrome will allow revoked certs as a result. What is the point in disabling OCSP, then? Chrome could always use its own revocation database as a primary reference, and use OCSP additionally if there is no hit. I like that Chrome pulls revocations via the update mechanism, but this does not sound very scalable - where do you draw the line? Do you have data how many CRL entries come with a reason (those are preferred by Chrome). How do you make sure no false reason is given by CAs as a consequence - i.e. they always just put fake entries there saying cert renewed even though it may actually have been a compromise. So, yes, Chrome does raise the barriers a bit, but I fail to see how this could be a long-term solution and how it could extend to anything but a small selected subset of the Web. Certainly the privacy concern that Google expresses because the CA learns the IP address of users and which sites they're visiting does not extend to Google itself, which already has much more detailed information about its users. Since it is a push mechanism, Google does not get which sites the user is visiting. I think Markus' point is: it is not an advance in privacy for the user. Many people just type a keyword into the omnibox to land on the desired page (facebook). Thus, Google already knows what they do; they do not need the information from online revocation checking. -- 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] how many MITM-enabling sub-roots chain up to public-facing CAs ?
Ian, Actually, we thought about asking Mozilla directly and in public: how many such CAs are known to them? I'd have thought that some would have disclosed themselves to Mozilla after the communication of the past few weeks. Your mail makes it seem as if that was not the case, or not to a satisfying degree. Which makes me support Marsh Ray's one-strike proposal even more strongly: issuing a death sentence to a CA who has disclosed is counter-productive. It will drive the others deeper into hiding. You kno, I can't help but think of the resemblance to the real world death penalty for humans - AFAICT it does not seem to deter criminals. Ralph On 02/14/2012 03:31 AM, ianG wrote: Hi all, Kathleen at Mozilla has reported that she is having trouble dealing with Trustwave question because she doesn't know how many other CAs have issued sub-roots that do MITMs. Zero, one, a few or many? I've sent a private email out to those who might have had some direct exposure. If there are any others that might have some info, feel free to provide evidence to kwil...@mozilla.com or to me if you want it suitably anonymised. If possible, the name of the CA, and the approximate circumstance. Also how convinced you are that it was a cert issued without the knowledge of the owner. Or any information really... Obviously we all want to know who and how many ... but right now is not the time to repeat demands for full disclosure. Right now, vendors need to decide whether they are dropping CAs or not. iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography -- Ralph Holz Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] how many MITM-enabling sub-roots chain up to public-facing CAs ?
Hi, Well I am not sure how they can hope to go very far underground. Any and all users on their internal network could easily detect and anonymously report the mitm cert for some public web site with out any significant risk of it being tracked back to them. Game over. So removal of one CA from a major browser like mozilla would pretty much end this practice if it is true that any CAs other than trustwave actually did this... If all users used a tool like Crossbear that does automatic reporting, yes. But tools like that are a recent development (and so is Convergence, even though it was predated by Perspectives). More importantly, however, how capable do you judge users to be? How wide-spread do you expect such tools to become? Most users wouldn't know what to look for in the beginning, and they would much less care. Following your argument, in fact, we should have a large DB with Mitm certs and incidents already. We don't - but not because CAs would not have issued Mitm certs for Sub-CAs, surely? No, CAs would try to hide the fact that they have issued certs that are good for Mitm a corporate network. Some big CAs -- to big too fail even, maybe, and what about them? -- have not yet publicly stated that they have never issued such certs. I think giving them a chance at amnesty is a better strategy. Ralph -- Ralph Holz Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] how many MITM-enabling sub-roots chain up to public-facing CAs ?
Hi, On 02/14/2012 04:20 PM, Adam Back wrote: My point is this - say you are the CEO of a CA. Do you want to bet your entire company on no one ever detecting nor reporting the MITM sub-CA that you issued? I wouldnt do it. All it takes is one savy or curious guy in a 10,000 person company. Consequently if there are any other CAs that have done this, they now know mozilla and presumably other browsers are on to them and they need to revoke any mitm sub-CA certs and stop doing it or they risk their CA going bankrupt like with diginotar. Yes, I got that. I just think it's not how a normal CEO would react if TrustWave had been kicked out *after* confessing what they'd done. If that confession had been met with punishment, CAs would have had only an incentive to hide, but not to make further confessions. That's why I said I like Marsh's proposal: incentives are now to make up for past mistakes, *and* take precautions they are not repeated. That's a net gain in security for everyone, and that's why I was against kicking out TrustWave. Ralph -- Ralph Holz Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] how many MITM-enabling sub-roots chain up to public-facing CAs ?
Hi, If all users used a tool like Crossbear that does automatic reporting, yes. Not really -- and this I think goes to the root of why what was done here is so evil. [... many correct things omitted, sorry ...] It is not so hard really to see the conceptual difference between the two cases. But to tools like Crossbear, they basically look the same. Why? Crossbear sends the full certificate chain it sees to the CB server, where it is compared with the full chain that the CB server sees (plus a few more servers, too, actually, that it can ask). Convergence, AFAICT, does the same. If you're inside the corporate network, the certificate chain in the SSL handshake cannot be the same, and both systems will detect them. Where Crossbear goes further is that it will now start requesting traceroutes from participating systems to find out where in the network the Mitm is. Ralph -- Ralph Holz Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] how many MITM-enabling sub-roots chain up to public-facing CAs ?
Hi, In both cases, Crossbear will detect a MITM device, yes? But in one case, the device is authorized to sign for the entities it's signing certificates for, and in the other, it's not. This does not in any way diminish the usefulness of Crossbear as a tool for detecting MITM devices. But what's interesting about what happens in these two cases is that it's _whether the user is being deceived_ that differs. Crossbear can't know that -- the user has to supply the knowledge of whether there is, in fact, an authorized MITM in place. Ah, I see where you're going with this. Crossbear signals its findings to the client browser, via a separate SSL connection (the CB server cert is hard-coded into the Crossbear client). The assessment comes complete with a view of what others are seeing, including a view we obtain by asking Convergence. The suspicious chain is sent to our database for human analysis. As Crossbear's assessment is not something everyday users will understand, we ourselves view Crossbear as the tool that, e.g., a travelling security afficionado/hacker/interested person might want to use, but not your average guy. Our goal is to find out how many Mitm actually happen, and how, and where. That's why Crossbear has this second component, the hunting tasks. BTW: Crossbear's assessment still leaves some potential for false positives: there are plenty of server farms out there that use more than one (valid) chain. If a new but valid one pops up, no system can know it at first. That's where all these notary-based systems get in trouble when they cache (and they have to, at least on the global scale, like Convergence). And that is precisely what is wrong with what Trustwave did: they tried to make it look like there was no MITM in place instead of an unauthorized one, where in this case authorized means the administrator of the client node positively agreed to have that node's traffic MITMed. Yes, fully agreed. But I still think pulling their root would have given the wrong incentive to CAs. Ralph -- Ralph Holz Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] how many MITM-enabling sub-roots chain up to public-facing CAs ?
Hi, As Crossbear's assessment is not something everyday users will understand, we ourselves view Crossbear as the tool that, e.g., a travelling security afficionado/hacker/interested person might want to use, but not your average guy. Our goal is to find out how many Mitm actually happen, and how, and where. That's why Crossbear has this second component, the hunting tasks. Interesting -- will this work, in the case of authorized MITM of the network the client's on? The second SSL connection will always fail, since the MITM device will MITM it. Perhaps there should be an option to retrieve results separately and later? Yes, things start to become difficult when the middle-box goes and actively meddles with the messages the client sends to the server. That sure is a dedicated attacker now that is also built to defeat Crossbear. We have the CB server's cert hard-coded in the client, so we can encrypt to the server and check its signatures, too, and be sure who's talking to the client. If the attacker starts to drop CB server messages, our first reaction is to warn the user that there might be foul play and that he's now unprotected. Unfortunately, there's no way to distinguish deleted messages from network outage or similar faults. So, yes, we have thought about extending Crossbear to a) store the results and try to send them later (should work for mobile devices) or b) try and switch to other channels. We're not quite sure about the latter as the question is really how much power your attacker has. Use the user's mail client and create a mail, anonymous FTP, WebDAV - OK. Maybe a Tor hidden service for the extreme cases? None of these is built-in so far. BTW, what we do not address is an attacker sending us many forged chains and/or traces. We don't want clients have to register with our server and obtain an identity. That's a sore point. Ralph -- Ralph Holz Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] how many MITM-enabling sub-roots chain up to public-facing CAs ?
Hi, BTW, what we do not address is an attacker sending us many forged chains and/or traces. We don't want clients have to register with our server and obtain an identity. That's a sore point. Aren't the certs of interest those that chain to a well-known root? So they could be validated, and those that don't could be efficiently discarded. At that point, the attacker is reduced to effectively doing an SSL DoS on you which is likely to grow old quickly. Yes, the certs are the lesser problem. The problem is that hunting tasks can be pulled by anyone from the server and results sent back. This is still not too bad DoS-wise, but it allows to send forged traceroute results. Ralph -- Ralph Holz Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] how many MITM-enabling sub-roots chain up to public-facing CAs ?
Hi, You kno, I can't help but think of the resemblance to the real world death penalty for humans - AFAICT it does not seem to deter criminals. Singapore has approximately one hundredth to one thousandth the crime rate of western democracies - near zero rapes, and dramatically fewer murders. Not only is their lower class law abiding, their bankers and bureaucrats, unlike ours are also law abiding. From which it is evident that the death penalty *does* deter, both for institutions and individuals. May I, just for reasons of comparison, have the same numbers for the US, especially the states with a death penalty, and the UK and/or DE? Ralph -- Ralph Holz Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Duplicate primes in lots of RSA moduli
Hi, Paper by Lenstra, Hughes, Augier, Bos, Kleinjung, and Wachter finds that two of every one thousand RSA moduli that they collected from the web offer no security. An astonishing number of generated pairs of primes have a prime in common. The title of the paper Ron was wrong, Whit is right I think is rather misleading, since virtually all the DSA keys were PGP-generated and there was only one ECDSA key, while there were vast numbers of RSA keys from all manner of software. So what it should really say is PGP got DSA keygen right, the sample size for ECDSA is too small to make any meaingful comment, and some RSA implementations aren't so good. Their survey seems to be very nice work. But they reach this conclusion in the abstract that RSA is significantly riskier than ElGamal/DSA. In the body of the paper, they indicate (although they are much more defensive already) that this is due to the fact that you need two factors and more randomness to go into the key creation. The larger number of weak RSA keys is then taken as an indication that this is inherently a problem of RSA. It's a leap. If you need more input, more can go wrong; but it does not seem conclusive evidence here. It would be conclusive if they compared keys created with the help of the same source of randomness and primality testers. Interestingly, in their own conclusions section they do not reiterate the above statement. Ralph -- Ralph Holz Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] On the duplicate RSA keys issue
Hi, the following blog post, which documents similar efforts, sheds some light, I think: https://freedom-to-tinker.com/blog/nadiah/new-research-theres-no-need-panic-over-factorable-keys-just-mind-your-ps-and-qs Ralph -- Ralph Holz Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] can the German government read PGP and ssh traffic?
But this sounds to me like a very general answer which was probably prepared ahead of time to reveal the minimal amount of information. For this reason I don't think it should be interpreted as referring to SSH or PGP specifically. But the phrase depending on the type and quality of the encryption would seemingly rule out endpoint hacks. Perhaps someone who knows German can better interpret it. The general feeling is, as someone put it here, it means everything and nothing, a fog of words. Something like we're able to store encrypted streams and try some brute-force on it later, also the known attacks against weaknesses and such. But if the protocols are executed flawlessly and implementations have no weaknesses, we don't stand a chance. Also, we've got out Bundestrojaner, and if we use that, we're on your system and you're practically defenceless. Never mind that it's in the face of the constitution and actually so badly written it violates some of the really important and very distinct guidelines that the courts have given us. Ralph -- Ralph Holz Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Why using asymmetric crypto like symmetric crypto isn't secure
Hi, In the past there have been a few proposals to use asymmetric cryptosystems, typically RSA, like symmetric ones by keeping the public key secret, the idea behind this being that if the public key isn't known then there isn't anything for an attacker to factor or otherwise attack. Turns out that doing this isn't secure: http://eprint.iacr.org/2012/588 A question: The attack seems to aim at getting n = p * q, and then factor it. I.e. what they really show is that it is possible to derive the public key from two plain/ciphertext pairs; alternatively a multiple of n. In essence, there is no point in keeping the public key secret as it can be guessed. However, the factoring would still remain as a huge task for the attacker, unless RSA is used at a meagre bit length, as in their example. Correct? Ralph signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Interactive graph of the CA ecosystem
Hi, To that end, have y'all thought of other views that would be interesting to have? Also, can you put more meta data along with the provider? Such as address, parent company, how long they've been a CA, (if it's known) how many certs they've signed? Certainly nice information. @Bernhard: That information can be found in the Mozilla spreadsheet that Kathleen Wilson maintains in Google Docs. A Google search of moz.dev.sec.pol should yield it. Ralph -- Ralph Holz Network Architectures and Services Technische Universität München Phone +49 89 28918043 http://www.net.in.tum.de/de/mitarbeiter/holz/ PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] another cert failure
Hi, On 01/05/2013 12:29 PM, Ben Laurie wrote: Unless all the people who saw it happened to be running Chrome, then it seems quite likely it was used maliciously, surely? The problem is that there are many values that both legitimately and maliciously can take. Turktrust's argument seems to be that it was legitimately used for SSL interception on a firewall/proxy device. The SANs in the rogue certs that have been published seem to support that. Whether SSL interception is good or bad is, unfortunately, open to debate. That said - does Google currently hold more rogue certs than the ones published? Chrome has some other sites pinned, too - is there actually a list? Ralph signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] How much does it cost to start a root CA ?
Hi, Is inclusion of a root CA in the major browsers a shall issue process ? hat is, you meet the criteria and you get in ? Or is it a subjective, political process ? The process varies between browser vendors, with baseline requirements established in the CAB Forum. Audits are usually required. The process for Mozilla is open: there is a one-week time of debate in the group mozilla.dev.security.policy where everyone can chime in and help to analyse the inclusion request. Sadly, there are not that many participants, but that is understandable as the level of detail is high and understanding a CPS document is very demanding. There are some veterans, of course. My impression is that every voice is heard equally, and a summary of concerns then given at the end of the week. The CA is given a chance to fix that and can then be included. Rejections are extremely rare, I am not sure if I have seen even one in the past 3 years. It certainly was not more. I am not sure if some participants' opinion is given more weight than others (it might make sense), or how the resolution of concerns is handled afterwards. What I have seen repeatedly is discussion whether a CA operates for the general public (only those are deemed acceptable) or not. That seems to be a somewhat subjective criterion. What I have also seen was post-hoc debate about the inclusion of the Chinese CA CNNIC (CN-NIC), which IMO highlighted a shortcoming of the process: If participants do not have much time, the one-week discussion period may pass without many comments and a CA thus be included. In the case of CNNIC, many objections were raised afterwards as this CA had been allegedly associated with malware in the past; there was also concern the Chinese government might use it to issue the kind of MITM certificates we're worried about. No proof of any such activity could be given, and Mozilla decided that the fair approach was to keep them in. Ralph signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Why anon-DH is less damaging than current browser PKI (a rant in five paragraphs)
Certificate Transparency is a real security measure that is a response by a browser vendor. So the response to the repeated failure of browser PKI is PKI-me-harder. Yeah, that's really going to make users safer. I don't see why CT is PKI-me-harder. EV or BR would fall into that category. But why CT? It is a very useful monitoring tool, and has some advantages over Sovereign Keys. Ralph -- Ralph Holz Network Architectures and Services Technische Universität München Phone +49 89 28918043 http://www.net.in.tum.de/de/mitarbeiter/holz/ PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Q: CBC in SSH
Hi, From what I can tell from our data, the most common symmetric ciphers in SSH are proposed by client/servers to be used in CBC mode. With SSL/TLS and XMLEnc, this mode has had quite some publicity in the recent past. I was wondering to which degree the attacks that were possible on SSL with AES/CBC might also be applicable to SSH? Quickly asking Google yielded things like http://modular.math.washington.edu/home/wstein/www/home/malb/papers/plaintext_recover_attacks_against_ssh.pdf http://www.kb.cert.org/vuls/id/958563 I was wondering if there have recently been any more insights? Grateful for any pointers. Thanks, Ralph -- Ralph Holz Network Architectures and Services Technische Universität München Phone +49 89 28918043 http://www.net.in.tum.de/de/mitarbeiter/holz/ PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] someone should make openssh keys expire
Hi,
On 04/09/2013 04:05 AM, Tom Ritter wrote:
Somebody did ;) http://www.sshark.org/
Could I shamelessly self-advertise our notary service for SSH host keys?
ralph@firenze:~$ dig -t TXT 131.159.15.12.cbssh.net.in.tum.de
;; ANSWER SECTION:
131.159.15.12.cbssh.net.in.tum.de. 21600 IN TXT {ip: 131.159.15.12,
[{fp: 0f:59:a5:bf:28:7f:31:a3:cc:4a:7f:10:24:f8:b1:93, first-seen:
2012-11-18 01:36:19, last-seen: 2012-11-18 01:36:19, count: 1, type:
ssh-rsa, ver: ssh2},{fp:
56:de:fb:d4:c9:99:5d:e0:36:f4:2e:fb:4d:15:68:7d, first-seen: 2012-11-18
01 :36:35, last-seen: 2012-11-18 01:36:35, count: 1, type: ssh-dss,
ver: ssh2}]}
We have several hundred thousand IP -- hostkey mappings there.
Here's the talk:
http://www.youtube.com/watch?v=29h21n-tyfEt=46m26s
Admittedly, this is just a low-powered notary that we run for the fun of
it, but we're going to release code etc. for others to use.
Ralph
signature.asc
Description: OpenPGP digital signature
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Validating cryptographic protocols
The state of the art is represented by: - ProVerif (represent protocols by Horn clauses and analyzes them doing over-approximation) http://prosecco.gforge.inria.fr/personal/bblanche/proverif/ - Scyther (symbolic backwards search) http://people.inf.ethz.ch/cremersc/scyther/index.html - Avispa (here protocols are modeled in a common language called HLPSL and fed into four different back-end tools, each with unique features...) http://www.avispa-project.org/ - Casper/FDR (translate protocol models in process algebra CSP and uses FDR model checker to provide an analysis of the translated protocols) http://www.cs.ox.ac.uk/gavin.lowe/Security/Casper/installation.html So far, I've been having positive experiences with Scyther and Avispa. I second that. In particular, I have found Avispa to be very useful. There used to be one difference between Scyther and Avispa in terms of the authentication definition, with Scyther's using a stronger one. But I think Cas mentioned he's implemented Avispa's definition now, too. Both are very good model checkers. Avispa might give you some more difficulty, I think, because it's only available as a binary for certain platforms (ia32 linux, I think). Ralph ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Potential funding for crypto-related projects
I don't think they are doing this (as I said, they only bother with the low hanging fruit) but they could. Is there a tool that detects changes of CA? Certificate Patrol does it for you on client-side: https://addons.mozilla.org/de/firefox/addon/certificate-patrol/ Our own Crossbear does it for you on server-side - and will aggressively start tracerouting to get an idea of where the MITM must be. Note that we are currently revising Crossbear to be implemented as an OONI test - called OONIBear. The Firefox plug-in has been broken by Mozilla's lovingly frequent changes in API; we're fixing at the moment. [1] https://addons.mozilla.org/de/firefox/addon/certificate-patrol/ [2] http://www.net.in.tum.de/fileadmin/bibtex/publications/papers/holz_x509forensics_esorics2012.pdf [3] http://www.youtube.com/watch?v=29h21n-tyfEt=46m26s Ralph -- Ralph Holz I8 - Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] what has the NSA broken?
Hi David, Most private keys are issued by, not merely certified by, the CAs. Can you give numerical evidence for this claim? Device certificates (those that go into mass manufactured products) typically have the CA provide both keys and cert. The back and forth of keygen-CSR-Sign-Return per product does not fit in the mindset of a manufacturer. I suspect this is more certs than all the web site certs put together. An interesting point, certainly. Two caveats, both of which I have to systematically verify for SSL, however (I have already verified them for SSH): 1) Mass-produced devices like to use default keys - Heninger et al. showed that quite conclusively last year. I.e. we are not looking at distinct certificates, and not such ones for private use. I can verify that with our latest scan of today, which was IPv4-wide. It will take me a bit to wade through the subjects, issuers, SKID and AKID. 2) On the same line: why have a device key signed by a CA anyway if you are going to use it for all devices of one line? 3) When we look at distinct certs, I am not so sure that your argument more than all Web certs put together still holds. Again, I need a moment to check that. Ralph -- Ralph Holz I8 - Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] TLS2
Hi Ben, Boy, are you out of date: http://en.wikipedia.org/wiki/Server_Name_Indication. I am not so sure many servers support it, though. My latest data, unfortunately, is not evaluated yet. But in 2011 the difference between switching on SNI and connecting without it, was pretty meagre across the Alexa range. Granted, many of those hosts may not be VHosts. Does Google have better data on that? Ralph -- Ralph Holz I8 - Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] TLS2
Hi, I am not so sure many servers support it, though. My latest data, unfortunately, is not evaluated yet. But in 2011 the difference between switching on SNI and connecting without it, was pretty meagre across the Alexa range. Granted, many of those hosts may not be VHosts. Does Google have better data on that? I think you're testing that wrong. The major websites run one website at multiple IPs - not multiple websites at a single IP. So connecting with/without SNI will usually get you the same result. To clarify: we did not hunt SNI-enabled sites. We were after cases where a server on the Alexa lists shows the default certificate for another site, but will show the correct one if SNI is enabled. We thus did two scans back then, one with and one without SNI enabled, and determined whether we saw different certificates for some domains. In the setup you describe, we'd fully expect the same certs -- and I agree it seems to be the much more prevailing setup. You want to test the Alexis 2,000,000 - 3,000,000 sites and see if you get a different result - hit shared hosting sites, where multiple sites run on a single IP. Ideally, I'd combine an IP scan with DNS information from zone files (which we have, but I don't have the time to do it). [0] https://en.wikipedia.org/wiki/Server_Name_Indication Yes, but our scans back then did not determine deployed server versions. Ralph -- Ralph Holz I8 - Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] To Protect and Infect Slides
Hi Jake, Ian Grigg just made a point on metzdowd that I think is true: if you want to change the NSA, you need to address the many corporates that profit from what they are doing. Because the chain goes like this: corporate money - election campaigns - representatives - NSA What do you think? And any ideas how to exercise pressure? Ralph On 12/31/2013 09:13 PM, Jacob Appelbaum wrote: Kevin W. Wall: On Tue, Dec 31, 2013 at 3:10 PM, John Young j...@pipeline.com wrote: 30c3 slides from Jacob Appelbaum: http://cryptome.org/2013/12/appelbaum-30c3.pdf (3.8MB) And you can find his actual prez here: https://www.youtube.com/watch?v=b0w36GAyZIA Worth the hour, although I'm sure your blood pressure will go up a few points. I'm also happy to answer questions in discussion form about the content of the talk and so on. I believe we've now released quite a lot of useful information that is deeply in the public interest. All the best, Jacob ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography -- Ralph Holz I8 - Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
