April 2012 archive

WordPress 3.3.2 Out With Security Fixes – Upgrade Now!

Wordpress orgIf you are a user of WordPress, as I am for several of my sites, you really should update your site to WordPress 3.3.2. If you take a look at the Codex page for the release:
http://codex.wordpress.org/Version_3.3.2

You'll note that the release is pretty much all about security fixes to underlying libraries and other aspects of the software.

While yes, I'm a "security guy" who may care about these kind of things more than others, the reality is that I'm in the "content business" and I want my content always to be available. Having my site taken down by attackers is NOT a way to do that.

So I always upgrade WordPress - particularly when there are security issues involved.

The beautiful thing is that you should just be able to go into your site and click the "Update automatically" link to make it happen. Yes, backup your database first to be safe... but do go in and do the update.

Particularly because if the upgrade fixes "cross-site scripting attacks", you have to know that attackers are out there right now trying to exploit those attacks against sites that have NOT yet upgraded.

So don't be a target... upgrade!


If you found this post interesting or useful, please consider either:


Want to understand DNSSEC? Watch this excellent 1-hour elearning video.

Want to understand DNSSEC and how it can help secure the Internet?  The folks at SIDN, the registry behind the .NL country code top-level domain (ccTLD), have put together a truly excellent 1-hour video e-learning session available in either English or Dutch at:

http://www.dnsseccourse.nl/

The course touches on the basics of DNS then explains the role of DNSSEC, how it works and the steps that need to be done.  It also has some solid points about things you need to think about and also business impacts of DNSSEC.  Perhaps most usefully, the course includes a number of animations that really illustrate how DNSSEC works, as well as a few examples of what DNS zone files really look like with DNSSEC involved.

The video’s target audience is really for domain name registrars who would enable DNSSEC for their customers (domain name registrants). However, SIDN created the video in such a way that it’s quite a useful introduction to DNSSEC for anyone interested in the topic.

I found the elearning user interface quite nice in that you could skip around between sections, return to past sections, stop/start the sections and skip ahead as well.  The “Notes” tab also includes the text of what was said in each section, which I could see being quite valuable particularly for those for whom English or Dutch is not a native language.  It was also nice to have the video introductions from Bert Hubert interspersed with the slides and animations.

DNSSEC course

My one issue with the user interface was that when a section was done you have to press the “Next” button to move on to the next section.  Given that there are 74 sections, I soon found myself wishing there was an “auto-advance” that would just keep on playing the video.  A minor quibble, perhaps. Otherwise I was quite pleased.

On a technical level, my only issue was that the course oversimplified one aspect of the DNSSEC infrastructure. It states that a copy of the public key for your zone (the DNSKEY record) is stored in the parent zone as the DS record.

In fact, the DS record is a digest of the DNSKEY, as defined in section 5 of RFC 4034 and shown as an example in section 5.4.

I realize that the video couldn’t go into every detail and had to simplify some aspects in order to keep it within the presentation timeframe.  I also realize that the idea is quite similar. However, if someone left this video thinking that the DS record in the parent zone was simply the DNSKEY record from the child zone, they would be extremely surprised when the do a “dig” on the records for a DNSSEC-signed domain and see that they are quite different.

Regardless, I still see this as an outstanding introduction to DNSSEC and commend the folks at SIDN for creating this elearning video.  If you want a quick way to understand DNSSEC, definitely do check it out!

 

Civic.io – Mark Headd’s new site on Civic Hacking and Open Government

My friend Mark Headd passionately wants to open up government - and to do so through code. I've known him for years as the author of the VoiceInGov / Vox Populi blog where he has been writing about mashups and so many other ways to open up access to government information via telephony. Back in November 2010, Mark joined me and the others on the rocket ship known as Voxeo and did outstanding work for the Voxeo Labs and Tropo teams.

But just as my passions altered my career last fall, as of just a short time ago Mark is now the Director of Government Relations at Code for America and, with that, changing a bit about the way he is writing online.

His new site is civic.io, where he will be writing on "civic hacking, civic startups and the future of open government". He's brought over to the site many of his relevant older posts, so he's already got a solid amount of content.

The work he and the others at projects like Code For America are doing is incredibly important to help with keeping our networks open. I'm looking forward to reading more of what Mark is up to in the time ahead - and certainly wish him all the best in this new endeavor.

Oh, and of course you can follow him on Twitter at @civic_io.

Civic io


If you found this post interesting or useful, please consider either:


Facebook To Provide IPv6 Access For Developers On May 18th

Facebook logoAs of May 18, 2012, developers working on Facebook applications will have access over IPv6 to Facebook’s development platform to test their applications out in preparation for World IPv6 Launch.  In a blog post this week, Facebook’s Eric Osgood writes:

