WordPress.com on SSL

If you want to know about protecting your wordpress.com login with SSL, you can read the support page about it. It shows you the checkbox you need to tick. You need to enable it first (Users -> Personal Settings: Browser Connection checkbox). It does not forces logins automatically to SSL.

The rest is somehow misleading: No, it must not slow down, and no, you should not disable mixed content warnings. Even if it’s for *.wordpress.com “only”.

Next to that I’m a bit puzzled about the fact that secure cookies are shared across all worpdress.com subdomains which not per-se must be problematic, but it’s available in the plugins dir as well, not only for the admin.

Anyway, this is probably the impact of firesheep and worpdress.com is in the process of adapting. The firesheep developer is asking around site owners what the problems are to adopt securely to SSL and to learn about the problems in the way. See codebutlers blog. Nice move! EFF is covering the topic as well from both sides, hosters and users.

This entry was posted in Pressed and tagged , , , , , . Bookmark the permalink.

3 Responses to WordPress.com on SSL

  1. Joseph Scott says:

    A few notes:

    – Browsers intentionally don’t cache SSL content to disk. We could potentially work around some of that by marking it public, but in general it still won’t be as fast as non-SSL.

    – I think the problem we ran into with the cert warnings was with wildcard certs. That’s something we should improve at some point, but haven’t yet.

    – We’ve had the HTTPS option for more than 2 years – http://en.blog.wordpress.com/2008/09/16/protect-your-blog-with-ssl/ – we regularly discuss how to improve the security of WordPress.com.

    • hakre says:

      Enabling cache for SSL users – if not already established – looks reasonable to me.

      Cert / mixed content warnings I only had on the global dashboard. The rest looks pretty good to me. I only think that it’s not advisable for non-techie users to deactivate the warnings for all wp.com subdomains. Better is to solve the problem server-side to just output SSL only links instead. That’s just from a users perspective I was a bit concerned about.

      For the subdomains I was wondering a bit. Did some checks if it is possible to aquire cookies from other sites but I came to the point that I think that this would need some flaw in wp admin core or within one of the plugins to escalate it.

      So I can’t say it’s safe but I have no fault-proof suggestion as well how to improve here. Probably to limit the cookies to the specific sub-domain which is currently not done for the sec cookies. This might conflict with the global dashboard, but as with the plugins cookie path, a third cookie could be added to work around this.

  2. Denis says:

    I’d like to second Joseph’s comment on SSL speed: browsing a site using https instead of http is, in my experience, measurably slower. It’s slow enough that I’ve disabled it on my own WP sites, sticking to logging in via SSL.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s