The reason for using the “www” hostname prefix when entering websites is now a matter of history. It’s old. Deprecated. Outdated. Antiquated. Like websites that only work in Internet Explorer, sites that break when you use the domain alone should be firmly encouraged to join the 21st century. It’s wasteful to type, and it’s cumbersome to pronounce. Consider that it takes nine syllables to properly enunciate three characters. Some argue that there is still a good reason to separate traffic destined to web servers from that destined to the domain itself. I think this is precisely the idea that’s become obsolete. The reason for that differentiation in the past was that the other protocols were as prolific (or even more prolific) than HTTP at the time. HTTP was just one of many, so it made no sense at the time to give any type of traffic a preference by pointing the root of a given domain to the system that hosted that content. Things are different now. HTTP is utterly dominant. Any site interacting with the public on any serious scale does so via a web server, so making this the default is a matter of obvious practicality. This doesn’t mean we should abolish the use of hostnames. Hostnames are excellent tools for separating traffic and making meaningful associations with users. The argument here is simply for having the root point to the web content.

Compatibility

There are four basic levels of no-www compatibility:

1. Your site is available via www.domain.tld only. If you use the domain alone your request will fail.
2. Your site is available via both www.domain.tld and domain.tld, but www.domain.tld does not redirect to domain.tld.
3. Your site is available via both www.domain.tld and domain.tld, and www.domain.tld does redirect to domain.tld.
4. Your site is available only via domain.tld and www.domain.tld will break.

I personally recommend webmasters implement #3, and don’t advise #4 for any reason. The discussion here is about improving usability through simplification, not breaking things for the satisfaction of being pedantic.:

No-www is an initiative to make all websites accessible from both the http://www.example.com/ and http://example.com/ forms of their names. The reason behind it is to standardize domain names providing web content and to avoid typing unnecessary letters. — Wikipedia

The reason for using the “www” hostname prefix when entering websites is now a matter of history. It’s old. Deprecated. Outdated. Antiquated. Like websites that only work in Internet Explorer, sites that break when you use the domain alone should be firmly encouraged to join the 21st century. It’s wasteful to type, and it’s cumbersome to pronounce. Consider that it takes nine syllables to properly enunciate three characters.

Some argue that there is still a good reason to separate traffic destined to web servers from that destined to the domain itself. I think this is precisely the idea that’s become obsolete. The reason for that differentiation in the past was that the other protocols were as prolific (or even more prolific) than HTTP at the time. HTTP was just one of many options, so it made no sense to give any type of traffic a preference by pointing the root of a given domain to the system that hosted that content.

Things are different now. HTTP is utterly dominant. Sites interacting with the public on any serious scale does so via a web server, so making this the default is a matter of obvious practicality. This doesn’t mean we should abolish the use of hostnames. Hostnames are excellent tools for separating traffic and making meaningful associations with users. The argument here is simply for having the root point to the web content as a matter of convention.

As for people who include it when speaking, there’s no need to be rude when correcting them. Just kindly inform them that it’s faster if they just go to the domain itself, and that the “www” isn’t needed.

For more information, check out the no-www FAQ, and feel free to fly their sitecon seen above.:

[Edited 07.27.07]

IDLE is not — according to my definition above — a true push technology. IDLE actually requires an active connection in order to work, and that connection cannot be initiated by the server.

[Update]: Yahoo! uses P-IMAP, not IDLE to implement “push”…[ Link: An Introduction to IMAP IDLE ]

Shibboleth is the Hebrew word that literally means “ear of wheat”. In the Hebrew Bible, pronunciation of this word was used to distinguish members of a group whose dialect lacked a “sh” sound from members of a group whose dialect included such a sound. The consequences of getting it wrong were fatal: Today, “shibboleth” refers to words and phrases that can be used in a similar way—to distinguish members of a group from outsiders.

So basically, a Shibboleth is something that you prompt for, and based on the way the response is given you can tell whether the person is part of the secret club or not. The cool part about it is that, at least in the traditional sense, the person being tested was not physically able to say the password correctly.

Very cool stuff.

> An ICMP Primer 

All People Seem To Need Data Processing.

Well, for those that deal with TCP a lot, I thought it might be helpful to have a mnemonic for the TCP flags as well. What I’ve come up with is:

Unskilled Attackers Pester Real Security Folks

