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 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
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] [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] 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] what has the NSA broken?
Hi, On 09/06/2013 07:12 AM, James A. Donald wrote: > Most private keys are issued by, not merely certified by, the CAs. Can you give numerical evidence for this claim? The CAs I work with - StartSSL and DFN - either allow to send CSRs or use the HTML keygen method. I'd be surprised if a majority of CAs insisted on generating the key for you. The Baseline Requirements by CABForum furthermore state that a CA must not archive the private keys. 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] Potential funding for crypto-related projects
Hi, > There should be a disclaimer somewhere that Tor is a competitor to > I2P, is far from perfect itself (actually has a few glaring > weaknesses, such as exit nodes), and the guy critiquing I2P works for > Tor. The guys who did the PETS 2011 attack on I2P are not with Tor, but with GNUNet -- an absolutely underrated project whose principal problem is deployment. And the goal is not competition as in market share, but competition as in healthy disclosure of weaknesses. That said, behind every project there is an ego. I'd be happy so see more people have a look at GNUNet: https://www.gnunet.org/ Disclaimer: The GNUNet guys are my friends; but I am not a GNUNet developer myself. Until I'm Grothoff'ed, as so many have been before. Insider joke. -- 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] 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-tyfE&t=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] 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] 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-tyfE&t=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
[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] 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
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] 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] 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] Interactive graph of the CA ecosystem
Hi, >> Hm, I do have a question. Thawte EV has an "outbound" link to "Thawte >> Root", similarly TUM has an "outbound" link to DFN. I would understand >> "outbound" as indicating the direction of the signature, i.e. DFN -> >> TUM. So I would have expected the link between TUM and DFN to be >> "inbound" when I click on TUM. But it seems to be consistenly applied, >> so I guess that was a conscious choice? > > Well, we chose to represent the relationships between the certificates > the other way round - the child certificates point to their parent CA. > However, > this is a purely semantical issue - for your point of view we just would > have to reverse all links. Fair enough. I don't know if my view is a minority or majority view, but I'd change it. :) >> […DFN Certificates and how they are granted...] > > Thank you very much, it is interesting to know the exact way this is done > at the Moment. I also think that each Institution (like the TUM) can only > issue certificates for a fixed set of domains. Other domains might require > manual DFN intervention. > > But I am not a hundred percent positive about that - I mainly got that > impression > from some threads on the Mozilla bug tracker where they discussed the DFN. That is an interesting question indeed. Any domain under the 2LD of a German university is certainly within their CPS. However, we have registered 2LDs under ORG and NET now, with WHOIS identifying us as TUM, and will ask them to certify those. I'll report if that is possible or not. :) 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] Interactive graph of the CA ecosystem
Hi, > We just released an interactive graph that shows the relationship > between the root-CAs of the Mozilla root-store and their intermediates > at http://notary.icsi.berkeley.edu/trust-tree/. Nice one, and nice to hear from you, too. :) My regards to the team - I imagine Robin is among them. Tell him I haven't forgotten about the daily update thing, just busy.:) > Root-CAs are pictured as red nodes, intermediate CAs are green. > The node diameter scales logarithmically with the number of > certificates signed by the node. Similarly, the color of the green > nodes scales proportional to the diameter. Hm, I do have a question. Thawte EV has an "outbound" link to "Thawte Root", similarly TUM has an "outbound" link to DFN. I would understand "outbound" as indicating the direction of the signature, i.e. DFN -> TUM. So I would have expected the link between TUM and DFN to be "inbound" when I click on TUM. But it seems to be consistenly applied, so I guess that was a conscious choice? > The DFN-Verein CA has signed the largest number of intermediate > CA certificates. As you might know it provides certificates for > many German higher education and research institutions. It creates > a unique sub-CA for each institution for which it issues certificates. > Our data set currently contains more than 200 sub-CAs of it. > The DFN does this for administrative reasons. The control of the > private keys of all sub-CAs remains at the DFN and they check > each certificate request. Yes, thanks for noting - that's an important issue that too many blog posts have failed to note. As a matter of fact, I have spoken to the local TUM certification guys a few weeks ago and know the procedure that is applied for DFN certs. It has become a whole lot more strict now and checks are diligent, meaning it is very clear who made the CSR (me) and it is linked to official documentation (passport + my position within staff). Yet it does remain a bit tricky. E.g. DFN requires that the certificate is only issued if the "real person" applying for it (-> me) is "responsible" for the local certification process (our sub-domain). The tricky part is that "responsible" is a vague description. What does it mean? * That I have root on the Web server (I do)? * That I usually do all the cert stuff (no, only for my stuff and if I find the time for other sub-domains)? * That there is an official position in the hierarchy declaring someone responsible (there is not)? So the local guys have to fall back to checking my identity via the intranet and assuming I have the "correct position" within staff. I imagine most DFN certifications are like that. A whole lot better than domain-only validation by e-mail, though. I guess this problem occurs a myriad times in certification. 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] 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] Mobile Traffic Interception (SSL/TLS and VPN)
Hi, Is there a reason you focus primarily on mobile networks? Anyway, you can use 3G sticks and laptops for mobile access, so I assume the following fits your category, too. Crossbear uses a notary approach plus traceroutes from many locations in an attempt to find the attacker: https://github.com/crossbear/Crossbear There is a paper from ESORICS: http://www.net.in.tum.de/fileadmin/bibtex/publications/papers/holz_x509forensics_esorics2012.pdf The difficulty is, of course, that in-band localisation can be countered by powerful and clever attackers. During the beta phase, we collected around 4000 certificate chains - none due to a MitM. Our chief difficulty is actually getting the tool through the Mozilla add-on checks - functionality checks require them to set up a MitM to test themselves... Crossbear is in the process of being integrated with OONI, which should give it more traction: http://www.ooni.nu/ Our hope is that with OONI's advanced arsenal of methods, we can counter some of the attacker's measures. Our promise is also that we publish all our data, minus "anonymisation" where required. One point I really think should be stressed is that such tools should only be used by people who know what they are doing and know that there could be consequences - it is potentially dangerous in some countries to run such things! E.g. one of my colleagues has a network measurement suite for Android, which enjoys quite some popularity on the Android store because it gives you nice feedback about your provider's network and how well you are served. However, they don't do SSL checks, and for good reason: their tool is meant for unsavvy users, too, who might use the tool in certain countries, and they don't want to endanger them. Also, I know the EFF is collecting data with HTTPs Everywhere, but it's opt-in so far and without tracerouting. When I met Peter last December, he also told me that they have not found genuine MitM (i.e. not off-the-shelf middle-boxes). Ralph On 09/09/2012 09:01 PM, Jeffrey Walton wrote: > Hi All, > > Is anyone aware of papers or studies on HTTPS traffic interception in > mobile networks? > > I know Colling Mulliner did a study of HTTP headers and information > leakage in the past. I know we have Trustwave (and I'm not aware of > published results of Mozilla's subsequent actions) and the more > general problem of Public CA hierarchies. I am aware of products like > BlueCoat and Dr. Matt Greene's Interception Proxies page. I believe > the EFF is aggregating data on SSL/TLS at the moment, but the data > will not be released for some time. > > With HTML5 and WebSockets, I believe we can build a smarter client > that can detect interception based on pinning (either public key or > certificate). Is anyone aware of any tools for doing so (perhaps where > aggregated data is offered)? -- 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 ___ 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
[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] 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
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] 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, >> 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, >> 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. > That penalizes CAs who choose to operate ethically and within the > bounds of contractual agreements. Just sayin Well, it's a point one can make. The question is whether pulling someone's root would help the ethical guys so much more, however, or whether having operated un-ethically has given the others so much of an advantage. On the whole, the net gain in security seems better with Marsh's proposal. 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, > Pardon my ignorance. Just tried to Google these, and cannot find them. > Could you give links? Crossbear (disclaimer - it's our own): https://pki.net.in.tum.de/taxonomy/term/3 Slides: https://pki.net.in.tum.de/node/4 Github: https://github.com/crossbear/Crossbear We will submit the XPI to the Mozilla Add-On Store soon (code is fixed according to their feedback; now we need to get the new server up, and install the CA-signed cert Mozilla requires us to have). Moxie's Convergence: http://convergence.io/ Best regards, 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, 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, > 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 ?
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] 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] 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=nl&sl=nl&tl=en&u=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
[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=auto&tl=en&js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&u=http%3A%2F%2Fwebwereld.nl%2Fnieuws%2F108815%2Fweer-certificatenleverancier-overheid-gehackt.html&act=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] 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
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] 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] -currently available- crypto cards with onboard key storage
Hi, > Unfortunately, it also appears to be unbuyable. I tried all three > sources listed on the crypto-stick.org website yesterday: two were > out of stock, while the third said something along the lines of > "low stock - order soon", walked me through the whole ordering process, > then said my order had been submitted -- without ever asking for > payment. > Is there a way to actually get these? I've spoken to Jan of privacyfoundation.de, who seem to have created the thing. He says it should be available again in 2 weeks. There seems to be a waiting list. I am seriously tempted, but the key I use privately is a DSA key (the one for professional use is RSA), and DSA does not seem to be supported. Hm. 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 from our PKI scans now available
Good day, We have uploaded all our PKI data sets from our IMC paper (SSL Landscape). This includes 1.5 years worth of scans from Germany, plus 8 individual scans from locations around the globe (including 2 from China). The download location is: http://pki.net.in.tum.de/ We provide these in the hope that they may be useful to other researchers and interested folks (and we believe there are still some interesting things and gems hidden in the data). 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] 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)
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] 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 <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
[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] 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)
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] 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, 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] 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] 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
[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, >>> 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
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, > 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] PKI "fixes" that don't fix PKI (part III)
Hi, >> But Steve, generic malware runs on your PC or in your browser. If >> they wanted to steal card numbers, they'd steal card numbers today, >> from the browser or by key logging, before the numbers got TLS-ed. >> Since they don't do it now, I don't see any reason to think they'd do >> it if it were easier to steal them other places. > > Do you have any data to support your assertion that malware isn't > stealing credit card numbers from individual PCs? Wasn't there a paper on the underground economy that investigated such things by monitoring drop zones? And they found CC numbers, I thought? I could be wrong. I can't remember the title, but Thorsten Holz was one of the authors (no, not a relative of mine). 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] wont CA hackers CA pin also? and other musings (Re: PKI "fixes" that don't fix PKI (part III))
> And just while I am here there was a paper that proposed a firefox plugin > that would cache certs and warn if one changed unexpectedly. Savy users > would then notice the warning before clicking through, and post the > evidence > on relevant security lists. However the plugin seems to be vaporware > and no > one ever implemented or at least released such a thing which seems rather > odd in the last years SSL/PKI environment. We could really use such a > thing > around now, I'd install it for sure. I am not quite sure... are you referring to Kai Engert's recent proposal? We're working on a (more elaborate) version of 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] 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
[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] 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
Re: [cryptography] ssh-keys only and EKE for web too (Re: preventing protocol failings)
Good day, > This like designing a bicycle with three and half wheels. Any > restructuring that makes DNSSEC useful would make the CAs useless. The > goal of their design is not to make DNSSEC useful, but to make it useful > in a fashion that does not harm the CA business model. With one notable exception: at the current state, Keys-in-DNSSEC is only for authentication of domains. They would replace the "domain-validated" certs that CAs often issue (and I would guess it's their cash cow). CAs could still issue their Extended Validation certs which identify the organization behind the domain by a given trade name. There are not many of these yet, though, presumably due to the pricing. So, in summary, CAs would lose their cash cow, and most but not all of them would probably become useless soon, indeed. Let's see how things develop at Mozilla. 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] 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] ssh-keys only and EKE for web too (Re: preventing protocol failings)
Hi, > You know this is why you should use ssh-keys and disable password > authentication. First thing I do when someone gives me an ssh account. Using keys to authenticate is what I usally do, too. But even if a user decides not to use plain password auth, switching off password-based access globally for all users is unfeasible in many settings. Say you've got a multi-user machine (a cluster, even). If your typical user is not a geek, but a scientist - telling them they need to create a key, send it to you to add to authorized-keys etc. is going to result in much extra work (for you) and frustration (for users). I have seen biologists who have done DNA string comparison with notepad.exe. You need good nerves to support them. There are other scenarios where pure-key auth fails, too - e.g. large testbeds like PlanetLab are bound to re-install their machines every now and then, and user homes can be lost in the process. OK, host keys won't help much here, anyway. I think using keys is super and increases protection a good deal, but it can't really solve all problems mentioned above. Plus, one compromised user account is enough for an attacker to try and increase his privileges. Ralph > ssh-keys is the EKE(*) equivalent for ssh. EKE for web login is decades > overdue and if implemented and deployed properly in the browser and server > could pretty much wipe out phishing attacks on passwords. > > We have source code for apache, mozilla, maybe could persuade google; and > perhaps microsoft and apple could be shamed into following if that was > done. > > Of course one would have to disable somethings (basic auth?) and do some > education - never enter passwords outside of the browsers verifiably local > authentication dialog - but how else are we going to get progress, this is > 2011, and the solution has been known for nearly 20 years - its about time > eh? Maybe you could even tell the browser your passwords so it could > detect > and prevent users typing that into other contexts. > > (*) The aspect of EKE like SRP2 that fixes the phising problems is you dont > send your password to the server, the authentication token is not offline > grindable (even to the server), and the authentication token is bound to > the > domain name - so login to the wrong server does not result in the phishing > server learning your password. > > Adam > >> I can second that with an observation made by several users of the >> German Research Network (DFN), in December 2009. Someone had registered >> a long list of typo domains, i.e. domains like tu-munchen.de instead of >> tu-muenchen.de, and then installed an SSH daemon that would respond on >> all subdomains. >> >> Some users (including a colleague and myself) noticed that they suddenly >> got a host-key-mismatch warning when accessing their machines via SSH - >> and found that they had mistyped the host name *and still got an SSH >> connection*. Neither my colleague nor me had entered our passwords yet, >> but that was only because we were sensitive to host key changes at that >> moment because we had re-installed the machines just a few days before >> the event. >> >> The server that delivered the typo domains was located in South Africa, >> BTW. I don't even know if legal persecution is possible, and I don't >> think anyone attempted. The DFN reacted in a robust way by blocking >> access to the typo domains in their DNS. Not a really good way, but >> probably effective for most users. >> >> The question, after all, is how often do you really read the SSH >> warnings? How often do you just type on or retry or press "accept"? What >> if you're the admin who encounters this maybe 2-3 times day? >> >> (Also, Ubuntu, I believe, has been known to change host keys without >> warning when doing a major update of openssh.) >> >> 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 -- 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] preventing protocol failings
Hi, >> When systems come with good usability properties in the key management >> (SSH, and I modestly suggest ZRTP and Tahoe-LAFS) then we don't see >> this pattern. People are willing to use secure tools that have a good >> usable interface. Compare HTTPS-vs-HTTP to SSH-vs-telnet (this >> observation is also due to Ian Grigg). > > I reject the SSH key management example though. Especially if you've > ever maintained a large number/variety of unix servers running SSH, > where hardware failures, machine upgrades, etc. lead to frequent SSH > key churn. In those cases the only solutions are: I can second that with an observation made by several users of the German Research Network (DFN), in December 2009. Someone had registered a long list of typo domains, i.e. domains like tu-munchen.de instead of tu-muenchen.de, and then installed an SSH daemon that would respond on all subdomains. Some users (including a colleague and myself) noticed that they suddenly got a host-key-mismatch warning when accessing their machines via SSH - and found that they had mistyped the host name *and still got an SSH connection*. Neither my colleague nor me had entered our passwords yet, but that was only because we were sensitive to host key changes at that moment because we had re-installed the machines just a few days before the event. The server that delivered the typo domains was located in South Africa, BTW. I don't even know if legal persecution is possible, and I don't think anyone attempted. The DFN reacted in a robust way by blocking access to the typo domains in their DNS. Not a really good way, but probably effective for most users. The question, after all, is how often do you really read the SSH warnings? How often do you just type on or retry or press "accept"? What if you're the admin who encounters this maybe 2-3 times day? (Also, Ubuntu, I believe, has been known to change host keys without warning when doing a major update of openssh.) 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] 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] 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
