I finally moved the public side of this blog over to HTTPS last weekend. Traditionally I’ve preferred to put public info on HTTP and save HTTPS for things that need it – passwords, payment info, login tokens, anything that should be kept private — but between the movement to protect more and more of the web from eavesdropping and the fact that tools are making it harder to split content between open and encrypted sides (the WordPress app sometimes gets confused when you run the admin over HTTPS but keep the public blog on HTTP), I decided it was time.

The last sticking point was putting HTTPS on my CDN, and I’d decided to try getting Let’s Encrypt and CloudFront working together over the weekend. Then Amazon announced their Certificate Manager for AWS, which took care of the hard part. All I had to do was request and approve the (domain-validated) certificate, then attach it. Done!

Downside: Because I opted for the SNI option on the CDN, rather than pay the premium to get unique IP addresses on every CloudFront endpoint, the images won’t work with older browsers like IE6. (Server Name Indication is a way to put more than one HTTPS site on the same IP address.)

On the other hand, the cert I have on the site itself is SHA2-signed (as it should be, now that SHA-1 is no longer sufficient), so it wouldn’t work with older browsers even if I turned off the CDN and kept the images on the server.

It’s the first time I’ve actually broken the ability of older browsers to see any of my personal sites. I’ve broken layouts, sure, but not completely cut them off. In general I’d rather not, but I think I’m OK with it this time because

  1. SHA1 really does have to go, SHA2 is well-established, and it’s not like I’m providing downloads of modern browsers or a critical communications forum for people who are stuck with ancient hardware/software because that’s all that’s available to them.
  2. SNI has been around for TEN YEARS.

And as it turns out, DreamHost’s ModSecurity rules block IE6 to begin with, so the whole site’s already broken in that browser.

So I guess next time I redesign I can finally drop any IE6 workarounds. :shrug:

After switching one of my self-hosted WordPress blogs to all-HTTPS, I ran into an odd problem: Jetpack Related comments stopped working after a while.

After going back and forth with Jetpack support and my web host, it turned out the problem was with the SSL configuration on my site. Jetpack has to download a copy of your posts in order to calculate recommendations, and it uses libcurl to do that. Curl has stopped supporting the RC4 cipher in SSL connections because weaknesses have been found in it…and that’s what my server was using! (Ack!) I assume it was an old compatibility setting that never got updated.

Jetpack needed to reindex the site, but couldn’t retrieve anything, so it got stuck on “Indexing request queued and waiting…” Disconnecting and reconnecting didn’t work. Jetpack thought it was connected, so it didn’t report an error. (I assume it uses a different library for some things.) Pages were loading the script and the placeholder, but didn’t have suggestions to put there. And of course it wasn’t done indexing, so it didn’t offer a reindex button on the debug page.

What to do:

SSL ciphers are a server configuration setting, not a problem with your SSL certificate, so you don’t need to revoke and reissue the cert. If your hosting provider manages your server, you can ask them to disable RC4. If you run your own server, you’ll need to look up how to disable RC4 on IIS, Apache, NginX, etc. You can verify your site’s settings at Qualys’ SSL Server Test: Look for RC4 in the results and see if it’s labeled Yes or No.

If Jetpack doesn’t start indexing after you change your config, try turning off the Related Posts module and turning it back on. It only took a few minutes before recommendations started appearing on the site again.

There is one downside, which is that some older browsers (specifically Internet Explorer on Windows XP) may not be able to connect. As always, it’s a trade-off.

One of the great ironies of phishing is that, these days, identity theft via the web tends to work by preying on people’s fear of identity theft. It doesn’t help that most people don’t really understand the technology. The typical phishing message looks something like this:

Dear so-and-so. In order for us to protect your account from identity theft, we need you to give us all the critical information that we already have. Otherwise, your account will be locked.

These typically use actual bank logos and link to a website that imitates the bank’s real site as closely as possible. The days of “Pease entr yore acccccount infomation hear KTHXBYE” are long gone.

But the one I saw in the spamtraps today was just astonishing in its brazen use of buzzwords to add authenticity:

Dear Wilmington Trust Banking Member,

Due to the high number of fraud attempts and phishing scams, it has been decided to implement EV SSL Certification on this Internet Banking website.

First we have the scare tactic (always ironic in a “there are treacherous people about” sense). Throwing in EV SSL certificates makes it seem a bit more authoritative, since it’s something a lot of companies have started doing, and people may have heard about it in the news.