Unskilled = URG Attackers = ACK Pester = PSH Real = RST Security = SYN Folks = FIN

The way this helps me the most is when isolating traffic to capture using Tcpdump. It’s possible, for example, to capture only SYNs (new connection requests), only RSTs (immediate session teardowns), or any combination of the six flags really. As noted in my own little Tcpdump tutorial, you can capture these various flags like so:

Find all SYN packets tcpdump 'tcp[13] & 2 != 0'

Find all RST packets tcpdump 'tcp[13] & 4 != 0'

Find all ACK packets tcpdump 'tcp[13] & 16 != 0'

Notice the SYN example has the number 2 in it, the RST the number 4, and the ACK the number 16. These numbers correspond to where the TCP flags fall on the binary scale. So when you write out:

U A P R S F

…that corresponds to:

32 16 8 4 2 1

So as you read the SYN capture tcpdump 'tcp[13] & 2 != 0', you’re saying find the 13th byte in the TCP header, and only grab packets where the flag in the 2nd bit is not zero. Well if you go from right to left in the UAPRSF string, you see that the spot where 2 falls is where the S is, and that’s how why you’re capturing only SYN packets when you apply that filter.

Remembering these flags and how to isolate them can go a long way in helping low-level network troubleshooting/security work by isolating what it is you want to see and/or capture. And of course the more you can isolate what you want to see, the faster you can solve the problem. I encourage anyone not making use of this powerful feature already to go ahead and add it to their repertoire.

For a customer project, I had to dive into the IPSec protocols at a very low level, and it was a real learning experience for me. I’d been using IPSec to set up network-to-network VPNs for a long time,…

(Source: Steve Friedl)

As you’ve probably heard, the system is based on the Jabber protocol — which is basically a set of standards built on streaming XML. Here are some details if you’re interested.

Anyway, my curiousity is focused around the authentication piece, so I fired up a sniffer and watched myself login. My side first sent an “auth xmlns” that included an X-GOOGLE-TOKEN (I can’t include the actual content since WordPress is eating the XML) which consisted of a very long alphanumeric string. The server then responded with a “success xmlns” response. After that the exchange of information ensued.

One key piece of information here is the fact that Google’s Jabber implementation doesn’t currently support encryption. From their website:

Google Talk currently does not encrypt chats or calls. But we are working hard to make many improvements to Google Talk while it is in beta, and we plan to fully support encryption of chats and calls before our official release.

No big deal — it’s still beta.

Anyway, I have to get back to work but I’ll be looking more into this later…

Two values, called “Diffie-Hellman parameters”, are at the core of this protocol, and they consist of a very large prime number ‘p’, and a second related “generator” number that is smaller than ‘p’, called ‘g’. The value for ‘g’ is tied very strongly to its associated ‘p’ value. The nature of this relationship is that for each number ‘n’, there is a power ‘k’ of ‘g’ such that n = g^k % p. Each host must agree on these two parameters (‘p’ and ‘g’) in order for the protocol to work. Finally, a third and private value, called ‘x’ is also generated for each host. This value, unlike ‘p’ and ‘g’, is not shared.

Public keys (to be exchanged with each other) are then generated with this function: y = g^x % p

…or in other words, take value ‘g’ and raise it to the power of value ‘x’, divide that by ‘p’, and your remainder is your public value ‘y’.

Then, the two parties exchange their y’s with each other and the exchanged numbers are used to create the shared secret ‘z’ as follows: z = y^x % p

…or in other words, take the exchanged public key ‘y’ and raise it to the power of your private key ‘x’, and divide that by the shared value ‘p’. The shared secret, ‘z’, is the remainder of that operation.

The beauty of Diffie-Hellman is that both parties will end up with the same value for ‘z’! And ‘z’ makes an outstanding key for whatever encryption algorithm they decide on using for the rest of their communication.

This works because: z = (g^x % p)^x' % p = (g^x' % p)^x % p

The key concept here is that the portion of the equation above in parenthesis is the other host’s public key. Notice that it has the other host’s private value in it. That’s what makes the attainment of a mutual secret possible mathematically.

The magic of Diffie-Hellman is that you not only end up with a shared secret, but the secret is never sent over the wire. Each side comes up with it independently, and that’s what makes the protocol so beautiful.: