Ben Laurie - Who Pwns The Internet? (Take Two, Part Two)
I actually got these done over the weekend, but I’ve been kinda busy. After taking a more, ahem, principled approach, France seems less dramatic
but still pretty impressive. If you take a close look you’ll see I’ve also had a crack at adding the AS’ owner as well (not 100% reliable, if anyone knows how, let me know!). The UK depends on one less AS than before
and I can do Fiji
I still can’t do the world, though - but now the problem is that dot chokes on the graph.
Ben Laurie - Who Pwns The Internet? (Take 2)
Another interesting way to pwn the Internet is to control the routing of packets to critical nameservers. In practice, Internet routing is done by ASes (Autonomous Systems). If an AS wants to pwn a nameserver on a network it controls, it is a trivial matter: it just redirects the packets to its own nameserver. I’d draw you a picture, but I’m sure Matasano Chargen will do it prettier.
So. I thought it would be instructive to determine which ASes had control over which domains. More fun with dot.
The picture is no longer quite so rosy for the UK, but still, not bad, all things considered.
But France. I don’t know what to say about France. France is surreal. I’ve linked through to a much bigger version because, well, you’ve got to lose yourself in the spiderwebs. The SVG is here, though.
As for Fiji, I’d love to show you Fiji, but the way I’m doing it doesn’t work for Fiji right now. And hence, obviously, not for the whole world, either. Coming soon, I hope.
Ben Laurie - Who Pwns The Internet?
Update: Ben Hyde suggested I should use the (undocumented) “concentrate” option to dot, which certainly tidies up the graphs. So I did.
A remark on the IETF DNS Working Group’s mailing list got me thinking.
Suppose I were the owner of nordu.net (to pick an example at random), then I could take control of sunet.se, for about 25% of Internet users, since one of their four nameservers is server.nordu.net. Similarly, I could then take control of ripe.net for 25% of those 25% (via sunic.sunet.se). One in seven of those guys could fall victim to my ownership of nic.fr via ns-sec.ripe.net, and from there I have complete control of fr (that is, France) - ok, by now, for only a bit under 1% of the Internet, but even so, that’s kinda worrying, don’t you think? And obviously if I own sunet.se then it would be more like 3.5%…
On the other hand, uk does not suffer from this problem: it depends only on nic.uk. Which seems like a much better idea. Anyway, I got to wondering just how bad this problem actually is, which led to me having more fun with dot. So, for a taster, here’s France’s dependencies…
And here’s the UK’s
And here’s Fiji (I include this for Jasvir, who is getting married there soon, and ought to know the terrible risk he’s taking)
And all the top level domains put together
So that one is pretty but a bit hard to digest. Obviously the main news is that there are a lot of domains which could interfere with one or more TLDs!
Another way to think about this is to wonder who could pwn the most TLDs? Well, the answer (after the root, of course) is that nstld.com, gtld-servers.net, com and net come in equal first with 228 TLDs pwnable. Next up is Affilias, through a variety of domains, including org and info, able to control 187 TLDs. After that comes se (Sweden) with 158 and nordu.net, sunet.se, chalmers.se, kth.se, uninett.no, uu.se, edu, no, norid.no, lth.se and uit.no, all able to have a go at 157 TLDs.
Food for thought. Especially if you’re thinking about DNSSEC.
Ben Laurie - Ignorance Transfer Network
SSDSIG recognises that some commonly used languages (e.g. C, php etc.) allow, or even encourage, programming practices that introduce security vulnerabilities. Accepting that in time market forces may encourage the adoption of safer alternatives some members feel that the process needs to be accelerated. The reasons for the continued use of ‘unsafe’ ‘languages and the near-term feasibility of alternatives for commercial systems of modest criticality are complex and ill-understood. This also applies to the slow uptake of more formal methods Further data on this is required.
This is a gem from “Secure Software Development - a White Paper: Software Security Failures: who should correct them and how” by Bill Whyte and John Harrison, from the Cyber Security Ignorance (Knowledge, shurely? Ed) Transfer Network, presumably at the taxpayer’s expense. I hear through the grapevine that they’re planning to spend more of our money to set up a “Secure Software Development Panel” to deliberate on the deep thinking exemplified above. Awesome.
So, what’s wrong with that statement? Firstly, I think we’ve got past the idea that there’s something extra special about buffer overflows as a security issue. Yes, there are many languages that prevent them completely (e.g. PHP, amusingly), but they don’t magically produce secure programs either. Indeed, pretty much all languages used for web development are “safe” in this respect, and yet the web is a cesspit of security problems, so how did that help?
Secondly, the claim that the “reasons are … complex and poorly understood” is a great one to make if you want to spend your life wasting your time on government money, but, well, not exactly true. C is widely used because it is fast, portable, can do anything and has a vast amount of software already written in it that is otherwise difficult to get at. Which is, of course, why PHP is widely used: because it’s one way for the less capable programmer to get at all that C out there. As for “near-term feasibility of alternatives”, well, name an alternative and I’m pretty sure anyone knowledgeable in the field could give you a thorough rundown on its near-term feasibility in an hour or so.
Thirdly, talking about “unsafe” languages implies that there might be “safe” ones. Which is nonsense.
Fourthly, formal methods. Really? The reason there’s slow uptake is because they don’t work. Get with the program, guys!
Ben Laurie - Wave Trust Patterns
Ben Adida says nice things about Google Wave. But I have to differ with
… follows the same trust patterns as email …
Wave most definitely does not follow the same trust patterns as email, that is something we have explicitly tried to improve upon, In particular, the crypto we use in the federation protocol ensures that the origin of all content is known and that the relaying server did not cheat by omitting or re-ordering messages.
I should note, before anyone gets excited about privacy, that the protocol is a server-to-server protocol and so does not identify you any more than your email address does. You have to trust your server not to lie to you, though - and that is similar to email. I run my own mail server. Just saying.
I should also note that, as always, this is my personal blog, not Google’s.
Ben Laurie - Google Wave Federation
Today Google announced Google Wave. I’m not going to talk about Wave itself, just search for it and get a ton of articles. Suffice it to say that it is awesome.
What I want to mention is the Wave Federation Protocol, and in particular, General Verifiable Federation, which is the part my talented colleague Lea Kissner and I worked on. I know I’m a crypto geek, but I think this protocol is pretty interesting, with applications wider than just Google Wave, since it creates a platform for building federated messaging systems in which you do not trust intermediaries.
Lea and I welcome feedback on the protocol, which we are sure is full of mistakes right now, as we were in a bit of a rush to hit today’s deadline…
(And for those friends who are probably wondering now if this is why I went to Australia earlier this year, the answer is, unsurprisingly: yes).
Ben Laurie - ECMAScript 5
When I started working on Caja I had not really plumbed the depths of Javascript (or, as it is more correctly called, ECMAScript 3) and I was very surprised to learn how powerful it actually is. I was also pretty startled by some of the nasty gotchas lurking for the unwary (or even wary) programmer (had I known, perhaps I would never had tried to get Caja off the ground!).
For some time now, the ECMAScript committee has been working on a new version of Javascript which fixes many of these problems without breaking all the existing Javascript that is out there. This seems to me a remarkable achievement; Mark Miller, Mike Samuel (both members of the Caja team) and Waldemar Horwat gave a very interesting talk about these gotchas and how the ES5 spec manages to wriggle around them. I recommend it highly. Slides are available for those who don’t want to sit through the presentation, though I would say it is worth the effort.
Ben Laurie - So You Think Linux is Secure
If you ignore the cyberannoying cybertrend towards cyberusing “cyber” as a cyberprefix for everything, then you’ll notice that our man in DC is lumping Linux and Windows in the same attackable boat.
I guess we should also ignore the fact that he’s commenting on Kylin, which is derived from FreeBSD, which is, pretty much, UNIX - though I am told it doesn’t licence the UNIX trademark, unlike, say, MacOS.
Ben Laurie - Why Privacy Will Always Lose
In social networks, that is.
I hear a lot about how various social networks have privacy that sucks, and how, if only they got their user interaction act together, users would do so much better at choosing options that protect their privacy. This seems obviously untrue to me, and here’s why…
Imagine that I have two otherwise identical social networking sites, one with great privacy protection (GPPbook) and one that has privacy controls that suck (PCTSbook). What will my experience be on these two sites?
When I sign up on GPPbook, having jumped through whatever privacy-protecting hoops there are for account setup, what’s the next thing I want to do? Find my friends, of course. So, how do I do that? Well, I search for them, using, say, their name or their email address. But wait - GPPbook won’t let me see the names or email addresses of people who haven’t confirmed they are my friends. So, I’m screwed.
OK, so clearly that isn’t going to work, let’s relax the rules a little and use the not-quite-so-great site, NQSGPPbook, which will show names. After all, they’re rarely unique, so that seems pretty safe, right? And anyway, even if they are unique, what have I revealed? That someone signed up for the site at some point in the past - but nothing more. Cool, so now I can find my friends, great, so I look up my friend John Smith and I find ten thousand of them. No problem, just check the photos, where he lives, his birthday, his friends and so forth, and I can tell which one is my John Smith. But … oh dear, no friend lists, no photos, no date of birth - this is the privacy preserving site, remember? So, once more I’m screwed.
So how am I going to link to my friends? Pretty clearly the only privacy preserving way to do this is to contact them via some channel of communication I have already established with them, say email or instant messaging, and do the introduction over that. Similarly with any friends of friends. And so on.
Obviously the experience on PCTSbook is quite different. I look up John Smith, home in on the ones that live in the right place, are the right age, have the right friends and look right in their photos and I click “add friend” and I’m done.
So, clearly, privacy is a source of friction in social networking, slowing down the spread of GPPbook and NQSGPPbook in comparison to PCTSbook. And as we know, paralleling Dawkins on evolution, what spreads fastest is what we find around. So what we find around is social networks that are bad at protecting privacy.
This yields a testable hypothesis, like all good science, and here it is: the popularity of a social networking site will be in inverse proportion to the goodness of its privacy controls. I haven’t checked, but I’ll bet it turns out to be true.
And since I’ve mentioned evolution, here’s another thing that I’ve been thinking about in this context: evolution does not yield optimal solutions. As we know, evolution doesn’t even drive towards locally optimal solutions, it drives towards evolutionary stable strategies instead. And this is the underlying reason that we end up with systems that everyone hates - because they are determined by evolution, not optimality.
So, is there any hope? I was chatting with my friends Adriana and Alec, co-conspirators in The Mine! Project, about this theory, and they claimed their baby was immune to this issue, since it includes no mechanism for finding your friends. I disagree, this means it is as bad as it possible for it to be in terms of “introduction friction”. But thinking further - the reason there is friction in introductions is because the mechanisms are still very clunky. I have to use cut’n'paste and navigating to web pages that turn up in my email (and hope I’m not being phished) and so forth to complete the introduction. But if the electronic channels of communication were as smooth and natural as, say, talking, then it would be a different story. All of a sudden using existing communications channels would not be a source of friction - instead not using them would be.
So, if you want to save the world, then what you need to do is improve how we use the ‘net to communicate. Make it as easy and natural (and private) as talking.
Ben Laurie - Three Books
I do most of my reading when travelling (have to find some way to fill in the email gap), and the last three books I’ve read have been notably great. So, in no particular order…
Musicophilia: Tales of Music and the Brain, by the slightly insane Oliver Sacks. I generally enjoy Sacks’ books but they always feel a bit light on science. This book is different - full of fascinating anecdotes backed up by actual research. Most astonishing is the way that music can have a radical affect on people suffering from very debilitating conditions, such as Parkinson’s and Alzheimer’s. Great read.
Old Man’s War by John Scalzi. The cover compares Scalzi to Robert Heinlein. This strikes me as entirely unfair; Heinlein’s books are entirely populated by Heinlein talking to himself (if the character is male) and brainy bimbos that are hoplessly in love with him. Scalzi manages a much grittier and highly engaging version of Starship Troopers (which is admittedly a classic, even if Heinlein did write it).
Finally, Crooked Little Vein by Warren Ellis. A high speed romp through the perverts of the modern age by the world’s unluckiest private investigator in search of the lost, secret, alternative constitution of the United States of America, under the control of a monkey-crap injecting Most Powerful Man In The World. Really. Apparently it was supposed to shock me (said the back cover) but I was mostly laughing.
Ben Laurie - Trust Me, I’m Signed!
The W3C recently announced their spec for signing widgets. Signing things is a good idea, if you’d like to be assured that they come from where you think they come from, or you want to detect tampering. But I would have hoped we were way past statements like this
Widget authors and distributors can digitally sign widgets as a trust and quality assurance mechanism.
If trust and quality were assured by signatures then our lives would be so much easier - but sadly it is not so. Indeed, it is so much not so that CAs, in an amazing piece of marketing, have managed to persuade us that, since they work so poorly for trust, what we should do is pay them even more money to get more robust signatures (a.k.a. EV certificates)!
Anyway, I was sufficiently irritated by this stupidity that I felt it necessary to remark on it. Which prompted this absolutely brilliant response from my friend Peter Gutmann
From the report:
Of signed detected files, severity of the threats tended to be high or severe, with low and moderate threats comprising a much smaller number of files:
Severe 50819
High 73677
Moderate 42308
Low 1099So there you go, signing definitely does provide a “trust and quality assurance mechanism”. If it’s a CA-certified signed rootkit or worm, you know you’ve been infected by the good stuff.
“the report”, by the way, is a large scale study by Microsoft which makes for some interesting reading. In particular, they also acknowledge that even the promise that signatures would at least let you track down the evil bastard that wrote the code has proven empty
Though also intended to identify the signing parties, Microsoft has been unable to identify any authors of signed malware in cooperation with CAs because the malware authors exploit gaps in issuing practices and obtain certificates with fraudulent identities.
Ben Laurie - CodeCon Is Back!
Unfortunately, I can’t be there, but the lineup looks great. The bio-hacking track looks particularly fun.
Not long to go now, less than two weeks. Sign up!
Ben Laurie - More Banking Stupidity: Phished by Visa
Not content with destroying the world’s economies, the banking industry is also bent on ruining us individually, it seems. Take a look at Verified By Visa. Allegedly this protects cardholders - by training them to expect a process in which there’s absolutely no way to know whether you are being phished or not. Even more astonishing is that this is seen as a benefit!
Frame inline displays the VbV authentication page in
the merchant’s main window with the merchant’s
header. Therefore, VbV is seen as a natural part of the
purchase process. It is recommended that the top
frame include the merchant’s standard branding in a
short and concise manner and keep the cardholder
within the same look and feel of the checkout process.
Or, in other words
Please ensure that there is absolutely no way for your customer to know whether we are showing the form or you are. In fact, please train your customer to give their “Verified by Visa” password to anyone who asks for it.
Craziness. But it gets better - obviously not everyone is pre-enrolled in this stupid scheme, so they also allow for enrolment using the same inline flow. Now the phishers have the opportunity to also get information that will allow them to identify themselves to the bank as you. Yes, Visa have provided a very nicely tailored and packaged identity theft scheme. But, best of all, rather like Chip and PIN, they push all blame for their failures on to the customer
Verified by Visa helps protect you from fraudulent claims from cardholders – that they didn’t take part in, or authorise, a payment. Once you are up and running with Verified by Visa, you are no longer liable for chargebacks of this nature.
In other words, if the phisher uses your Verified by Visa password, then it’s going to be your fault - obviously the only way they could know it is if you told them! If you claim it was not you, then you are guilty of fraud; it says so, right there.
Ben Laurie - Mining Is Easy
I’ve written before about the risks involved in exposing the social graph. Now there’s a nice video showing just how easy it is to mine that graph, and other data we give away so freely, using Maltego2. Scary stuff.
Ben Laurie - Capabilities for Python
Guido van Rossum has never been a big fan of this idea, and he recently unloaded a pile of reasoning as to why. Much of this really boils down to the unsuitability of existing Python implementations as a platform for a capability version of the language, though clearly there are language features that must go, too. There’s more on this point from tav, but perhaps his idea of translating Capability Python into Cajita is a more fruitful course…
Anyway, what intrigued me more than the specifics was this statement from Guido
The only differences are at the library level: you cannot write to the filesystem, you cannot create sockets or pipes, you cannot create threads or processes, and certain built-in modules that would support backdoors have been disabled (in a few cases, only the insecure APIs of a module have been disabled, retaining some useful APIs that are deemed safe). All these are eminently reasonable constraints given the goal of App Engine. And yet almost every one of these restrictions has caused severe pain for some of our users.
Securing App Engine has required a significant use of internal resources, and yet the result is still quite limiting. Now consider that App Engine’s security model is much simpler than that preferred by capability enthusiasts: it’s an all-or-nothing model that pretty much only protects Google from being attacked by rogue developers (though it also helps to prevent developers from attacking each other). Extrapolating, I expect that a serious capability-based Python would require much more effort to secure, and yet would place many more constraints on developers. It would have to have a very attractive “killer feature” to make developers want to use it…
There are two important mistakes in this.
Firstly, capability enthusiasts don’t prefer a security model in the sense that Guido is suggesting; we prefer a way of enforcing a security model. App Engine does this enforcement through layers of sandboxing whereas capability languages do it by not providing the untrusted code with the undesirable capabilities. Of course, a side effect of this approach is that capabilities allow far more subtle security models (e.g. “you can only write this part of the file system” or “you can only write files a user has specifically designated” or “you can create sockets, but only for these destinations”) without much extra work and so capability enthusiasts have a tendency to talk about and think in terms of those subtler models. However, Guido’s all-or-nothing model can be implemented easily with capabilities - we don’t have to be subtle if he doesn’t want us to be!
This fallacy causes the second error - because the security model does not have to be subtler, there’s no particular reason to imagine it should take any longer to implement. Nor need it place many extra constraints on developers (I will concede that it must place some constraints because not all of Python is capability-safe). Developers are really only constrained by capability languages in the intended sense: they can’t do the things we don’t want them to do. If the security models are the same, the constraints will be the same, regardless of whether you use sandboxes or capabilities.
Incidentally, I tried to sell the idea of capabilities to the App Engine team several years ago. Given how far we’ve come with Caja in a year, working on a language that is definitely less suited to capabilities than Python is, I would be very surprised if we could not have done the same for Python by now.
Ben Laurie - The Telegraph Show How Not To Do It
I’m a bit stunned that an organisation the size of The Telegraph would store user passwords in plaintext, but, well … they do.
Ben Laurie - DNSSEC: Update
I’ve had feedback since I wrote about DNSSEC that my makefile didn’t work on many platforms. Why Linux and FreeBSD have to use different versions of make I have no idea, but at least it is possible to write makefiles that work on either, if you’re careful. So, I’ve updated the tarball with a version that should work most places. Give it a try.
For the geeky, here’s a diff:
iff -r 94acb807ca7c -r d4a50f0d790c Makefile
--- a/Makefile Sat Mar 07 16:41:39 2009 +0000
+++ b/Makefile Sat Mar 07 16:49:37 2009 +0000
@@ -1,4 +1,6 @@
all: run
+
+.PHONY: named.root anchors.xml isc-dlv.conf
push: dnssec.tgz
scp dnssec.tgz www.links.org:files
@@ -6,7 +8,7 @@
run: named.root rndc.key itar-trusted-keys.conf force-dnssec.conf isc-dlv.conf
named -c named.conf -d 10 -g
-named.root!
+named.root:
rm -f named.root
wget ftp://ftp.rs.internic.net/domain/named.root
@@ -17,7 +19,7 @@
./anchors2keys < anchors.xml > /tmp/itar-trusted-keys
mv /tmp/itar-trusted-keys itar-trusted-keys.conf
-anchors.xml! iana-pgp-keys
+anchors.xml: iana-pgp-keys
# appears to break without -v!
rsync -v rsync.iana.org::itar/anchors.xml rsync.iana.org::itar/anchors.xml.sig .
gpg --no-default-keyring --keyring ./iana-pgp-keys --verify anchors.xml.sig anchors.xml
@@ -46,7 +48,7 @@
gpg --export 1BC91E6C | gpg --no-default-keyring --keyring ./isc-pgp-keys --import
rm isc-key.tmp* 363
-isc-dlv.conf! isc-pgp-keys
+isc-dlv.conf: isc-pgp-keys
rm -f dlv.isc.org.named.conf*
wget http://ftp.isc.org/www/dlv/dlv.isc.org.named.conf http://ftp.isc.org/www/dlv/dlv.isc.org.named.conf.asc
gpg --no-default-keyring --keyring ./isc-pgp-keys --verify dlv.isc.org.named.conf.asc dlv.isc.org.named.confShmooCon News - Badge Contest
Folks we have a winner!This year's badge contest was finally solved by Darth Null. He's winning a ticket to SC2010 and asks to give a shout out to Durak for his awesome squinting abilities which apparently came in handy when reading those barcodes. :)
Congrats Darth Null.
In other news, most of the speaker presos have been posted. If they're not up, it's simply because we haven't received them yet. Videos will follow soon.
Ben Laurie - Native Client
I mentioned Native Client in passing a while back but I didn’t explain what it is…
Native Client is a way to sandbox code without resort to hardware assistance. In short, what it does is statically verify that the code obeys certain rules, and as a result, that the code can only use the interfaces to the rest of the system that the sandbox intends it to use. In other words, it’s a bit like Caja only for native code instead of Javascript. There’s also a version of gcc that produces code that will pass the static validation - which means that pretty much any C (or C++ or Fortran) program can be ported to Native Client with little difficulty.
The Native Client team think the point of Native Client is to allow web apps to have access to high speed code without compromising the security of the user. This is certainly a use, but I find the idea of using it to enforce security in other areas quite interesting, too. For example, with Native Client you could make Mark Seaborn’s Plash both portable and more useful - which Mark has been working on. Of course, before this can be relied on we need to know that NaCl is secure, so it is interesting that the team are offering cash for bugs. You could get paid for playing with NaCl!
Ben Laurie - Doing DNSSEC Right
Since posting about DNSSEC, I’ve had lots of great feedback. So, in no particular order…
Various people have pointed out that DLV is not as bad as I suggested
- DLV is only activated for queries that cannot be proved secure in the cache
- DLV employs aggressive negative caching - it works out whether existing cached NSEC (and NSEC3?) records would prove nonexistence of a record before bothering to query it
- DLV is not used for domains that have trusted keys
Although the second measure is, as I remember it, strictly speaking against the rules (one is not supposed to calculate negative responses from the cache), clearly it can be stipulated that a DLV server must behave when serving NSEC records. Anyway, the net result is that the overhead of DLV is actually quite reasonable. I still say it should be run by every DLVed domain for every other, though. In any case, I am going to switch it on in my own caching resolver.
One thing I wanted to achieve is that a DNSSEC-ignorant resolver downstream of my caching resolver would only get validated results. I tried to do this with the dnssec-must-be-secure configuration option - but this is wrong. That option requires everything to be signed, whereas in DNSSEC it is perfectly OK for a zone to be unsigned so long as its parent delegates to it with no keys (bear in mind that with DNSSEC the nonexistence of the keys is provable, and so this is secure). In fact, BIND 5.3 behaves as I want it to with just DNSSEC enabled. In BIND 5.4 onwards I will have to switch it on with the dnssec-validation option (gee, thanks, ISC for making a backward incompatible change!).
Jelte Jansen operates a domain with various broken entries - this is very handy for testing and I now include its key in my configuration. Note that if you want to see a record that fails validation, then you need to set the CD bit (with dig, +cd or +cd +dnssec if you want to see the DNSSEC records).
Paul Hoffman wonders why I would prefer a signature (for anchors2keys) to download over HTTPS. The reason is that HTTPS download doesn’t really prove the file hasn’t been interfered with - the server will serve anything that happens to be in the filesystem over HTTPS, of course. A signature would be done with a key that I would hope is very strictly supervised, and so is far more trustworthy.
Incidentally, for DNSSEC newbies, one of the interesting features of DNSSEC is that it can be done entirely with offline keys. Proving negatives (i.e. the nonexistence of names) with such a constraint is an interesting problem - and one that I spent three years working on, leading in the end to RFC 5155.
I’m sure everyone is tired of reading my config and makefile, so there’s a tarball here.
Finally, thanks very much to all the experts for the excellent feedback.
Ben Laurie - DNSSEC With DLV
Tony asks “what about DLV?”.
DLV is Domain Lookaside Validation. The idea is that if your resolver can’t find a trust anchor for foo.bar.example.com, then it can go and look in a lookaside zone, hosted at, say, dlv.isc.org, for trust anchors. So, it would first look for com.dlv.isc.org and then example.com.dlv.isc.org and so forth.
So, what do I think of this? It’s another way to solve the problem of having the root not signed.
How does it compare to IANA’s ITAR?
- It’s much less efficient - all those extra lookups for every query.
- It covers more than just TLDs - ITAR could, too, but it doesn’t, for whatever reason.
- There doesn’t seem to be a way to force it, like there is for ITAR. That is, I would like to configure my caching server to force DNSSEC for every domain that exists in DLV, but I don’t believe I can. This makes DLV practically useless, since now only clients that check the AD bit will be aware of the failure.
Also, I think it would be organisationally better if all the participating domains would run DLV for each other, rather than have any single party running it.
Anyway, I modified my setup to also use DLV. Here’s the new Makefile
all: run
run: named.root rndc.key itar-trusted-keys.conf force-dnssec.conf isc-dlv.conf
named -c named.conf -d 10 -g
named.root!
rm -f named.root
wget ftp://ftp.rs.internic.net/domain/named.root
rndc.key:
rndc-confgen -a -c rndc.key
itar-trusted-keys.conf: anchors2keys anchors.xml
./anchors2keys < anchors.xml > /tmp/itar-trusted-keys
mv /tmp/itar-trusted-keys itar-trusted-keys.conf
anchors.xml! iana-pgp-keys
# appears to break without -v!
rsync -v rsync.iana.org::itar/anchors.xml rsync.iana.org::itar/anchors.xml.sig .
gpg --no-default-keyring --keyring ./iana-pgp-keys --verify anchors.xml.sig anchors.xml
anchors2keys:
wget --no-check-certificate https://itar.iana.org/_misc/anchors2keys
chmod +x anchors2keys
iana-pgp-keys:
html2text -nobs http://www.icann.org/en/general/pgp-keys.htm > iana-pgp-keys.tmp
# IANA's PGP keys suck. Clean them up...
awk '/^>/ { print substr($$0,2,100); next; } /^Version:/ { print; print ""; next; } { print }' < iana-pgp-keys.tmp > iana-pgp-keys.tmp2
gpg --import iana-pgp-keys.tmp2
gpg --export 81D464F4 | gpg --no-default-keyring --keyring ./iana-pgp-keys --import
rm iana-pgp-keys.tmp*
force-dnssec.conf: itar-trusted-keys.conf
awk '/^"/ { gsub(/"/, "", $$1); print "dnssec-must-be-secure \"" $$1 "\" true;"; }' < itar-trusted-keys.conf | sort -u > force-dnssec.conf
isc-pgp-keys:
rm -f 363
wget --no-check-certificate https://www.isc.org/node/363
html2text < 363 > isc-key.tmp
awk '/^Version:/ { print; print ""; next; } { print }' < isc-key.tmp > isc-key.tmp2
gpg --import isc-key.tmp2
gpg --export 1BC91E6C | gpg --no-default-keyring --keyring ./isc-pgp-keys --import
rm isc-key.tmp* 363
isc-dlv.conf: isc-pgp-keys
rm -f dlv.isc.org.named.conf
wget http://ftp.isc.org/www/dlv/dlv.isc.org.named.conf http://ftp.isc.org/www/dlv/dlv.isc.org.named.conf.asc
gpg --no-default-keyring --keyring ./isc-pgp-keys --verify dlv.isc.org.named.conf.asc dlv.isc.org.named.conf
mv dlv.isc.org.named.conf isc-dlv.conf
test:
dig -p5453 +dnssec www.dnssec.se @localhost
and here’s named.conf
options {
listen-on port 5453 { 127.0.0.1; };
pid-file "named.pid";
dnssec-enable true;
dnssec-lookaside . trust-anchor dlv.isc.org.;
include "force-dnssec.conf";
};
// obtain this file from ftp://ftp.rs.internic.net/domain/named.root
zone "." { type hint; file "named.root"; };
// include the rndc key
include "rndc.key";
controls {
inet 127.0.0.1 port 1953
allow { 127.0.0.1; }
keys { "rndc-key"; };
};
// include ITAR trust anchors
include "itar-trusted-keys.conf";
// include ISC DLV trust anchor
include "isc-dlv.conf";
Enjoy.
Incidentally, I have enabled “forced ITAR” on my main resolver, so we’ll see how that goes. I haven’t added DLV because, like I say, failure would not be noticed, so what’s the point of all the overhead?
Ben Laurie - What Is DNSSEC Good For?
A lot of solutions to all our problems begin with “first find a public key for the server”, for example, signing XRD files. But where can we get a public key for a server? Currently the only even slightly sane way is by using an X.509 certificate for the server. However, there are some problems with this approach
- If you are going to trust the key, then the certificate must come from a trusted CA, and hence costs money.
- Because the certificate is a standard X.509 certificate, it can be used (with the corresponding private key, of course) to validate an HTTPS server - but you may not want to trust the server with that power.
- The more we (ab)use X.509 certificates for this purpose, the more services anyone with a certificate can masquerade as (for the certified domain, of course).
One obvious way to fix these is to add extensions to the certificates that prevent their use for inappropriate services. Of course, then we would have to get the CAs to support these extensions and figure out how to validate certificate requests that used them.
But I have to wonder why we’re involving CAs in this process at all? All the CA does is to establish that the person requesting the certificate is the owner of the corresponding domain. But why do we need that service? Why could the owner of the domain not simply include the certificate in the DNS - after all, only the owner of the domain can do that, so what further proof is required?
Obviously the answer is: DNS is not secure! This would allow anyone to easily spoof certificates for any domain. Well, yes - that’s why you need DNSSEC. Forgetting the details of DNSSEC, the interesting feature is that the owner of a domain also owns a private key that can sign entries in that domain (and no-one else does, if the owner is diligent). So, the domain owner can include any data they want in their zone and the consumer of the data can be sure, using DNSSEC, that the data is valid.
So, when the question “what is the public key for service X on server Y?” arises, the answer should be “look it up in the DNS with DNSSEC enabled”. The answer is every bit as secure as current CA-based certificates, and, what’s more, once the domain owner has set up his domain, there is no further cost to him - any new keys he needs he can just add to his zone and he’s done.
Does DNSSEC have any other uses? OK, it would be nice to know that the A record you just got back corresponds to the server you were looking for, but if you trust a connection just on the basis that you used the right address, you are dead meat - you’ll need some key checking on top of it (for example, by using TLS) to avoid attacks by evil proxies (such as rogue wifi hotspots) or routing attacks and so forth. For me, the real value in DNSSEC is cryptographic key distribution.
Ben Laurie - Using DNSSEC Today
It’s been a while since I’ve properly paid attention to developments in the DNSSEC world, so I was surprised to learn that IANA now has an “Interim Trust Anchor Repository“. No need to wait any longer for the root to be signed, you can configure yourself to do DNSSEC right now.
Here’s how. First off, grab this Makefile
all: run
run: named.root rndc.key itar-trusted-keys.conf force-dnssec.conf
named -c named.conf -d 10 -g
named.root!
rm -f named.root
wget ftp://ftp.rs.internic.net/domain/named.root
rndc.key:
rndc-confgen -a -c rndc.key
itar-trusted-keys.conf: anchors2keys anchors.xml
./anchors2keys < anchors.xml > /tmp/itar-trusted-keys
mv /tmp/itar-trusted-keys itar-trusted-keys.conf
anchors.xml! iana-pgp-keys
# appears to break without -v!
rsync -v rsync.iana.org::itar/anchors.xml rsync.iana.org::itar/anchors.xml.sig .
gpg --no-default-keyring --keyring ./iana-pgp-keys --verify anchors.xml.sig anchors.xml
anchors2keys:
wget --no-check-certificate https://itar.iana.org/_misc/anchors2keys
chmod +x anchors2keys
iana-pgp-keys:
html2text -nobs http://www.icann.org/en/general/pgp-keys.htm > iana-pgp-keys.tmp
# IANA's PGP keys suck. Clean them up...
awk '/^>/ { print substr($$0,2,100); next; } /^Version:/ { print; print ""; next; } { print }' < iana-pgp-keys.tmp > iana-pgp-keys.tmp2
gpg --import iana-pgp-keys.tmp2
gpg --export 81D464F4 | gpg --no-default-keyring --keyring ./iana-pgp-keys --import
rm iana-pgp-keys.tmp*
force-dnssec.conf: itar-trusted-keys.conf
awk '/^"/ { gsub(/"/, "", $$1); print "dnssec-must-be-secure \"" $$1 "\" true;"; }' < itar-trusted-keys.conf | sort -u > force-dnssec.conf
and this named.conf
options {
listen-on port 5453 { 127.0.0.1; };
pid-file "named.pid";
dnssec-enable true;
include "force-dnssec.conf";
};
// obtain this file from ftp://ftp.rs.internic.net/domain/named.root
zone "." { type hint; file "named.root"; };
// include the rndc key
include "rndc.key";
controls {
inet 127.0.0.1 port 1953
allow { 127.0.0.1; }
keys { "rndc-key"; };
};
// include ITAR trust anchors
include "itar-trusted-keys.conf";
and run make. After a while, with luck, you’ll have named with trust anchors configured (you can see which ones by looking at itar-trusted-keys.conf) running on port 5453 (and the rndc control channel on port 1953).
You can test it with, for example
$ dig -p5453 +dnssec www.dnssec.se @localhost
; < > DiG 9.3.5-P2 < > -p5453 +dnssec www.dnssec.se @localhost
;; global options: printcmd
;; connection timed out; no servers could be reached
[ben@euphrates ~/svn-work/peim/doc]
$ dig -p5453 +dnssec www.dnssec.se @localhost
; < > DiG 9.3.5-P2 < > -p5453 +dnssec www.dnssec.se @localhost
;; global options: printcmd
;; Got answer:
;; ->>HEADER< <- opcode: QUERY, status: NOERROR, id: 41806
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.dnssec.se. IN A
;; ANSWER SECTION:
www.dnssec.se. 300 IN CNAME dnssec.iis.se.
www.dnssec.se. 300 IN RRSIG CNAME 5 3 300 20090302080001 20090220080001 62658 dnssec.se. y0JcIxVunryZRaccDX2PteGyxCQ2dlfeoeDYNcoPKCryBa9vGWuNJwNa MhqzMmLLr5N4SbQsIL8YrQ8+l/wBFebXB6I8dJ8OWDmz6OqihSzkDYB/ qFwEWLQi49RfCuE6Qai/PnPh0Om+7guyL15fLTMh3PtZso4axt23/vqG 5RI=
dnssec.iis.se. 3600 IN CNAME www.iis.se.
dnssec.iis.se. 3600 IN RRSIG CNAME 5 3 3600 20090302135501 20090220135501 6477 iis.se. ebDsJcmZRHkq5Y+SLTIC2Iey3fNBj7r3bk3TAeyJPXtgFE6YJqAtJmv4 m5Sn1jDZhidnI0NWyPz5dUwDFfzVnJN/DH+CZJuiynKQge4inIGt8Dzk ybaq7JSoFkHABAu+IBbVKwR4+TW92tzv2CgzdtBIsQnuOn+CQMpmuz+N rFk=
www.iis.se. 3600 IN A 212.247.7.210
www.iis.se. 3600 IN RRSIG A 5 3 3600 20090302135501 20090220135501 6477 iis.se. aIOT7U/CRcFi3CcgaHp6EqV8JHkODodQM0Pg7CKh1gby4/8pGnqABDiU +4bg8/zDlAzVUz6o4j5sjIg5uS2A1ODJzp+UodXyVL9/Q8eBfZGSDuOa FPwK9jUxj6P1iXIqoMyeAS1PG1rFgSim/xpZLhJK2l5ScQ/1+Pq6SG8T Lgc=
;; Query time: 1236 msec
;; SERVER: 127.0.0.1#5453(127.0.0.1)
;; WHEN: Sun Feb 22 14:07:14 2009
;; MSG SIZE rcvd: 602
Because we have forced DNSSEC on the trusted domains (this is done in the included file force-dnssec.conf), the fact we get an answer at all tells us that the signatures checked out - but also the fact that the AD bit is set (”;; flags: ... ad ...“) tells you that the signatures were validated by the caching server you just set up. Note that pretty much no application will check for the AD bit, so DNSSEC is only really going to help if you have it forced on, as in this configuration. Obviously if you want to run this for real, you should run it on standard ports and point all your resolvers at it. Then you get the benefits of DNSSEC today with no application changes.
Note that ordinary queries (i.e. ones that don’t request DNSSEC) are also validated by the server, but we don’t see the DNSSEC stuff in the response
$ dig -p5453 www.dnssec.se @localhost
; < > DiG 9.3.5-P2 < > -p5453 www.dnssec.se @localhost
;; global options: printcmd
;; Got answer:
;; ->>HEADER< <- opcode: QUERY, status: NOERROR, id: 2159
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 0
;; QUESTION SECTION:
;www.dnssec.se. IN A
;; ANSWER SECTION:
www.dnssec.se. 100 IN CNAME dnssec.iis.se.
dnssec.iis.se. 3400 IN CNAME www.iis.se.
www.iis.se. 3400 IN A 212.247.7.210
;; AUTHORITY SECTION:
iis.se. 86200 IN NS ns3.nic.se.
iis.se. 86200 IN NS ns.nic.se.
iis.se. 86200 IN NS ns2.nic.se.
;; Query time: 1 msec
;; SERVER: 127.0.0.1#5453(127.0.0.1)
;; WHEN: Sun Feb 22 14:41:25 2009
;; MSG SIZE rcvd: 147
I notice that the AD bit isn’t set, though, which seems like a bug.
Ben Laurie - Identification Is Not Security
The New York Times have an article about the Stanford Clean Slate project. It concludes
Proving identity is likely to remain remarkably difficult in a world where it is trivial to take over someone’s computer from half a world away and operate it as your own. As long as that remains true, building a completely trustable system will remain virtually impossible.
As far as I can tell, Clean Slate itself doesn’t make this stupid claim, the NYT decided to add it for themselves. But why do they think identification is relevant? Possibly because we are surrounded by the same spurious claim. For example…
- We need ID cards because they will prevent terrorism.
- We shouldn’t run software on our Windows box that isn’t signed because that’ll prevent malware.
- We should only connect to web servers that have certificates from well-known CAs because only they can be trusted.
But…
- The guys who crashed the planes were all carrying ID. Didn’t help.
- The guys who blew up the train in Spain were all carrying ID. Didn’t help.
- People get hacked via their browser all the time. Did signing it help?
- What does it take to sign code? A certificate, issued by a CA…
- What does it take to get a certificate? Not much … proof that you own a domain, in fact. So, I can trust the server because the guy that owns it can afford to pay Joker $10? And I can trust the code he signed? Why?
Nope. Security is not about knowing who gave you the code that ate your lunch - security is about having a system that is robust against code that you don’t trust. The identity of the author of that code should be irrelevant.
ShmooCon News - The ShmooCon Crew
is wiping the sleep from their eyes and slowly getting back to reality. Thanks to everyone who made it out to DC. We hope you had a good time.Speaker presentations and videos will be online soon. Videos will take a bit longer than the slides, but we will get them up there eventually.
Please remember to leave your feedback at feedback.shmoocon.org or, if you'd rather, shoot us an email. The online review system will be available for one more week, so get your reviews in before it's too late.
Thanks again folks. Keep watching this spot for more post-con wrap up.
Ben Laurie - Crypto Craft Knowledge
From time to time I bemoan the fact that much of good practice in cryptography is craft knowledge that is not written down anywhere, so it was with interest that I read a post by Michael Roe about hidden assumptions in crypto. Of particular interest is this
When we specify abstract protocols, it’s generally understood that the concrete encoding that gets signed or MAC’d contains enough information to unambigously identify the field boundaries: it contains length fields, a closing XML tag, or whatever. A signed message {Payee, Amount} K_A should not allow a payment of $3 to Bob12 to be mutated by the attacker into a payment of $23 to Bob1. But ISO 9798 (and a bunch of others) don’t say that. There’s nothing that says a conforming implementation can’t send the length field without authentication.
No of course, an implementor probably wouldn’t do that. But they might.
Actually, in my extensive experience of reviewing security-critical code, this particular error is extremely common. Why does Michael assume that they probably wouldn’t? Because he is steeped in the craft knowledge around crypto. But most developers aren’t. Most developers don’t even have the right mindset for secure coding, let alone correct cryptographic coding. So, why on Earth do we expect them to follow our unwritten rules, many of which are far from obvious even if you understand the crypto?
ShmooCon News - Day 2
and all seems to be going well. Over 1300 people are currently present.Ben Laurie - A Good Use of the TPM?
Back when the TPM was called Palladium I made myself unpopular in some circles by pointing out that there were good uses for it, too, such as protecting my servers from attackers.
Whether that is practical is still an interesting question - it’s a very big step from a cheap device that does some cunning crypo to a software stack that can reliably attest to what is running (which is probably all that has saved us from the more evil uses of the TPM) - but at a recent get-together for privacy and anonymity researchers George Danezis and I ran, Mark Ryan presented an interesting use case.
He proposes using the TPM to hold sensitive data such that the guy holding it can read it - but if he does, then it becomes apparent to the person who gave him the data. Or, the holder can choose to “give the data back” by demonstrably destroying his own ability to read it.
Why would this be useful? Well, consider MI5’s plan to trawl through the Oyster card records. Assuming that government fails to realise that this kind of thing is heading us towards a police state, wouldn’t it be nice if we could check afterwards that they have behaved themselves and only accessed data that they actually needed to access? This kind of scheme is a step towards having that kind of assurance.
ShmooCon News - Ads make us happy
Another ShmooCon vid from PSKL... This was sent to us with the oh so funny comment that it was just in time for that critical "all the tickets have already been sold" phase of advertising.You can also check out previous year's video fun in our archives. (Please be aware - we no longer offer free admission in exchange for ads, but we might hook you up with some special swag.)
ShmooCon News - ShmooCon Labs
The application period for ShmooCon Labs is officially over. We've got about 30 attendees this year plus a few vendor reps and the labs staff. They'll all work pretty much non-stop to make sure the con network is up and running before ShmooCon begins on Friday - the idea being that they learn a thing or two (or three) along the way as well.A few other things of note:
There are still a few (very few) rooms left at the Washington Hilton should anyone still be needing a hotel. Those of you who are local and maybe just want to stay in DC for Saturday night - this is a good option for you. Call 202-483-3000 and reference the code SHC for a great rate.
There is a ShmooCon Twitter feed and to (again) answer the question everyone keeps asking - yes, it really is us.
Lastly - it's snowing today in the DC area. Be sure to check those weather forecasts before heading this way.
Ben Laurie - Caja on the Yahoo! Developer Network
Here’s a nice (and brief) article about developing for the Yahoo! Application Platform, and, in the process, covering some of the benefits and gotchas of Caja.
Caja enforces the W3C standards for JavaScript, HTML, and CSS, regardless of browser (!).
Yes, you read correctly, if your code cajoles, it will run in Firefox and IE. This is amazing and its value cannot be overestimated.
ShmooCon News - Less than 2 weeks remaining...
The schedule is posted, speakers selected, and we're headed into the final pre-con moments.It's not to late to gen up a Barcode ShmarCode entry or to warm up your TF2 and Halo trigger fingers - so get busy!
Ben Laurie - United Are Bastards
I just accidentally went through the whole booking process on United’s US site. There were many seats in Economy Plus. But I couldn’t book because I don’t have a US address. So, I went through it all again on the UK site. Guess what? Economy Plus is allegedly booked solid. Bastards.
ShmooCon News - Keynote Speaker - Matt Blaze
We're happy to announce that this year's keynote speaker will be Matt Blaze.Since 2004, Matt Blaze has been a computer science professor at the University of Pennsylvania;
prior to that, he spent a dozen years on the research staff of AT&T; (Bell) Labs. Matt's work focuses on cryptography and its applications, trust management, physical and human scale security, designing secure systems, and networking and distributed computing. He's particularly interested in security related to public policy, such as cryptography policy (key escrow), wiretapping and surveillance, electronic voting, and secrecy in science.
Ben Laurie - Will GPLv3 Kill GPL?
I started looking at the LLVM project today, which is a replacement for the widely used gcc compiler for C and C++. My interest in this was prompted by thinking once more about static analysis, which it is pretty much impossible to use gcc for, and is likely to remain so, because Stallman opposes features which would enable it.
Anyway, being an optimist, I thought perhaps the interest in LLVM and clang (the C/C++ front end) were prompted by a sudden surge of interest in open source static analysis, but asking around, it seems it is not so.
The primary motivator appears to be GPLv3. Why? Well, here’s a few facts.
- GPLv3 is not compatible with GPLv2. Don’t take my word for it, believe Richard.
- Linux is, of course, famously GPLv2 without the upgrade clause, and hence GPLv3 incompatible.
- FreeBSD, for example, are unlikely to accept software into the core that is GPLv3. No new licence can be used without core team approval and I am told this has not been given for GPLv3 and is not likely to be.
- Commercial users of open source have always been a bit twitchy about GPLv2, but they’re very twitchy indeed about GPLv3. And don’t tell me commercial users are not important: these days they are the ones financing the development of open source software.
GCC is, apparently, going to move to GPLv3 - it says here that GCC 4.2.1 would be the last version released under GPLv2 (which is a bit rum, because I just checked GCC 4.4 and it is GPLv2. What gives?).
So, pretty clearly, there’s a need for a C/C++ compiler that is not GPLv3, and this, it would seem, is the real driver for LLVM.
Obviously this issue is not confined to GCC. As more software moves to GPLv3, what will the outcome be? Will the friction between GPL and other licences finally start persuading projects that free != GPL, and that BSD-style licences better suit their needs? Or will it just be that GPLv3 fails to make headway? We can only hope for the former outcome.
ShmooCon News - Overflow Rooms at the Hilton
We've been able to secure a limited amount of overflow rooms at the Hilton Washington for Friday and Saturday nights. To make your reservation call 202-483-3000 and reference either the code SHC or just ask to be put on the ShmooCon block.Ben Laurie - Verisign Demonstrate Their Lack of Integrity
On the 7th of May, 2008, Debian fixed the now famous OpenSSL Weak PRNG bug. So, I’m pretty stunned to read, over 9 months later, Verisign’s newsletter saying
Earlier this year, the Debian organization discovered a vulnerability that weakened the system’s Random Number Generator, making SSL encryption predictable
Err, earlier last year. A lot earlier.
They go on to say
We have identified which customers were affected. If one of your customers has a weak certificate, we’ll send you details on how to resolve the situation, with templates for talking to customers about the problem and policies for replacing weak certificates.
Affected certificates must be replaced as soon as possible. VeriSign will begin revoking any certificates that are still affected by this vulnerability in early 2009.
Well, that’s mighty big of you, Verisign! You’ve left your customers exposed to this problem for over 9 months - even if they replace the certificates, they are still vulnerable to attack, of course - and now that 75% of vulnerable certificates have expired, you’re beginning to think you might start revoking them. Soon. Let me guess - does “early 2009″ mean May? I’m sure you wouldn’t be so cynical as to wait until there were no certificates to revoke, would you?
By the way, if anyone gets the details on “how to resolve the situation” from Verisign I’d be very interested to see them. I wonder how much the resolution will cost?
Update: A former Verisign employee pointed out Verisign’s values
…We exercise integrity in all aspects of our business. And with ferocious drive, we take the initiative to carry out all actions with exceptional execution by acting decisively…
If this is ferocious, I wonder what Verisign’s version of laid-back looks like?
Ben Laurie - Radio 4 on Open Source and Creative Commons
The Radio 4 programme “In Business” was all about free stuff and Creative Commons last night. Because of Auntie’s lameness, this link will presumably only work for a week.
Update: find the podcast here.
ShmooCon News - ShmooCon Twitter Feed
Yes. It's really us. :)We'll be using this feed during the con as another way to share information about any schedule changes, contest updates, etc. The same information will be posted on this website and available at the registration desk so don't feel like you'll be missing out on something if you don't want to subscribe.
Ben Laurie - Jabber Pain
For a while, its been apparent to me that Jabber was occasionally dropping messages. Last week I finally got annoyed enough to investigate it in earnest.
Unfortunately, I started off on entirely the wrong track, and blamed GTalk (sorry, guys!) - but much investigation later, with help from some very patient friends (you know who you are: thanks!), I found that it was my own Jabber server that was to blame.
However, it was not an easy journey. First of all, how do you tell messages are being dropped? I am pretty certain my server has been dropping messages since before Christmas - i.e. at least four weeks, and I am fairly certain it has been doing it ever since I first built it - which must be a year or two now. Could it be that it could drop messages for that long and no-one noticed? It seems to me, in retrospect, that it could! A wise friend of mine once said, “you know, 90% of what we say to each other could be completely different and it would make no difference”. This is even more true for IM. We send messages out. Sometimes we get answers. Sometimes we don’t. If we don’t, well, the other guy was away, or not interested, or got busy and forgot to respond. It’s fine. It was probably one of the 90%. When it’s one of the 10%, well, then we say it again. And this time we get an answer, and we’re both happy. So, it you can go on for years and not notice that stuff is missing.
It wasn’t until I started badgering my friends to tell me when they thought messages were going missing that it became clear that they were, indeed. And not just a few - a lot! I now know that it was dropping about 50% of incoming messages (i.e. messages sent to me) and no outgoing messages. God knows what kind of rude bastard my friends think I am by now! An interesting feature is that it would drop them in batches - i.e. drop for 5 minutes, forward for 5 minutes, drop for 5 minutes and so on. If it had been every second message it would have been apparent sooner, I suspect, because the conversation would be quite choppy.
But even knowing that messages were being dropped was not the end of the story. How do you figure out what is to blame? In the typical scenario, because I run my own server, there are at least 3 connections and 4 pieces of software that could be at fault.
- The other guy’s client,
- the connection from that to their server,
- their server,
- the connection from their server to my server,
- my server,
- the connection from my server to my client,
- my client
As I said above, I started at the wrong end - with GTalk. With some help, it became apparent that GTalk was unlikely to be to blame (and because it was upstream from the other guy’s client, we could eliminate that, too). So the next easiest target to look at was my server - which I did, with the help of tcpdump and Wireshark, though investigation was complicated by both OTR and SSL, which make it very hard to interpret and track messages. Luckily the server-to-server connection was in plain text (which is one reason I use OTR), so it could be done, with difficulty - particularly since it turned out that my jabber daemon was the culprit - so I could see messages coming in in the traces, and no corresponding activity in the server-to-client connection. Sometimes.
To cut a long story short, after much poking at my existing jabber server, which was jabberd14, I decided to replace it with jabberd2. But before I did that, I wanted to be really sure that jabberd14 was to blame, and that jabberd2 would fix it. So, I wanted the Jabber equivalent of ping. To my amazement, there appears to be no such thing! There is a Jabber ping extension but I can’t find anything that uses it. Which is the final reason I am writing this blog post - I wrote a pair of scripts that will do a Jabber ping test, Ping.pl and Pong.pl, feel free to use them. And if you are using jabberd14, I’d really like to know if you, too, get message drops…
I was planning to make them count and produce statistics and such, but I got lazy. Since you can see both ends, eyeballing them is enough to let you know what’s going on - Ping does count how many it got back, though, so you can leave it running without watching it all the time. To run them, you need two Jabber accounts, one on the suspect server and the other elsewhere. You can run them like this:
./Ping.pl suspect-server.com account1 password1 account2@otherserver.org
./Pong.pl otherserver.org account2 password2
Pong will actually answer multiple Pings running simultaneously. Ping pings every 10 seconds. Output should be reasonably obvious. Because Jabber does store-and-forward, Ping will ignore Pongs from a different session. And because they use different resources, you can use the same account at both ends, if you want. Like I say, I’d be really interested to hear from anyone that experiences drops - a couple of hundred pings was always enough to show them when I was testing.
Oh yeah, and the good news: jabberd2 has now answered over 500 pings without a single drop. So, if you felt ignored, I hope things will improve!
ShmooCon News - Hotel Block Sold Out
Well...We were just getting ready to make an announcement that the room block would be closing on the 16th and there were a limited amount of rooms left. In fact, they had just increased the number of rooms available to us to give more of you the ability to get in on the rate.
A bunch of you must have been busy today because we just got an email telling us that the block is completely sold out. While this is good news for us, we realize some of you might still be in need of a place to stay. We'll do some research into nearby hotels and post something here soon.
Ben Laurie - CodeCon Comes Back
After an absence of several years (the last one was in 2006), CodeCon is back!
CodeCon has long been one of my favourite low-cost conferences, focusing on stuff that actually works. And I hear this year it won’t be in a nightclub, which may be bad from a beer point of view, but is good from the sticky floor perspective…
Check out the CFP.
ShmooCon News - Sponsor Shout Out
A quick mention of our current list of sponsors:- PGP
- Tenable
- Aspect Security
- Tenacity Solutions, Inc.
- ERNW
- G2,Inc.
- AccessIT
- Quest Consultants
- InGuardians
- PaulDotCom
- Core Security
- Ponte Technologies
Beyond giving us money (helps to pay for the extra fun con stuff like Saturday night), our sponsors are bringing some cool stuff to their tables this year. Be sure to stop by and check out all the contests and nifty con swag .
ShmooCon News - Schedule
No it's not up yet, but should be by the end of the week. For your travel purposes though here are the rough start and stop times.Reg will open on Friday around noon with the opening talks scheduled for 2 or 3. Conference will run until Sunday afternoon - we try and have everyone out the door and things cleaned up by 4pm at the latest.
See you soon!
ShmooCon News - More Speakers Posted
As the confirmations roll in, we're posting more and more speakers to the site. We should have the full line-up posted soon.Please remember those hotel reservations. They can be made online using the code SHOSHOA.
Also ShmooCon Labs applications will be processed this week so if you want to attend and haven't sent us an email yet - do so soon.
ShmooCon News - ShmooCon Ads
First ShmooCon ad of the year that we've seen. We love this stuff. :)ShmooCon News - Ticket Sales - Done!
And forgive us we if admit to being glad that it's over for this year... ;)Lots of news still to come. Watch this space for announcements on speakers, our keynote address, and other events.
In the meantime, if you're planning on coming to DC anyway, you might think about heading out a day or two early and attending DC*BSDcon in it's inaugural year. It's being held at the Wardman in the days just prior to ShmooCon. If you're a BSD fan you might want to check it out.
As always, we encourage you to make your hotel reservations sooner rather than later. The room block is only open for a few more weeks. Code to use is "shoshoa."
Thanks everyone and Happy New Year!
ShmooCon News - Ticket Count
Number of tickets going up for sale tomorrow, Dec 28, at noon eastern:50 Early Bird ($100)
100 Open Reg ($175)
15 I Love ShmooCon ($300)
ShmooCon News - The news you've been waiting for...
Ticket Sales Round 2.1 will open this Sunday, Dec 28 at noon EST. The cart has been revamped, the server updated, and we're confident (enough) to go ahead and try again.A limited amount of tickets will be available. Exact numbers are still TBD - we'll post that information tomorrow.
Should you miss out on this round there's still Round 3 on Jan 1. At noon people. Eastern Standard.
ShmooCon News - Light at the end of the tunnel...
and no...we don't think it's an oncoming train (as someone joked with us today).We're busy contacting everyone who wrote in and should have everything resolved soon.
It definitely looks as though there are tickets left to sell in this round. We don't know the absolute final count yet, but we're getting there. We'll post again once we do know and will let you at that time what day we'll open up sales for those leftover barcodes. We'll give at least 24 hours notice, probably more. Thanks again to everyone for your patience.
In other conference news, here's a few other reminders for all of you:
Please make your hotel reservations soon! Book your room using our code: shoshoa.
Don't forget about the barcode contest - we're super excited to see what people dream up. For that matter, you should check out all of the events scheduled to take place.
That's it for now. Next update will probably be to announce a sales date.
ShmooCon News - Getting there...
We have now made an attempt to contact all barcode recipients. We know that many of you are still patiently waiting to hear from us. Your turn is coming - we promise.We know it is seeming to take a long time and for that we are sorry. Some of our processes had to be revamped to accommodate the solutions we are putting in place. That took a few days to finish. Remember too, that ShmooCon is a volunteer-run organization and many of those involved in the clean up have other responsibilities during the day - ones that actually pay them. :)
Progress is being made though, we promise.
The icanhaztickets@shmoocon.org email address will be shut down at 9PM EST tomorrow, 12/6.
If you have not already emailed in and are one of those who entered in CC information and hit submit on 12/1, you have 24 hours to contact us.
If you have already sent us this info, please DO NOT email us again.
ShmooCon News - Slow Progress
Just a quick update for the evening. We are *this* close to having contacted all barcode recipients. We'll finish up that process tonight. More detailed information will be posted tomorrow.ShmooCon News - Ticket status update
A fair bit of time was spent yesterday reading through your emails and comparing that information to what we saw in our records. Three groups were formed: Those who actually received a barcode, those who hit submit but then saw nothing, and those who were just "somewhere in the cart" when all this took place.We're going to deal with those who actually received a barcode first. By far this is the easiest group to both track and confirm. Once that process is finished we will evaluate how to move forward with the second and third groups.
I'm going to again ask for patience. Please don't email asking for updates. We will be posting information here as we go along. Any specific questions can be addressed as we begin to make contact with you.
ShmooCon News - You guys rock..
Seriously. Judging by the number of emails we've received, I think we've heard from just about everyone who got past the submit process. We're extremely thankful that you all are such a nice crowd. The majority of your messages have been ones of understanding and outright kindness. Silly Hackers... Don't worry. Your secret is safe with us.We'll be ready to start contacting folks tomorrow. If you don't hear from us the first day, please be patient. Look for updates here before emailing us again. We're working this pretty hard, and again, our goal is to be as fair as possible based on the records we have.
Thanks again. Feel free to throw a shmooball (or two or three) at us once con time gets here.
ShmooCon News - Ticket Sales - Shut Down
Wow.So a number of things went wrong but perhaps the largest (and the reason for shutting down the system) - is that ticket sales were made live without un-stubbing the process that would actually charge your card. Bottom line - no purchases were actually made. Your credit information went nowhere. And you were not charged.
Problem the second. The box was completely overloaded. Way way more than expected - and this after we already made some changes in the code in an attempt to reduce this from happening.
So let's talk some solutions. We have records of everyone who made it to the point at which they actually submitted their credit card information. We will make an attempt to contact everyone we have records for and provide you a means of actually purchasing a ticket (and or tickets depending on what the logs tell us). However, to help us out, if you could please contact us at icanhaztickets@shmoocon.org to help us track tickets, that would be great. Include the name and email address you were using at the time of attempted purchase. Once we get through this process we will evaluate how many tickets are actually left for this round and reopen ticket sales to the masses. We will give 24 hours notice on this.
Again - this is going to take us a few days to get through. Responses to any of the ShmooCon email addresses will likely be delayed but we will get back to you as soon as we can.
As to the load on the box? We're going to tweak that even more too.
We are, as you can imagine, horribly embarrassed and extremely sorry for this turn of events. We will do our best to handle it fairly for all involved. Thank goodness for logs.
- Heidi
ShmooCon News - Round 2 - Ticket Sales
Lots happening in ShmooCon land...Round 2 of ticket sales begins tomorrow, December 1 at noon EST. You might want to start getting ready now...
CFP closes tomorrow as well. Talks received after 11:59pm EST will not be considered for ShmooCon 2009. That means you've got just over 24 hours to wow us with your submission.
On that note, our first round of speakers has been accepted and notified. We're still waiting to hear back from a few of you but here's the line up so far:
Scott Moulton - Ten Cool Things You Didn't Know About Your Hard Drive!
Chema Alonso, et al - Re-Playing with (Blind) SQL Injection
Travis Goodspeed and Joshua Gourneau - Building Wireless Sensor Hardware and Software
More detailed information will be posted to the website later this week.
Good luck tomorrow!
Ben Laurie - Crypto Everywhere
Recent events, and a post to the OpenID list got me thinking.
Apparently rfc2817 allows an http url tp be used for https security.
Given that Apache seems to have that implemented [1] and that the
openid url is mostly used for server to server communication, would
this be a way out of the http/https problem?I know that none of the browsers support it, but I suppose that if the
client does not support this protocol, the server can redirect to the
https url? This seems like it could be easier to implement that XRI .Disclaimer: I don’t know much about rfc2817
Henry
[1] http://www.mail-archive.com/dev-tech-crypto@lists.mozilla.org/msg00251.html
The core issue is that HTTPS is used to establish end-to-end security, meaning, in particular, authentication and secrecy. If the MitM can disable the upgrade to HTTPS then he defeats this aim. The fact that the server declines to serve an HTTP page is irrelevant: it is the phisher that will be serving the HTTP page, and he will have no such compunction.
The traditional fix is to have the client require HTTPS, which the MitM is powerless to interfere with. Upgrades would work fine if the HTTPS protocol said “connect on port 80, ask for an upgrade, and if you don’t get it, fail”, however as it is upgrades work at the behest of the server. And therefore don’t work.
Of course, the client “requires” HTTPS because there was a link that had a scheme of “https”. But why did was that link followed? Because there was an earlier page with a trusted link (we hope) that was followed. (Note that this argument applies to both users clicking links and OpenID servers following metadata).
If that page was served over HTTP, then we are screwed, obviously (bearing in mind DNS cache attacks and weak PRNGs).
This leads to the inescapable conclusion that we should serve everything over HTTPS (or other secure channels).
Why don’t we? Cost. It takes far more tin to serve HTTPS than HTTP. Even really serious modern processors can only handle a few thousand new SSL sessions per second. New plaintext sessions can be dealt with in their tens of thousands.
Perhaps we should focus on this problem: we need cheap end-to-end encryption. HTTPS solves this problem partially through session caching, but it can’t easily be shared across protocols, and sessions typically last on the order of five minutes, an insanely conservative figure.
What we need is something like HTTPS, shareable across protocols, with caches that last at least hours, maybe days. And, for sites we have a particular affinity with, an SSH-like pairing protocol (with less public key crypto - i.e. more session sharing).
Having rehearsed this discussion many times, I know the next objection will be DoS on the servers: a bad guy can require the server to spend its life doing PK operations by pretending he has never connected before. Fine, relegate PK operations to the slow queue. Regular users will not be inconvenienced: they already have a session key. Legitimate new users will have to wait a little longer for initial load. Oh well.
Ben Laurie - Keyczar!
When I joined Google over two years ago I was asked to find a small project to get used to the way development is done there. The project I chose was one that some colleagues had been thinking about, a key management library. I soon realised that unless the library also handled the crypto it was punting on the hard problem, so I extended it to do crypto and to handle key rotation and algorithm changes transparently to the user of the library.
About nine months later I handed over my “starter project” to Steve Weis, who has worked on it ever since. For a long time we’ve talked about releasing an open source version, and I’m pleased to say that Steve and intern Arkajit Dey did just that, earlier this week: Keyczar.
Keyczar is an open source cryptographic toolkit designed to make it easier and safer for developers to use cryptography in their applications. Keyczar supports authentication and encryption with both symmetric and asymmetric keys. Some features of Keyczar include:
- A simple API
- Key rotation and versioning
- Safe default algorithms, modes, and key lengths
- Automated generation of initialization vectors and ciphertext signatures
When we say simple, by the way, the code for loading a keyset and encrypting some plaintext is just two lines. Likewise for decryption. And the user doesn’t need to know anything about algorithms or modes.
Great work, guys! I look forward to the “real” version (C++, of course!).
Ben Laurie - Call Me Nostradamus!
Looking for links for the previous article on OpenID, I came across this post, from May 2007.
Sun’s House of Cards?
Sun have a plan. In short, they’re going to have an OpenID provider which authenticates Sun employees only.
That is, so long as you trust your DNS. Or, in other words, if you aren’t using any untrusted networks. How often does that happen?
And in the comments we find
Well, obviously it all has to run over TLS to be useful. Which should address those issues, right?
Comment by Tim Bray — 8 May 2007 @ 22:43 |Edit This
“Obviously”. Yes, that’s obvious to you and me, but really you need to write down the rules.
Plus, of course, X.509 certs haven’t proved to be the most invulnerable things in the world.
Comment by Ben — 10 May 2007 @ 8:10 |Edit This
Now, if that isn’t prophetic, I don’t know what is.
Ben Laurie - NYT Doesn’t Quite Get It, Hilarity From OpenID
The New York Times’ Randy Stross has a piece about passwords and what a bad idea they are (sorry, behind a loginwall). So far, so good (and I’ll admit to bias here: I was interviewed for this piece, and whilst there’s no attribution, what I was saying is clearly reflected in the article), but Stross weirdly focuses on OpenID as the continuing cause of our password woes, because, he says, it is blocking the deployment of information cards, which will save us all.
Now, I am no fan of OpenID, but Stross is dead wrong here. OpenID says nothing about how you log in. It is not OpenID’s fault that the login is generally done with a password - that blame we must all accept collectively.
And whilst I firmly believe that the only way out of this mess is strong authentication, information cards are hardly the be-all and end-all of that game. They certainly have a way to go in usability before they’re going to be taking the world by storm. Don’t blame OpenID for that.
In the meantime, Scott Kveton, chair of the OpenID Foundation board, reacts:
The OpenID community has identified two key issues it needs to address in 2008 that Randy mentioned in his column; security and usability.
I just have to giggle. I mean, apart from those two minor issues, OpenID is pretty good, right? He forgot to mention privacy, though.