Some Twitter clients are vulnerable to DNS attacks

The Twitter blog implies that the name twitter.com was taken over. There are two scenarios under which a Twitter client will provide its user’s password to an attacker who has pointed the name ‘twitter.com’ to his machine.

The first is that the client uses “http basic auth” unencrypted with the HTTP protocol instead of HTTPS. If that’s the case, the client will always unrestrictedly give the username and password to whatever host is at twitter.com, and in this process it performs no verification of the host’s authenticity.

The second scenario is that the client uses HTTPS, but fails to also require and examine a trusted certificate of authenticity from the target host as part of the protocol. If the last part is skipped, though the HTTPS request will be encrypted for transit, the client has not verified the authenticity of twitter.com. Unfortunately, this certificate handling part can be sometimes tricky for developers to get right.

Originally, Twitter had no support for HTTPS, and the Twitter REST API to this day permits dumb HTTP basic authentication. Twitter’s own programming examples still show the URL “http://twitter.com/…”. So this, coupled with error-prone HTTPS certificate implementations in clients makes me expect there to be more than a few Twitter clients vulnerable to DNS attacks. Some may reveal your password to the first “twitter.com” that comes along.

Thus, if there was a DNS takeover of twitter.com, passwords were potentially compromised.

Without more detail from Twitter or the hackers, however, we don’t really know what’s happened. It could be that hackers didn’t actually get the DNS name “twitter.com”. It could be that all the vunerable Twitter clients happened to be off during the time of the attack. It could be that the attackers didn’t think to log the incoming http requests containing passwords and only wanted to add their greetings page and email address to twitter.com.

Comments welcome.

Date: Wed, 28 Jan 1998 17:04:11 -0800
From: postel@ISI.EDU
Subject: root zone secondary service
Cc: postel@ISI.EDU, iana@ISI.EDU

The following messages is pgp signed by “iana “.

—–BEGIN PGP SIGNED MESSAGE—–

====================================
====================================

Hello.

As the Internet develops there are transitions in the management
arrangements. The time has come to take a small step in one of those
transitions. At some point on down the road it will be appropriate for
the root domain to be edited and published directly by the IANA.

As a small step in this direction we would like to have the
secondaries for the root domain pull the root zone (by zone transfer)
directly from IANA’s own name server.

This is “DNSROOT.IANA.ORG” with address 198.32.1.98.

The data in this root zone will be an exact copy of the root zone
currently available on the A.ROOT-SERVERS.NET machine. There is no
change being made at this time in the policies or procedures for
making changes to the root zone.

This applies to the root zone only. If you provide secomdary service
for any other zones, including TLD zones, you should continue to
obtain those zones in the way and from the sources you have been.

- –jon.

Jon Postel
Internet Assigned Numbers Authority
c/o USC – ISI, Suite 1001
4676 Admiralty Way
Marina del Rey, CA 90292-6695

Talk: +1-310-822-1511
Fax: +1-310-823-6714
EMail: IANA@ISI.EDU

====================================
====================================

—–BEGIN PGP SIGNATURE—–
Version: 2.6.2

iQCVAwUBNM/OggXEg/2i5jY1AQFOSgQAmFKo34Ytxi+8R78qG7/2BUP3KdWqH2Aj
zufrv5sYkfQDNeW+02JA5LZT6ZW5AgRgTDJpQkZlKKvBfzD52GCsDpgt1yUdxxUJ
3VfmK48AIEV9LVKAwlDmOqia++cp1nA8Jd7en35HnKAuFVFEKN0fYEq8FHXEAuOJ
TXXrSiVyCHE=
=qZXq
—–END PGP SIGNATURE—-

All but the U.S. government secondary name servers agreed to switch.

tag:masonlee.org,2010:
tag:telephonographic.net,2010:
tag:borange.com,2010:
tag:textie.me,2010:

This is RFC4151, The “tag” URI Scheme”

Abstract

1. Overview

1.1. References

2. Technical Specification

2.1. Namespace

2.2. Namespaced rssCloud XML Publisher’s Schema


<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
 targetNamespace="http://rssboard.org/2009/xsd/rss2.0"
 elementFormDefault="qualified"
 attributeFormDefault="unqualified"
 version="0.9">

 <xs:element name="cloud">
  <xs:complexType>

   <xs:annotation>
    <xs:documentation>Specifies a web service that supports the rssCloud interface which can be implemented in HTTP-POST, XML-RPC or SOAP 1.1. Its purpose is to allow processes to register with a cloud to be notified of updates to the channel, implementing a lightweight publish-subscribe protocol for XML resources.</xs:documentation>
   </xs:annotation>
   <xs:attribute name="domain" type="xs:string" use="required"/>
   <xs:attribute name="port" type="xs:positiveInteger" use="required"/>
   <xs:attribute name="path" type="xs:string" use="required"/>
   <xs:attribute name="registerProcedure" type="xs:string"
use="required"/>

   <xs:attribute name="protocol" use="required"/>

    <xs:simpleType>
     <xs:restriction base="xs:string">
      <xs:enumeration value="xml-rpc"/>
      <xs:enumeration value="http-post"/>
      <xs:enumeration value="soap"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:attribute>
  </xs:complexType>
 </xs:element>
</xs:schema>


2.3. Use in Atom

2.4. Use in RSS

3. Examples

3.1. Atom Example

We’re using the internet for a world-wide-conversation, and lately we’ve been wrapping a lot of communications in atoms of information we sometimes call “posts”. People pass around links to posts and sometimes copies of posts, and we have feeds full of posts, tweets and things included. It’s all good. Hopefully the posts have unique IDs so we don’t confuse them with one another and they can be cross-referenced. But what is that ID? How do we choose them? Usually today we use URLs. URLs are rooted in DNS names. Full rights to DNS names are reassignable according to the policy of ICANN. There’s currently no policy to say the future owners of a domain can’t reuse URLs for most anything they want. Whoops?

If we want our decentralized world-wide-conversation to work for a very long time, we need to consider strategies for keeping our post IDs unique. If we use URLs, do we care that a malicious future owner may in some ways “overwrite” our posts in history by issuing their own posts with the same ID? For that matter, are some gTLDs more stable roots than others for long-term ownership?

Would we be better off working with an ID namespace for posts that had an explicit policy for the persistence of identity uniqueness at least written down, if not enforceable by contract law? A new gTLD?

Post archives

Here’s one idea that might get around all that. What if there was a giant P2P historical web that could be queried with a date and a URL (or any URI) and it did its best to return whatever post or resource was issued there at that time. Peers could make sure that posts they felt were important stayed in the archive by mirroring them, all regardless of where on the web the information was originally posted. A distributed file system of sorts.

Atomism and Holism

Of course, where we stop writing atomic posts and start communicating in high definition streams, it seems the persistence of ideas gets a lot harder, as one of the inspirations [scripting.com] for this #blogpostfriday post starts to get at.

What would Heraclitus say?

Further reading

Drummond Reed. “The Persistence of Persistence” [www.equalsdrummond.name]

Bob Wyman. “The Persistence of Identity” [www.wyman.us]

The main functional difference is the caching

Telnic recently posted a graphic showing how much simpler using DNS directly is than finding XRD. Called an “Idiot’s Guide” – I assume tongue-in-cheek – the best argument for using DNS is almost entirely unrepresented. Future library functions could ultimately make both lookup procedures trivial (ignoring for the moment you can’t do DNS lookup from javascript), so the graphical complexity does not represent a practical issue. Using DNS to make an HTTP request and parsing the response is pretty much what the entire web is made of. How often are we doing these lookups to where the overhead would be a problem?

The one advantage of using DNS to identify service endpoints is that DNS gives you a ready and reliable cache. We don’t see this in the graphic, but the authoritative source in the DNS lookup is shielded from repeat requests by DNS’s tiered cache. Better still about this, simple client apps automatically take advantage of DNS’s cache; it’s been the fabric of the internet since 1983.

There are drawbacks. UPDATE: As Blaine Cook points out in the comments below, perhaps the biggest is that DNS has security issues until DNSSEC is widely implemented. Without that, one can’t trust that the distributed cache is providing authoritative information. For storing public keys for digital signatures, that’s important.

The caching also means DNS records can take some time to propagate under normal circumstances. While DNS records can be explicit about their preferred Time-To-Live (TTL) in the cache, it’s ultimately up to the bottom tier name server to decide what minimum values it will allow. Though Telnic seems to be specifying 1 minute TTLs, we can’t be sure this low value will be observed by every bottom tier ISP.

Unpredicatable latency could potentially be an issue for applications that depend on service endpoint registration for a quick setup-and-run operation, like downloading and installing a new chat app and immediately trying to start a chat using the endpoint the app just registered on your DNS-based id.

WebFinger servers, on the other hand, will (I assume) work like the rest of the web and rely on a combination of client-side caching according to HTTP headers and in-memory caches at the authoritative server (or servers, as DNS may specify alternates). At worst, these servers see every request, and of course, no cache can be shared across individual clients without some additional mechanism being built.

So that’s what I take away from the Idiot’s Guide to WebFinger and .tel. DNS comes with free caching to lighten the server load, while HTTPS+XRD uses the web’s caching mechanisms.

Also – and I mentioned this earlier – something that’s not obvious from the diagram is that DNS can’t be directly accessed by javascript web apps. Flash apps can open a socket, but javascript cannot. Presumably this is one reason WebFinger is not using the DNS solution.

Domains can be free

I’ve noticed that critics of the DNS service lookups often point out that domains are not free, but email addresses are. I want to take a second to point out that this is not true. A name server is considerably less expensive to run than a mail system, and if you have a domain, subdomains such as myname.example.com can be given away to end-users “free”. It’s even conceivable that an email provider could create subdomains for every email address and enable WebFinger-like lookups for email addresses through DNS NAPTR records (e.g. masonlee.webfinger.gmail.com.), should that be desirable. (This is not WebFinger’s plan, though. WebFinger passes the email address as a parameter to an HTTP method on the mail host.)

.Tel is not the only DNS solution

There are three arguments that resonate with me for registering a .tel domain. None seem compelling to the tune of $12/year, especially for people that already have domains.

Argument 1. You get to use Telnic’s nameservers and APIS for privacy controls and editing NAPTR records.

If DNS is the ideal decentralized service discovery system, and we aren’t tied to Telnic Limited, then other name servers should also be implementing these same management APIs, bringing us back to the question, what’s really special about the .tel domain?

Argument 2. If we assume third-party apps will use the Telnic APIs, then [domain].tel is the shortest possible way to express “Hey, I have Telnic conforming NAPTRs and NAPTR-editing and privacy APIs!”.

Might one just as well express the same by adding a tel. subdomain to an existing domain, e.g. tel.masonlee.org.?

Argument 3. If everyone had a .tel domain, it would be an awesome namespace, where we might silently drop the “.tel” and just have global “usernames” for finding service endpoints.

This would be ideal in a lot of ways, but the current pricing is a barrier such that this is unlikely to happen. The same problem exists for top-level i-names. Email addresses (and phone numbers) are what everybody already has.

One argument against adopting .tel is that Telnic overrides all .tel DNS A records to point to their Telnic webservers. I’ve heard their reasons for doing so – guaranteed usability in old-generation mobile web browsers and to provide a consistent looking directory – but I think this is a mistake. It’s not clear that all service endpoints, especially highly technical ones, should need to be shown on a human-friendly page (example), and as is, only Telnic has the authority to decide how the records will be presented (icons, ordering, etc.) for .tel domains on the web.

Are NAPTR and XRD mappable?

Suppose you think both DNS and HTTP+XRD service listings are cool, .tel completely aside. Could we create a unified service discovery library that allows clients to look up a service for both email and domain ids? There would be some confusion as to whether domain-looking strings provided by a user should be resolved to DNS NAPTR or OpenIDs XRD via HTTP, but we could check both and prefer one.

Secondly, if we want to use DNS sometimes, but think that XRD has the momentum right now, can we transform XRD to a set of NAPTR records, and can we agree to use the same service URIs in both systems? We could get some API compatibility this way.

That said, once the net supports email addresses as ids, how many people are going to get themselves a domain name to do the same thing? Frankly, WebFinger seems likely to obsolete OpenID urls as well.

APIs needed

For both XRD and NAPTR registries to be useful beyond OAuth and single-sign-on, there’s a lot of work still to be done. XRD providers need a standard API to allow authorized third party applications to update a user’s service listing. When I download Skype app, Skype should be able to add its endpoint to my service registry. (I’m hearing that XDI might have a solution.) And while Telnic does have APIs for this that other name servers could mimic (way to go!), cursory inspection indicates they still need improvement: for example, an authorization scheme other than username/password.

All good stuff to watch for.

Can't have a new decentralized Twitter without short usernames! XRI I-Name evangelists should be all over this! #openmicroblogging #xri


Nik Putnam replied through Facebook:

why not? your reader could translate between URIs for contacts and your own nicknames for them, like your mail client does. no?

To which I added:

I-Names certainly aren't "decentralized", though, so they won't make for a decentralized Twitter-- just a more distributed one. They do have the benefit of being controlled by a foundation, aren't based on DNS, and have an interesting layer of indirection that allows the namespace to evolve.


So what’s up with I-Names these days, anyways? Last news I heard was support for them in OpenID 2.0.

=masonlee

The schema of the feeds dictates to a large degree the end-user experience. Twitter’s 140 character limit has surprised, impressed, and enlightened the lot of us techies. How could such a severe limitation actually works to the end user’s benefit? Easy: it makes a tweet stream readable. If you want to publish into the conversation, you have to conform to the standards and keep it short; people are skimming this information.

Compare a Twitter.com client to an Atom feed client. Atom clients have trouble displaying information from disparate sources uniformly because not every source agrees on the semantics of “title” vs “subtitle”, nor on what to put in the “summary”, nor on whether the content embedded in the feed should be the same or different from that in the link. Re-combined Atom feed items can make for some awkward reading when you start pulling in things like photo streams, audio feeds, and Twitter statuses. Just because some information can be shoved into Atom and shown in the same feed reader as everything else doesn’t mean it should be; however, the idea that all types of Atom feeds need to be supported in a feed reader is prevalent, and has usually worked to the detriment of user experience. Even RSS’s more simple “title” and “description” are two pieces of metadata too many for today’s information glut and the new distributed world-wide conversation.

One way to get clients built for a new distributed, real-time, world-wide conversation system might be to make a new feed format that helps dictate the user experience and expectations. In doing so, we would take a lesson from Twitter: Titles are outmoded. Make your case in 140 chars and attach a link. It works.

How about a straw-man proposal then? We’ll need some some short text, the ability to attach links, and some very basic metadata to make the system work. Call these new feed items “Tweets” (and make sure they can be JSON as well as XML!).

NEW TWEET SCHEMA STRAW-MAN for distributed world-wide conversation:

• Body. 140 chars!
• Links. If you are tweeting a link or links to data (e.g. an article, photo, mp3, etc.) those links go here. The items are NOT embedded in the Tweets. (Another lesson learned from Twitter and another interesting discussion.)
• Author. A person’s internet identity. I-Names?
• Digital Signature. The whole Tweet should be signed against the author’s public key so we can verify authenticity without having to get the tweet directly from the source.
• Datestamp.
• Universally Unique ID. When you make a tweet, you generate a UUID for it (in ultimate accordance with a registry.) Tweets don’t live in any central location, and aren’t created through a central place, so it’s not a URL.
• Context. If this is in reply to another tweet, or tweets, put their unique IDs here to so clients can load conversation context.

This would be the format of the Tweet itself, independent of any message routing systems. Separate metadata in routing envelopes would help get the right tweets to the right people at the right time, but those would be routing-system specific, and a separate discussion. (“Re-tweeting”, for example, should really just be re-routing, not creating a new Tweet.)

What else would you add? What’s the best counter-argument that this should be done with Atom instead?

Because the iPhone is a closed device (meaning you can’t install any low-level controls) there’s no way to see what your apps are doing with any of your private data, aside from your location. On the desktop, we have some rudimentary safeguards available, such as the LittleSnitch application, but there’s nothing like this for iPhone, and no possibility of anyone but Apple making such a thing.

The iPhone’s location privacy control is a good thing. I’d like to see that extended to other areas of the device.