Researchers at Applidium have published some interesting findings about the protocol used by Siri. For every request the user makes to Siri, the iPhone 4S sends the compressed audio of the request to servers at Apple to first be converted to text. Then, it is mapped into commands that the iPhone can understand, and then sent back to the device.

This protocol sits on top of HTTPS, and intercepting or spoofing it requires either a valid SSL certificate for guzzoni.apple.com or a way to convince the device to accept your certificate as valid. One must also hijack DNS so that the phone would think guzzoni.apple.com is at an IP address that you control. The post from Applidium covers the details pretty well, so let’s talk about what one could do with this.

I’ll start with the positive and creative things that can be done. In theory, it should be easy to port Siri to any device if you have a valid iPhone 4S ID. Any device capable of recording audio and running an “app” with Internet connectivity should work. This includes laptops, tablets, smartphones, even refrigerators and washing machines.

You can even build your own Siri server for existing Siri capable devices to talk to. This can be utilized for home use for commands like “turn on the light”, or “close the garage door.” This can also be done within a business: imagine integrating such a system with your everyday tools to make workflow voice interactive. Anything you can script, you can ask Siri about.

Read the rest of this entry »

With World IPv6 Day upon us, I thought I’d take a moment to expound on the IPv6 transition so far and what we are likely to see in the near future.

IPv6 is like a dead animal lying on the road: a group of kids gathered around it, sticks in hand negotiating who gets to poke it first. You have ISPs and carriers waiting for customers to demand it and all of their vendors to support it, you have hardware and software vendors waiting until IPv6 becomes more important to customers than the features their customers are willing to pay extra for then you have other businesses that have to weigh IPv6 activities against anything else on the plates of their IT departments. Given the current security/breach climate, it is no surprise to me that IPv6 is not making huge strides.

Finally, you have the end user. Without a killer app, there is very little motivation for end users to demand IPv6. Grandma wants pics of the grandkids, what protocol those images arrive over makes no difference to her. At the moment, the hassle of converting just doesn’t seem worth it for most users.

I myself went through the process of converting. I updated my personal website, email setup, a tunnel to my home network, and even got myself certified at ipv6.he.net. After all was said and done, the only thing I had to show for it was my newfound ability to go to ipv6.google.com or pass the various IPv6 tests. The cool factor of this lasted for 10 minutes. By the time it turned off, I found myself wondering why I wanted to maintain two sets of firewall rules plus RA and DHCP (not all of my devices at home support IPv6) and deal with the extra troubleshooting and maintenance. Having been through the exercise, now I already know what devices I need to replace and what services need to be updated and have a much better idea about how to keep things secure. When the time comes, it should be easier the second time around.

Read the rest of this entry »

If you consult the Internet Assigned Numbers Authority (IANA) IPv4 assignment page, you will notice that there are no remaining “UNALLOCATED” blocks in IPv4. This comes as part of the chain of events leading up to IPv6 migration and was triggered by the assignment of 179/8 to LACNIC and 185/8 to RIPE NCC a few days ago. These two assignments took the global unallocated pool down to five /8s, just enough for each regional Internet registry (RIR) to get one last block before the party ended.

The IPv6 proponents are using this as a call to action to spur the IPv6 transition. I look at the IANA list and wonder why the “Class E” space is still marked “RESERVED.” RFC 1700 declares 240/4 as “Class E addresses are reserved for future use.” I for one can’t think of a better “future” use for this space than to extend the useful life of IPv4 while we work out the kinks in IPv6. IANA allocated nineteen /8s in 2010 so the sixteen /8s that 240/4 comprises wouldn’t buy the global pool much more than a year. There are also concerns that some existing hardware and software won’t accept IP addresses in the 240/4 range though IPv6 suffers from the same problem.

I tend to agree with Dave Siegel at Global Crossing that the exhaustion of the global IPv4 pool is NOT a reason to panic. It should be used as an opportunity to review your IPv6 plans (You do have an IPv6 plan, right?) and make sure that you are on track. ISPs and RIRs both have a good deal of IP space stockpiled. If you are projecting the need for more IP space in the near future, this is not a good time to procrastinate on your request.

In line with Data Privacy Day this Friday, Facebook announced its rollout of Secure Sockets Layer (SSL) capability for all of its services. Facebook has taken some heat for its lack of SSL support, especially with the release of FireSheep, which we covered here. Facebook does warn that encrypted pages will take slightly longer to load, which is a small price to pay for the added security.

According to the official Facebook post, there should soon be a check box titled Secure Browsing (https) under the Account Security section of Account Settings. This setting specifies that all future connections be redirected to HTTPS. It should be noted that this rollout has just begun and that this option is not yet available to everyone. It may take some time before this option is made available to everyone.

In the absence of the Secure Browsing setting, manually changing the URL to https:// seems to work but with mixed results. The main profile page will successfully load with no problems. Unfortunately, things start to get sketchy from there. Many links are relative and will keep the user in the secure browsing environment. Other links, however, are absolute and remove the protection of SSL. Hopefully, Facebook will fix these issues soon or at least makes it more clear when SSL support is not available.

Facebook also warned that some third-party applications and their own chat functionality currently don’t work if SSL is enabled. Users should be aware of this and take appropriate precautions if they can’t use SSL for those reasons.

At least two tools have been released in the past week that make stealing Facebook, Twitter, or just about any other Web 2.0 account while you surf from your local coffee shop a drag-and-drop proposition. From a technical standpoint, it has never been difficult to do. With these new tools, however, it becomes trivial. I’im talking about something my grandmother can use.

Idiocy bills itself as a warning shot to people browsing the Internet unsecurely. The premise is simple—it is a 130-line Python script that will sniff open wireless networks for Twitter login cookies and will use that information to hijack any session it finds and to send a single Tweet. The message is simple—I browsed Twitter unsecurely on a public network and all I got was this lousy tweet. http://jonty.co.uk/idiocy-what.

The other tool, Firesheep (detected as HKTL_FYRSNIFF), is a more sophisticated tool. It is a Firefox plug-in that is capable of collecting session cookies from a much larger set of sites and that gives you the ability to fully hijack the session into your own browser. The list of sites that it can attack is even extensible by the user.

Read the rest of this entry »