With the World IPv6 Launch coming on June 6th 2012, Facebook has committed to enabling IPv6 access for our users on most of our HTTP and HTTPS endpoints. Based on the results of last years IPv6 test on June 8th 2011, we are confident that enabling IPv6 on our platform will be a success. On May 18th, we will be enabling IPv6 on beta.facebook.com ahead of World IPv6 Launch to give our developer community time to discover issues and report bugs back to us.

IPv6 is vital because the Internet’s original addressing system (IPv4) has run out of free space. Since every device on the Internet relies on a unique address to communicate, we must transition to IPv6 which provides over 4 billion times more addresses than IPv4. IPv6 will ensure everyone (users, ISPs, governments, and companies) have direct and open access to the Internet.

We are thrilled to see this news out of Facebook and  look forward to learning of developers ensuring their applications work over IPv6!

 

 

Creating an IPv6-only Wi-Fi Network For the Global INET Event

Global INETThis weekend, hundreds of people will begin converging in Geneva, Switzerland, for the Global INET event, celebrating the Internet Society’s 20th Anniversary, listening to visionary keynotes and collaborating with others to shape the future of the Internet.

While there, attendees will also have the opportunity to ensure their laptops and mobile devices are configured correctly for IPv6 – and…

…to use an IPv6-only Wi-Fi network.

Once connected to the IPv6 Wi-Fi network, attendees will be able to test their IPv6 connectivity by visiting an IPv6-only website (and entering a contest while there). To help attendees, we will be providing there onsite a document explaining briefly how to configure IPv6 on typical laptops and mobile devices.

To create this IPv6-only WiFi network for a large event like this, our Internet Society IT team worked with  Swisscom.  This diagram shows the overall architecture (click on the image for a larger version):

For the Internet gateway, we’ve configured a Cisco 2901 in dual stack mode. To restrict the network to IPv6-only, we have disabled IPv4 DHCP.  A few other notes:

Wi-Fi configuration:

For the Wifi access points we are using four Apple AirPort Extreme access points. These devices support connectivity on both the 2.4GHz and 5GHz bands. 802.11b/g/n is supported on the 2.4GHz band and 802.11a/n on the 5GHz band. Based on the IEEE 802.11n specification, AirPort Extreme uses a technology called multiple-input multiple-output (MIMO) to transmit multiple data streams simultaneously. A maximum of 50 WiFi users can be associated with each access point.

IPv6 LAN configuration:

DHCPv6 is not configured on the LAN. We use IPv6 address auto configuration (SLAAC) to discover the IPv6 parameters. The host uses the link prefix  + the EUI-64 address (MAC address + FF:FE) to construct the IPv6 address.

If you are going to be at Global INET, please do give the IPv6-only Wi-Fi network and try and let us know how it works for you.   We’re looking forward to seeing Global INET attendees using the network next week!


Note: Peter Godwin of the Internet Society’s IT team contributed to this article.

Where Are The IPv6-Only Wi-Fi Routers And Access Points?

Question ?In trying to set up an IPv6-only Wi-Fi network for a test environment in my home office, I ran across an interesting stumbling block:

You can’t turn IPv4 OFF on typical Wi-Fi access points or routers!

Now, this does make a certain degree of sense for consumer-grade equipment.  Providing such a setting is simply one more thing for someone to mess up – and generate support calls into the router manufacturer about how they can’t get on the network, can’t access email, etc., etc.  So I get it… the consumer equipment manufacturers are operating on commodity margins and need to minimize support inquiries.

It may also be quite honestly that… no one has asked for it!  We’ve been living in a world where IPv4 was the only option for so long that equipment product managers may not even be thinking about the desire for an IPv6-only Wi-Fi network.  “Why would you ever want to do that?”

But I do want to do that – and I imagine I’m not alone among those of us working on deploying IPv6. I want a Wi-Fi test network that is IPv6-only. No IPv4 at all.  Just IPv6… which then lets me connect to an IPv6 server and experiment with various different transition technologies.  Plus I get to see which apps work in an IPv6-only environment and which don’t.  I want a Wi-Fi network to experiment and play in the land of pure IPv6.

However, in searching online and looking through documentation of various Wi-Fi routers and access points, I’ve yet to find any off-the-shelf routers/APs that allow IPv4 to be disabled on an interface.

Yes, multiple people have suggested that I could hack the OpenWRT or DD-WRT code to roll my own AP without IPv4… and yes, I certainly could, and maybe that winds up being my only choice, but I’d personally rather hack on other projects than my Wi-Fi infrastructure.  However, that may be what I do.

Have any of you seen Wi-Fi routers or access points where you could disable IPv4 on the Wi-Fi network and only use IPv6?  Even better, an AP that lets me create multiple networks and have one of them be IPv6-only?

Or have any of you already hacked OpenWRT or similar code to be IPv6-only?

