Archive for category Internet
Returning to Zero continues the story of the Zed.Kicker botnet, and the efforts of white hat hacker Mick O’Malley and his friends to contain and destroy it.
A lot has changed in those six years, especially in internet security and privacy.
Six years ago, not to many people outside certain internet security areas had ever heard of a ‘botnet’, a robot network of compromised computers. Botnets back then had tens of thousands of computers, which was why my fictional Zed.Kicker botnet with millions of devices was so powerful. Today, there are many botnets with millions.
Six years ago, few also understood how dangerous a large botnet can be, with their distributed denial of service DDOS) attacks. Botnets routinely launch attacks today.
Six years ago, only a paranoid few thought about pervasive surveillance, and the notion that without taking measures, all our activities online were being tracked and recorded by governments, our own and others. In this post-Snowden era (three years ago, believe it or not), we know the extent and the invasiveness of the surveillance. (Just for fun, here is a photo of me asking Edward Snowden a question via a WebRTC video link after a screening of CITIZEN FOUR at IETF-93).
Six years ago, cybercrime was a rarity, including ransomware and other threats. Today is is unfortunately common.
Six years ago, many of us were concerned about our communication security: how to encrypt and authenticate or messaging and calls. The ‘Security and Other Lies’ blog entries in Counting from Zero reflect this emphasis. Today, privacy is a bigger concern, and how to minimize the meta-data about our communication and messaging is discussed in the ‘Privacy and Other Mirages’ blog entries in Returning to Zero.
One thing that hasn’t changed in six years is the excitement and nervous energy involved in launching a new book. I can’t wait for Returning to Zero to be available and to get feedback and comments!
And looking forward another six years? Who knows…
Returning to Zero, the sequel to Counting from Zero, and the second book in the Mick O’Malley series will be available on Amazon as Kindle and Paperback editions on February 25, 2017.
After my first look, I’m back exploring the other apps on my Blackphone. See my Full Disclosure of my friendship with the Silent Circle guys and my work on the ZRTP security protocol used in the Blackphone. Today I’m trying out the interestingly named Disconnect Secure Wireless application, basically a VPN (Virtual Private Network) service. Given that this app is all about making connections, having it called “Disconnect” is a little odd. The name probably makes more sense with their ad and malware blocking services. According to their FAQ: “Secure Wireless uses AES-256 to encrypt data to or from your device. Secure Wireless also enforces Diffie-Hellman for key agreement/exchange which provides perfect forward secrecy (PFS).” which is all good. Out of the box, the Disconnect Secure Wireless application takes you through a short tour of the service. Essentially, it is a VPN service that can be easily enabled/disabled and also automatically enabled/disabled based on a preference for a given network. It seems this application is only available on Android, as the iOS version seems to not be a VPN but be an add blocker of some type. Disconnect Secure Wireless starts off with a free service of 512MB per month which you would blow through very quickly if you used it for everything. By putting the Blackphone activation code into the Account screen, you get 2GB per month, which seems reasonable if you use it sparingly, such as WiFi hotspots or when traveling.
Using it is easy – tapping the middle of the screen starts the VPN. When turning it on, you get two warnings:
The first reminds you that, since this is a VPN service, all the device network packets will be routed through it. Essentially, this app is a Man-in-the-Middle (MitM), although hopefully a trusted MitM. You must tap the “I trust this application.” in order to proceed.
The next warning tells you that once turned on, the VPN will always run for this network, until you turn it off. This is a good warning from a usage perspective.
Next you get a Connecting message and the middle of the screen turns green and indicates bandwidth usage for the month to date. One interesting thing – while I did notice the bandwidth usage rise with normal web browsing, I did not notice it go up during lengthy Silent Circle voice calls. In general, for a VoIP call such as silent circle, you can use up to 1MB per minute, depending on the codec. Perhaps the packets from Silent Circle aren’t tallied by Disconnect against the VPN quota. Or maybe I just got lucky…
The VPN speed seemed reasonable, although a speed test during a Saturday afternoon isn’t exactly scientific. Compared to just my WiFi over Cable Modem, it was slower, of course. The VPN has a location configuration for North America, Europe, or Asia. I’ll need to try it other times of the day to see how well it works.
The default search is also provided by Disconnect, although this can be changed. A DNS failure in the browser automatically brings up a https://search.disconnect.me search window for the failed string. It does show the Google “G” symbol, however, indicating that it is not an actual search engine. Instead, as described here, Disconnect Search forwards you request to the engine of your choice (Google, Bing, Yahoo, DuckDuckGo, or Blekko) and anonymizes it. You can also use it in any browser at https://search.disconnect.me/ So, Disconnect Secure Wireless does what it promises to on the Blackphone.
Your suggestions, comments and questions are most welcome!
I am very proud of the Third Edition of the WebRTC Book that came out just a few weeks ago. My co-author Dan and I have been working on it for months, and it is always exciting to launch a new edition!
We worked feverishly during the IETF-89 meeting in London to get all the updates finished – all the APIs, protocols, and standards referenced should be up to date as of then (first week in March). We also had a lot of fun testing and doing screen captures of the new Demo Application, which now utilizes the WebRTC data channel for Real-Time Text (RTT) between the two browsers. I’ll write another day about RTT and how much fun it is compared to normal texting or instant messaging in another post. For us, to make use of the data channel APIs and protocols and show the interoperability between Chrome and Firefox browsers was a lot of fun as well.
The Demo Application also can now utilize a TURN server for enhanced NAT traversal. In some circumstances, NATs or firewalls will prevent a direct peer-to-peer Peer Connection from being established between two browsers, and a relay in the cloud is needed. If the Demo Application fails for you, try reloading the page adding a ?turnuri=1 to the URL and see if it works for you!
Also new for this edition is a description of how to analyze WebRTC protocols on your computer using the excellent open source packet capture and analysis tool Wireshark. Between Wireshark and various browser tools (try Tools/Developer Tools in Chrome and Tools/Web Developer in Firefox, or chrome://webrtc-internals in Chrome for lots of useful WebRTC info), you can learn a lot just by playing with WebRTC. If your application is not working, these tools allow you to debug and analyze what is happening.
Finally, Dan’s introduction to the WebRTC API has been greatly expanded with step-by-step introductions to the various functional parts of the client and server code. As always, you can download all of our Demo Application code from our book website, and also see it running as well.
We have received so much excellent feedback in the one and a half years since we published the first edition. We can’t wait to hear from you on what you think of the Third Edition. We enjoy hearing from you on Twitter, Facebook, or Google+.
Today, I published a new Internet-Draft on how to securely communicate over the Internet using a new web technology known as WebRTC and the ZRTP protocol. Using this technique, Internet users can determine if the National Security Agency, or anyone else, is listening in to their calls placed using a web browser. There are already a number of commercial and open source products utilizing ZRTP, including Silent Circle, Jitsi, and others, but this new technique opens it up for all web users.
With WebRTC, all media flows are encrypted and authenticated using Secure RTP or SRTP. Unfortunately, the keying method chosen for WebRTC is DTLS-SRTP or Datagram Transport Layer Security for Secure Real-time Transport Protocol. DTLS-SRTP on its own does not provide protection against Man-in-the-Middle (MitM) attacks, also known as eavesdropping attacks. Today, the news is full of reasons why Internet users need such protection. We now know the surveillance of Internet users is widespread.
The ZRTP security protocol, published as RFC 6189 back in 2011, was invented by Phil Zimmermann to allow Internet users to communicate securely and privately over the Internet. ZRTP was not selected as the default keying method for WebRTC, despite it being the ideal candidate.
How does this work? You’ll have to read the ZRTP specification to find out exactly how, but in simple technical terms, it is because ZRTP uses a technique known as a Diffie-Hellman key exchange augmented with a hash commitment. This allows the SAS, which can be two words or four hex digits, to prove that a media session has no eavesdroppers present.
Everyone needs privacy in their communication, and WebRTC with ZRTP finaly provides a real solution to all Internet users.
On Saturday, I gave a presentation and demo of ZRTP at Hackfest 2013, organized by the Washington University in St. Louis chapter of ACM (Association of Computing Machinery) .
A group of about 60 undergrads had gathered in Urbauer 211 to learn about hacking and try it out. I gave a short presentation about ZRTP, the media path keying protocol for SRTP invented by Phil Zimmermann.
I was fortunate to serve as the editor of the ZRTP specification, which was published as RFC 6189 two years ago. I showed how ZRTP allows users to detect the presence of a MitM (Man in the Middle) attacker by checking the Short Authentication String.
Here is a PDF of my presentation.
Then I used the Jitsi open source voice, video, & chat application to demo ZRTP. Emil Ivov, founder and chief developer at Jitsi answered my ZRTP call, and we checked the SAS. The sequence of steps used to secure the voice & video session is shown in this animated GIF.
Afterwards, I gave away a copy of Counting from Zero, my technothriller that incorporates elements of ZRTP, hacking, exploits, and zero-day attacks.
We then spent the rest of the afternoon playing with Metasploit on an isolated network of virtual Windows machines. It was an interesting day. Just like at IETF meetings, the biggest excitement of the afternoon was when the cookies arrived!
Perhaps at next year’s session, we can try out VoIP hacking tools such as SIPvicious!
The giveaway is hosted by goodreads, the social reading site. If you love to read but haven’t found Goodreads, you should check it out!
From now until November 9, you can sign up to win a paperback copy. Winners notified on November 10.
I’ve spent many years of my career working on interoperability in communication systems. Back in the dark ages, I did SS7 interoperability testing. During my CLEC days, I ran a test lab that tested optical, telephony, and ATM/Frame Relay equipment. I’ve spent many years working on interoperability issues with SIP, starting with the SIP call flows (RFC 3665 and RFC 3666) and then SDP Offer answer (RFC 4317). I’ve also been to many SIPits (SIP interoperability events run by the SIP Forum), testing voice and video interoperability.
WebRTC poses some interesting interoperability challenges, but I am hopeful we will get it right.
There are four different areas of interoperability: browser, protocol, codec, and offer/answer. Lets go through them one by one.
Browser interoperability is about aWebRTC application or site working the same regardless of which browser the user is using. In the past browser interoperability was just a browser/server issue, but with the peer-to-peer media and data channel flows of WebRTC, this is now a browser/browser issue. The good news is that there are only a handful of browsers, so the interop matrix is not too large. The bad news is that there are signs of discord already in pre-standards implementations. For one thing, all browsers must utilize the same APIs, or else WebRTC will be a major headache for developers. Of course, libraries can hide this complexity from developers, but this will slow down deployment and produces some needlessly bad user experiences. If we see one browser vendor using their own APIs instead of using the standard ones from the W3C, then we will know that someone is playing company games at the expense of the Internet users of the world. Hopefully this won’t happen, but it if does, users will and developers will likely move away from that browser.
Protocol interoperability is a major concern for WebRTC. In the past, browsers didn’t implement many protocols – everything used HTTP (Hyper-Text Transport Protocol). Today, browsers are doing more, including WebSockets, and will soon move to the next version of HTTP, 2.0. With WebRTC, the browser RTC Function has to implement multiple protocols including RTP, ICE, STUN, TURN, SCTP etc. These protocols define “bits on the wire” and “state machines” that ensure that interoperability works. For browser-to-browser media and data channels to work, browsers must implement these protocols and carefully follow the standards. If they don’t the whole industry will suffer. There are some issues today with the pre-standard WebRTC browser implementations. For example, one browser today implements a proprietary STUN client that will not work with standard STUN servers. Browser vendors will need to take protocol interoperability very seriously, and recognize that this is something new for them and that they need to follow industry best practices and approaches.
Codec interoperability is about ensuring that media sessions don’t fail because there is no common codec supported on both ends of the session. There are so many codecs in use, and every vendor and service provider seems to have their own favorite one. Fortunately, we should be able to avoid this for audio codecs. The IETF has recently finalized the Opus audio codec for speech and music, published as RFC 6717 this month. It really is a fantastic codec, much better than all the rest, making it an easy choice as one mandatory to implement (MTI) codec for WebRTC. Opus is also available as open source. The other MTI codec is G.711, also known as PCM, which provides interoperability in the VoIP and telephony world, and is also needed for interworking with the telephone network. Video codec choice is much more difficult. While H.264 is widely used today, there are no open source implementations or royalty-free licensing available for browsers or implementors. As such, it is very difficult to see how it could be chosen as a MTI video codec. Google’s VP8 video codec is proposed as an alternative, and is available in open source. However, there is much uncertainty about the licensing status of VP8. Should WebRTC deploy without common video codecs, this again could result in interoperability delays.
Offer/answer interoperability is perhaps the least understood, but most important area. Offer/answer refers to the negotiation of codecs, parameters, and settings for the media session or data channel between the two browsers. Even if both browsers use common APIs, standard protocols, and common codecs, if they are unable to successfully negotiate and configure their media or data channel, the connection will fail. WebRTC uses Session Description Protocol (SDP) to do this offer/answer exchange. The pre-standard WebRTC implementations are, frankly, a mess in this area. Their SDP is not standard, and not interoperable with anything else. It will take a lot of work to get this right, and we all must insist that browser vendors support standard offer/answer negotiations.
Occasionally, it is suggested that perhaps offer/answer would be easier if we didn’t use SDP. We all know and hate SDP, and it is ugly and awkward to use. However, it has taken over a decade’s work and experience to make it work, and any replacement would likely take that many years to get to work. And, in addition, since much of the standards-based VoIP and video world uses SDP, it would need to map to SDP as well. I can’t see this helping interoperability in any way. Previous efforts to replace SDP failed (anyone remember SDPng?) and I think anyone advocating replacing SDP needs to explain why a new effort wouldn’t meet a similar end, and why this effort wouldn’t take a decade. Also, the complexities of offer/answer relate to the complexities of negotiating an end-to-end session, and the actual syntax of the descriptions are a very small part of the complexity.
So WebRTC definitely has some interoperability challenges ahead of it. Fortunately, there are
many experienced engineers who are participating and helping with the effort. As long as the browser vendors take this seriously and don’t play games, I think WebRTC will have good interoperability, which will benefit web developers and web users alike.
If you are interested in WebRTC, you might like my new book “WebRTC: APIs and RTCWEB Protocols of the HTML5 Real-Time Web” published this month by Digital Codex LLC.