The use of EV SSL certification works with high security Web browsers to clearly identify whether the site belongs to the company or is another site imitating that company’s site.

It has been introduced to protect our clients against phishing and other online fraudulent activities. Since most Internet related crimes rely on false identity, WTDirect went through a rigorous validation process that meets the Extended Validation guidelines.

And here they talk about EV certs and how much safer they’ll make your account!

Please Update your account to the new EV SSL certification by Clicking here.

And here’s where they demonstrate that they figure the typical mark doesn’t actually have a clue what EV SSL certificates are. Various real businesses have converted from standard SSL to Extended Validation SSL, and the users didn’t have to do a thing.

Now, you might need to upgrade your web browser or switch to one that will show you a green bar (Firefox 3, IE7, Opera 9, etc.), but you’d still be able to access your account even if you didn’t. Unless the site started blocking other browsers like PayPal briefly discussed back in April. Even then, there would still be nothing that would require you to log into your account and make a change.

Anyway, let’s continue:

Please enter your User ID and Password and then click Go.

This one’s presumably a simple phish, just obtaining login credentials to give the thief access to the account through the web.

(Failure to verify account details correctly will lead to account suspension)

And of course the implied threat: Do this or you won’t be able to get at your money. Again, a typical phishing tactic.

On a side note: My favorite spam topic of the last week is “Refinance your ARM today.”. Yeah, I know what ARM stands for, but I keep imagining Cyborg, or perhaps the Six Million-Dollar Man, trying to refi a loan that covers the gadgets in his arm.

Last month, eWeek reported that PayPal intends to block unsafe browsersfrom accessing their site. They’ve focused on phishing detection and support for Extended Validation SSL Certificates. So what are these features, and why does PayPal think they’re critical? And just which browsers are they likely to block?

Phishing protection has an obvious appeal for a site whose accounts are one of the biggest phishing targets on the web.  Opera 9.1 and up, Firefox 2, and Internet Explorer 7 check the websites they visit against lists of known fraudulent sites. These browsers will warn the users before they accidentally type their credentials into a bogus log-in form. While this makes no difference when a user is already on PayPal’s site, it does mean the user is less likely to get his or her password stolen, and thieves are less likely to carry out fraudulent transactions with the account.

Extended Validation or EV certificates are like normal SSL certificates: they encrypt your web activity to prevent eavesdropping. What makes them different is that EV certificates require the issuer to verify the site owner more thoroughly. Browsers with EV support will display an indication that the site has been verified, usually by turning part or all of the address bar green. This is intended to give the user greater confidence that the site is legit. EV certificates are currently supported by IE7 and development versions of Opera 9.50 and Firefox 3. (You can preview a version of Opera with EV support by downloading Opera 9.50 beta 2.)

(It’s worth noting that Opera 9.50 beta 2 is stricter about verifying EV certificates, and will not show PayPal with a green bar because it loads images and scripts from another site. More recent preview releases will, like IE7 and Firefox 3, be satisfied if the main page is EV and the resources are all protected by regular SSL.)

So which browsers might get turned away at the gate?

In a follow-up story, PayPal clarified that they have absolutely no intention of blocking current versions of any browsers, and that they would only block obsolete browsers on outdated or unsupported operating systems. So an Opera 9 user on Windows XP isn’t likely to get shut out of PayPal anytime soon. But a Windows 98 user might have cause for concern.

Browser detection is extremely tricky to get right, requiring frequent adjustments. It looks like PayPal intends to take the minimalist approach: Assume most browsers are capable of handling what you send them, and only block the problematic ones.

(Originally posted at Opera Watch as a follow-up to Blocking IE6)

Sorry for the lack of updates this past week. I was just way too busy prepping for our move this weekend.

A couple of interesting news bits I noticed when I got into work this morning:

It looks like I’ve been lucky with installing Windows XP Service Pack 3. I’ve had no problems with the one machine I installed it on. According to Information Week, a lot of people are having serious problems with SP3, including BSOD on AMD-based systems.

Also, NetCraft has a screenshot of a PayPal page with both the green bar of an Extended Validation (EV) SSL certificate and a cross-site scripting (XSS) vulnerability. It’s a step or two beyond the standard lock icon, but there are still limits to what an EV cert can tell you. Unfortunately PayPal and others are really trying to drum “green bar = safe” into people’s heads.