Sean Coates: PHP, Web (+Beer)

A while back, I blogged about trust on the web, and how there are a lot of assumptions made by content providers that simply don't carry over to end users, or are just a small (but important) step from being good practices.

Yesterday, at $work, we were talking about something that lead to a discussion on SSL, and how I think (hypocritically since the domain you're reading right now isn't even available on https://) that most sites, even if they don't contain sensitive information should be available by https—even if the certificate is self-signed.

Chris respectfully (I think (-; ) disagreed with me saying that certificates that are not trusted a user's browser are as bad, or even worse than not allowing SSL at all. His theory—and I'm sure he'll correct me below if I'm misrepresenting him—is that offering this type of unverifiable certificate is not only useless, but harmful to users because there's a false sense of security. My retort, though not well received, is that users of modern browsers (Firefox at least) will be notified when a self-signed certificate that they've accepted has changed. This at least allows the user to verify when something is amiss. His rebuttal was that there's no way for the user to tell which certificate is the "good" one, and which is the "bad" one, and I can see his point.

We had a discussion on DNS and how we trust it for a lot of things that we shouldn't, even though we don't want to... especially given the recent problems with DNS. In the end, we all agreed that putting something like http://omniti.com/ on self-signed https serves no practical value as users will a) never use it, b) not know how to verify the certificate, and c) will get confused by their browser warning them about security problems.

This lead to a few other branches of thinking about SSL. The first was a question Chris asked us "how do access your online banking?" clarifying with "how do you get to the login page?" A few of us (myself included) answered "bookmark" while others said they hit their bank's main domain either from URL history or manually, and clicked through from there. Chris's point was that most users visit http://bank.example.com/ and are somehow directed their https login page. I checked my bank, and bad things happen:

• visit http://www.royalbank.ca/
• click "online banking", which links to http://www.rbcroyalbank.com/STRINGHERE/redirect-bank-hp-pagelink-olb.html
• which redirects, via META tag to: https://www1.royalbank.com/cgi-bin/rbaccess/RESTOFURLHERE
• user is presented the login form (in https)

My bookmark is the https://www1.royalbank.com/... page, so I feel relatively safe, but let's look at the bad things that happen here:

• User visits one domain (HTTP, not secure)
• User is _silently_ redirected to another domain on HTTPs

Why are these bad? Well, aside from the possible confusion of getting bumped from royalbank.ca to rbcroyalbank.com to royalbank.com, the user's chain of trust breaks down when they visit http://royalbank.ca/. http—no "s". If this site was compromised, the user would never know (without careful URL confirmation at the https destination) that s/he was not maliciously redirected to https://www1.roya1bank.com/ (note "L" is "1" (one) in my bad-guy example). Phishers could easily get a SSL certificate for roya1bank.com.

That got me thinking a bit about the SSL certificate acquisition process. I'm sure some of the really high-end SSL certificates still come with human validation (a real person looks at the application and makes a real decision about granting the certificate; in the case above, hopefully this would have been caught). Most certificate signing I've seen recently is based on proven ownership of the domain in question. So, as I say, it's trivial for me to go register a domain that LOOKS like a bank. Sure, I'd still have to compromise either the http server or DNS that points at the server, but Kaminsky demonstrated that this isn't so hard (or wasn't until just a few weeks ago).

Let's take it a step further back. If bad guys can compromise DNS, which is inherently insecure (not SSL, no trust model other than IP address, and it runs on UDP(!)), then surely they can trick your the certificate authority's SMTP server to deliver mail to another mail exchanger, right?

• bad guy targets example.com poisons the certificate authority's DNS for example.com to point MX at an IP controlled by bad guy
• bad guy generates a certificate signing request (CSR) and send it to the certificate authority (CA), "From" bob@exmaple.com
• CA receives the CSR and verifies with whois that the contact for the domain is bob@example.com
• CA signes the CSR and returns the certificate to bob@example.com (either by mail or through a web interface)
• bad guy is now in posession of a perfectly valid and trusted http://example.com/ SSL certificate

Scary. You must be thinking that CAs probably have a more secure DNS setup and wouldn't get poisoned (as easily). I believe that to be somewhat true. Let's say it's absolutely true: the CA has 100% perfectly secure DNS. Ok, we'll need to go one step further back:

• bad guy poisons the DNS for the target's less secure $20/month ISP, example.com, to redirect the MX for example.com to a different server
• bad guy visits example.com's registrar's web interface and indicates that he has forgotten his password
• registrar generates password reset URL/instructions and emails it to bob@example.com
• bad guy receives the hijacked email, logs into the domain and changes the contacts to badguy@example.net, an email account that he controls
• bad guy generates a CSR and sends it to the CA from badguy@example.net, and continues the process outlined above to receive a legitimate, valid and trusted certificate

In any of these scenarios, hundreds or thousands of account credentials could be acquired—especially with creative use of proxies at the bad guy's malicious server.

We're lead to believe that SSL is truly safe, and it's true that the encryption part lives up to the expectation, but modern practice of the certificate generation/signing process certainly leaves something to be desired, I think.

Yeah, it might be a long shot that an attacker could easily poison specific DNS servers on the internet, but again, as Kaminsky showed the world just a few weeks ago, (nearly?) every DNS server on the planet was vulnerable to exactly this type of attack before summer 2008.

Pardon me if I don the tinfoil hat until we all forget about this mess.

My first network connection device was a 2400 baud modem. Practically speaking, that would allow me to sustain downloads at a rate of less than 250 bytes per second. This was relatively fast at the time; I'd been using my buddy's 1200 baud modem to connect to local BBSs before that modem-netting birthday.

To put this into perspective, the Yahoo! homepage, all considered, is somewhere around 470kB. On my early-90s era modem, it would have taken a little over 30 minutes (half of one hour) to download (in perfect conditions, without protocol overhead (good ol' zmodem), and if my mom didn't happen to pick up the phone during transfer).

For the past few years, I've had a 10 megabit connection (downstream) into my home/office. Under perfect conditions, I can pull the entire Y! homepage, and all attached media in less than half of one second.

In the early 90s, the Y! homepage was obviously much smaller—all pages were smaller—but even with a smaller footprint, many pages took a long time to load. I remember browsing with many windows open (browsers didn't have tabs back then... in fact, we barely had browsers (-: ), loading up a dozen or so pages before alt-tabbing back to the first one I'd queued up a few minutes before (on my 14.4kbps modem, by this time), to see if it had finally finished loading.

To overcome low connection speeds, lack of resources on the client side, and other factors such as connection latency that lead to slow page page loads, web pioneers came up with a model for allowing content to be delived in reasonable sized chunks that is still in use today: pagination. Long lists of (say "100") pieces of data ("search results") were separated into smaller pages (of "10"), including widgets to allow skipping to the next, previous and often any page in the set.

Well... mostly still in use today.

Technologies have helped us hack around the idea of separating growing amount of data into pages. Ajax, for example, allows the dynamic loading of the next set of results without forcing a page reload (often poorly... try bookmarking the result of many of these dynamic populations. Even Mobile Mail on the iPhone/iPod Touch allows something like this.

It seems to me, though, that web interface designers are stuck in this rut of showing end users a mere 10, 20 or even 100 items at a time. My 10Mb connection can handle a lot more traffic than you're sending; your server had better be able to deliver it (and usually, it can); my browser is allowed to allocate much more RAM; and I even like to think that I've microevolved the ability to parse much more data that I could a few years ago.

So, I ask you, fellow web professionals: is pagination still necessary? I obviously don't think so, but I'm not a User Experience guy, I'm a user (and also the guy who has to make the UX happen, and make sure your server can deliver the results mentioned above). Tell me what you think.