Once upon a time there were still people using browsers that only supported SSLv2. It's been a long time since those browsers were current, but when running an ecommerce site you typically want to support as many users as you possibly can, so you support old stuff much longer than most people still need it.

At least 4 years ago, people began to discuss disabling SSLv2 entirely due to fundamental security flaws. See the Debian and GnuTLS discussions, and this blog post about PCI's stance on SSLv2, for example.

To politely alert people using those older browsers, yet still refusing to transport confidential information over the insecure SSLv2 and with ciphers weaker than 128 bits, we used an Apache configuration such as this:

# Require SSLv3 or TLSv1 with at least 128-bit cipher
<Directory "/">
    SSLRequireSSL
    # Make an exception for the error document itself
    SSLRequire (%{SSL_PROTOCOL} != "SSLv2" and %{SSL_CIPHER_USEKEYSIZE} >= 128) or %{REQUEST_URI} =~ m:^/errors/:
    ErrorDocument 403 /errors/403-weak-ssl.html
</Directory>

That accepts their SSLv2 connection, but displays an error page explaining the problem and suggesting some links to free modern browsers they can upgrade to in order to use the secure part of the website in question.

Recently we've decided to drop that extra fuss and block SSLv2 entirely with Apache configuration such as this:

SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP

The downside of that is that the SSL connection won't be allowed at all, and the browser doesn't give any indication of why or what the user should do. They would simply stare at a blank screen and presumably go away frustrated. Because of that we long considered the more polite handling shown above to be superior.

But recently, after having completely disabled SSLv2 on several sites we manage, we have gotten zero complaints from customers. Doing this also makes PCI and other security audits much simpler because SSLv2 and weak ciphers are simply not allowed at all and don't raise audit warnings.

So at long last I think we can consider SSLv2 dead, at least in our corner of the Internet!

Comments

Here's something new in HTTP land to play with: Shared Dictionary Compression over HTTP (SDCH, apparently pronounced "sandwich") is a new HTTP 1.1 extension announced by Wei-Hsin Lee of Google last September. Lee explains that with it "a user agent obtains a site-specific dictionary that then allows pages on the site that have many common elements to be transmitted much more quickly." SDCH is applied before gzip or deflate compression, and Lee notes 40% better compression than gzip alone in their tests. Access to the dictionaries stored in the client is scoped by site and path just as cookies are.

The first client support was in the Google Toolbar for Internet Explorer, but it is now going to be much more widely used because it is supported in the Google Chrome browser for Windows. (It's still not in the latest Chrome developer build for Linux, or at any rate not enabled by default if the code is there.)

Only Google's web servers support it to date, as far as I know. Someone intended to start a mod_sdch project for Apache, but there's no code at all yet and no activity since September 2008.

It is interesting to consider the challenge this will have on HTTP proxies that filter content, since the entire content would not be available to the proxy to scan during a single HTTP conversation. Sneakily-split malicious payloads would then be reassembled by the browser or other client, not requiring JavaScript or other active reassembly methods. This forum thread discusses this threat and gives an example of stripping the Accept-encoding: sdch request headers to prevent SDCH from being used at all. Though the threat is real, it's hard to escape the obvious analogy with TCP filtering, which had to grow from stateless to more difficult stateful TCP packet inspection. New features mean not just new benefits but also new complexity, but that's not reason to reflexively reject them.

SDCH references:

• SDCH Google Group which includes the specification PDF and ongoing discussion
• Wei-Hsin Lee's presentation slides on SDCH
• IETF mailing list announcement of SDCH and ensuing discussion thread
• Velocity 2008 conference notes where the pronunciation of SDCH is given as "sandwich"
• Vaporware Apache mod_sdch project

Comments

This has been frequently mentioned around the web already, but it's important enough that I'll bring it up again anyway. Firefox 3.5 adds the CSS @font-face rule, which makes it possible to reference fonts not installed in the operating system of the browser, just as is done with images or other embedded content.

Technically this is not a complicated matter, but font foundries (almost all of whom have a proprietary software business model) have tried to hold it back hoping for magical DRM to keep people from using fonts without paying for them, which of course isn't possible. As one of the original Netscape developers mentioned, if they had waited for such a thing for images, the web would still be plain-text only.

The quickest way to get a feel for the impact this change can have is to look at Ian Lynam & Craig Mod's article demonstrating @font-face in Firefox 3.5 side-by-side with any of the other current browsers. It is exciting to finally see this ability in a mainstream browser after all these years.

Comments

While traveling and staying at Hostel Tyn in Prague's city center, I ran into a strange problem with my laptop on their wireless network.

When many people were using the network (either on the hostel's public computers or on the wireless network), sometimes things bogged down a bit. That wasn't a big deal and required merely a little patience.

But after a while I noticed that absolutely no "uploads" worked. Not via ssh, not via browser POST, nothing. They always hung. Even when only a file upload of 10 KB or so was involved. So I started to wonder what was going on.

As I considered trying some kind of rate limiting via iptables, I remembered somewhere hearing that occasionally you can run into mismatched MTU settings between the Ethernet LAN you're on and your operating system's network settings.

I checked my setup and saw something like this:

ifconfig wlan0
wlan0     Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
          inet addr:10.x.x.x  Bcast:10.x.x.x  Mask:255.255.255.0
          inet6 addr: fe80::xxx:xxxx:xxxx:xxxx/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1239 errors:0 dropped:0 overruns:0 frame:0
          TX packets:20 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:191529 (191.5 KB)  TX bytes:4543 (4.5 KB)

The MTU 1500 stood out as being worthy of tweaking. So I tried a completely unscientific change:

sudo ifconfig wlan0 mtu 1400

Then tried the same HTTP POST that had been consistently failing, and poof! It worked fine. Every time.

I think mostly likely something more than 1400 bytes would've been possible, perhaps just a few short of 1500. The number 1492 rings familiar. I'll be old-fashioned and not look it up on the web. But this 1400-byte MTU worked fine and solved the problem. To my delight.

As an interesting aside, before making the change, I found one web application where uploads did work fine anyway: Google's Picasa. I'm not sure why, but maybe it sliced & diced the upload stream into smaller chunks on its own? A mystery for another day.

Comments

Safari is not now, nor has it ever been, my browser of choice. Aside from the fact that KHTML is generally the least compatible of browser engines these days, Safari is pretty barren from a feature standpoint. I rarely use it on my mac. I also find the lack of the "button" widget in Aqua annoying, because it makes Gmail ugly.

When I started using Safari 3.0.1 beta at work, I was impressed, but not impressed enough to ditch Opera. At home, however, I am using Camino, which I love, which is based on Gecko, the underlying Mozilla engine that also forms the core of Firefox. The problem is, as much as I love Camino, it's tough to use for development: it doesn't support extensions, it doesn't have a javascript debugger that works, it doesn't have draggable tabs, or tab restore, and it's not very easy to extend functionality. There are lots of tricks at PimpMyCamino, but even today, the most useful add-on, "CamiScript," is billed as unstable on Camino version above 1.0. Camino 1.0 was released in the first half of 2006. We're over a year later.

This is not a post to bitch about Camino though. I love 1.5 and it's serving me well. The thing is, I downloaded a nightly build of Webkit recently. Webkit is to Safari what Gecko is to Camino, and Webkit comes easily packaged in a disk image that requires no installation.

Webkit nightlies are awesome. First, there's the page inspector. From a development standpoint, this is awesome.


click image to view at full size

The inspector shows you each detail of the page load. You've got the entire page transfer size, as well as the page transfer time. You can break it down by element or by element type. You can view the headers sent and received. This is tremendously useful. It's been very interesting to see what parts of requests are properly cached and compar original load to subsequent page loads.

Then we have "Drosera," the Javascript debugger.


click image to view at full size

I haven't quite figured out how to use this tool, but I'm excited that it exists. It's something I've needed for some time on a Mac. This is all very promising.

Safari may be mostly bare, but by the time 3.0 final is released with Leopard, plus the fact that Safari exists on Windows, it, or its featureful offshoot based on Webkit, Shiira, just may be my main Mac browser.

You can get Webkit nightlies at nightly.webkit.org.

Tags: Web Browsers, Camino, Mac, Safari
Comments

If you browser around the internet, particularly on tech sites, you'll find person after person praising Apple for releasing Safari 3.0.1 a mere 3 days after releasing the first public beta on Monday. At first, I thought - here we go! First off, it's a BETA release, and I *expect* it to be updated. Secondly, people are going crazy about Apple's fast reaction time, but I wondered if it were Microsoft, would the reaction be the same, or would it be "They release a product and it takes less than 24 hours to find a major vulnerability!?"

But alas, I ran Software Update and updated my Safari/Win install at work to 3.0.1. Whereas 3.0 was a major disappointment at work - fonts were a mess, pages had major problems with rendering, and the browser would crash randomly - a few minutes after install I can tell you that 3.0.1, on my computer at least, is a HUGE leap forward. The browser hasn't crashed on me outside of one bug that existed before (maximizing on the slave screen of a dual-monitor setup), the thing is SO much better!

Safari is far from usable as my main browser. The thing is feature-barren, is far less customizable than Firefox and Opera and even Camino, and on Windows, it sticks out like a sore thumb. That said, I just love having the rendering engine on my windows machine, I love that it's available for iPhone and Mac-friendly web development.

Kudos to Apple for porting this great app to Windows fairly successfully. Microsoft has been very slow to move to OS X and Intel; they have let RDP stagnate, they have let Office go 5 years with no update, they have no management tools that work on Mac, no IE, no WMP, not even a fully compatbile Outlook Web Access (OWA)... yet.

I am usually wary of excessive praise on Apple, but after seeing the Leopard previews pushing the evolution of the desktop and the accessibility of backups, the iPhone pushing the mobile experience, and Safari pushing web standards, I'm really feeling good about what they are doing.

Tags: Web Browsers, Safari, Mac, Apple
Comments