I’d love to hear what options folks have found (and would love to publicize them here).

Image credit: a_ninjamonkey on Flickr

The post Where Are The IPv6-Only Wi-Fi Routers And Access Points? appeared first on Internet Society.

Where Are The IPv6-Only Wi-Fi Routers And Access Points?

Question ?In trying to set up an IPv6-only Wi-Fi network for a test environment in my home office, I ran across an interesting stumbling block:

You can’t turn IPv4 OFF on typical Wi-Fi access points or routers!

Now, this does make a certain degree of sense for consumer-grade equipment.  Providing such a setting is simply one more thing for someone to mess up – and generate support calls into the router manufacturer about how they can’t get on the network, can’t access email, etc., etc.  So I get it… the consumer equipment manufacturers are operating on commodity margins and need to minimize support inquiries.

It may also be quite honestly that… no one has asked for it!  We’ve been living in a world where IPv4 was the only option for so long that equipment product managers may not even be thinking about the desire for an IPv6-only Wi-Fi network.  “Why would you ever want to do that?”

But I do want to do that – and I imagine I’m not alone among those of us working on deploying IPv6. I want a Wi-Fi test network that is IPv6-only. No IPv4 at all.  Just IPv6… which then lets me connect to an IPv6 server and experiment with various different transition technologies.  Plus I get to see which apps work in an IPv6-only environment and which don’t.  I want a Wi-Fi network to experiment and play in the land of pure IPv6.

However, in searching online and looking through documentation of various Wi-Fi routers and access points, I’ve yet to find any off-the-shelf routers/APs that allow IPv4 to be disabled on an interface.

Yes, multiple people have suggested that I could hack the OpenWRT or DD-WRT code to roll my own AP without IPv4… and yes, I certainly could, and maybe that winds up being my only choice, but I’d personally rather hack on other projects than my Wi-Fi infrastructure.  However, that may be what I do.

Have any of you seen Wi-Fi routers or access points where you could disable IPv4 on the Wi-Fi network and only use IPv6?  Even better, an AP that lets me create multiple networks and have one of them be IPv6-only?

Or have any of you already hacked OpenWRT or similar code to be IPv6-only?

I’d love to hear what options folks have found (and would love to publicize them here).

Image credit: a_ninjamonkey on Flickr

Excellent Interactive Map of DNSSEC Support by Swedish Municipalities

This morning we learned via a tweet about this very cool interactive map of the status of DNSSEC support by Swedish municipalities. Sweden has by far been one of the leaders world-wide in implementing DNSSEC and the fact that such a map like this can even be constructed is a great testimony to all the excellent work happening there.

Kudos, too, to whomever created this map and site. Other than seeing it was funded by the great folks at .SE it’s not clear from the site who created it.  We love seeing visualizations like this and look forward to seeing more such maps for other parts of the world.

Comcast Rolling Out Home Gateway Support for IPv6 – And Nothing’s Controversial About a /64…

Outstanding news for Comcast subscribers last week at the North American IPv6 Summit! Comcast’s John Brzozowski, chief architect for IPv6 and distinguished engineer, indicated that Comcast was now moving its IPv6 support from just supporting single computers to supporting entire home networks. In a Network World article titled “Comcast is first U.S. ISP to offer IPv6 to home gateway users“, Carolyn Duffy Marson reports on Brzozowski’s comments, including the fact that the service is already available in two cities.

This step is critical for adoption of IPv6 by home users as most home users do typically have some type of home gateway providing Internet access to the many devices within their home.  Prior to this step, you could only connect a single computer for IPv6 access.  While this certainly made sense for Comcast as they started testing out their production IPv6 support, it is great to see them moving on to support the home gateway use case that the majority of Comcast customers will have.

Comcast also very helpfully is providing a website showing which home gateway devices will work with IPv6 (look for checkmarks in the IPv6 column):

http://mydeviceinfo.comcast.net/

My only real issue with the article is this sentence:

In a somewhat controversial move, Comcast is giving each of its home networking users what’s called a /64 block of IPv6 addresses, which represents more than 18 quintillion IPv6 addresses…

There’s actually nothing “controversial” about providing a /64 block as that’s the standard allocation of IPv6 addresses to a router.  This enables all devices within the router’s network to use “Stateless Address Autoconfiguration (SLAAC)” to automatically create their IPv6 addresses by combining the “router advertisement” with the devices own MAC address.   It’s what makes IPv6 “just work” for devices.

However, I completely understand why the author would write that.  When I first started digging into the details of IPv6 several years back I had the same reaction – aren’t we setting ourselves up for failure by starting out already giving up half our address space to the host portion?

Coming from the address-constrained IPv4 space – and just with an engineer’s view of efficiency, it seemed insanely wasteful!  And in some cases where there are always going to be a limited number of devices on a network, it certainly may be wasteful… but for the majority of networks using a /64 enables SLAAC and also makes room for innovation.  As we look at the sensor-based “Internet of Things”, we may find use for that very large address space.  Time will tell, but in the meantime the /64 allocation is just how things are done in IPv6 – welcome to the world of IP address abundance!

Aside from that minor note, it was great to see this article and congrats to Comcast for rolling out this support for IPv6 home gateways!  As World IPv6 Launch nears, this will definitely enable more people to get connected!

 

Jitsi Is The First VoIP Softphone To Support DNSSEC

JitsiWith it’s 1.0 release last week, the Jitsi soft phone became the first VoIP client I know of to support DNSSEC. Jitsi, formerly known as the “SIP Communicator”, is available for Windows, Mac OS X or Linux from:

jitsi.org

Jitsi has a great range of features including support for voice and video calls, chat/IM, desktop sharing, conference calls, wideband audio and much more. It works with the SIP (Session Initiation Protocol) and XMPP (Jabber) protocols and connects to common services like GoogleTalk, AIM, Yahoo!Messenger, Facebook chat, etc.  It’s also free and the source code is all available.

Jitsi has supported SIP and XMPP over IPv6 for quite some time now, but with this new release adds support of DNSSEC courtesy, I learned, of some funding from the NLnet Foundation and the University of Applied Sciences and Arts Northwestern Switzerland (FHNW). The DNSSEC code itself was implemented by Ingo Bauersachs from this university.

Essentially what Jitsi now does if you enable DNSSEC is to validate the signing of the SRV records in DNS that provide the address information for the remote end of the SIP or XMPP connection.

To step back and explain a bit further, if Alice wants to call Bob (to be cliche), and she knows his SIP address is “sip:bob@example.com”, her SIP client, IP-PBX or other SIP server (depending upon configuration) is going to perform a DNS lookup on “example.com” to retrieve the relevant SRV records. These records will provide the IP address(es) of the SIP server on Bob’s side. Alice’s SIP software will then connect to those IP addresses to send the appropriate SIP INVITE to start a conversation with Bob.

But how does Alice’s software know that the SRV records retrieved from DNS are correct? How can it know that they were not tampered with?

What if she is trying to call her bank and an attacker is redirecting her to another SIP server where there is a similar call center or IVR? (Okay, leaving aside the fact that at this moment you may not be able to make SIP connections to many banks… but that is changing slowly.)

Enter DNSSEC.

If the “example.com” domain is signed via DNSSEC, including all the SRV records, then the VoIP client can validate that the SRV records are in fact correct and the connection can be made knowing that it is to the intended recipient based on the SIP address.

From a configuration point of view, there has been one more screen added to Jitsi’s preferences:

Jitsi dnssec

At this moment there is no documentation on the Jitsi site about the DNSSEC features (they are working on it… and open to any offers of assistance! ;-) , but I asked Ingo Bauersachs about the configuration of the resolver. His reply was this:

Libunbound, the library Jitsi is using, is validating the DNSSEC chain, but it’s not a full resolver. Queries for DNSKEY, DS, etc. are sent to the OS’s resolver, or if configured, to the “Custom name servers”.

The option to override the OS’s default resolver is there because during development, the only servers supporting all relevant record types were from DNS-OARC and Verisign.

The choice not to use libunbound as a fully recursive resolver was performance and that it’s for one simply not the job of an application to perform recursive DNS queries.

In my own case, I’m running a local instance of DNSSEC-Trigger and that is my operating systems default resolver. I’ll be able to perform the DNSSEC resolution without any issues. Ingo also indicated that the table at the bottom of the Preferences panel will fill up with domains as you start to connect to sites (any sites – DNSSEC-signed or not). You can then specify what the DNSSEC-related behavior is for individual domains.

That’s how this all works, of course, when you have both publicly accessible SIP servers with SRV records – and DNSSEC signatures on those records. There may not be a whole lot of those sites out there quite yet, but having apps like Jitsi available will only help.

If you have a SIP- or XMPP-based VoIP or IM system (or “Unified Communications” system to use the appropriate marketing buzzwords) where you can sign your domain with DNSSEC, definitely check out Jitsi and see how it works. And as you have it working, I’d certainly love to hear from you and perhaps feature some examples in future blog posts.

The Jitsi team is also very interested in feedback and indicated that sending messages to the “dev” mailing list (and joining that list if you want) would be the best way to proceed.

I’m also personally interested in trying this out in a test environment… if you’ve got a SIP server with a domain that is DNSSEC-signed, please drop me a note as I’d like to try calling you. :-)

Kudos to the NLnet Foundation for funding this work and to Ingo Bauersachs and the Jitsi team for implementing it all. I’m looking forward to seeing where this goes!

P.S. Wikipedia has a decent page on SRV records if you want to know more about these record types.