If you look at the HTML source for this NGINX post I wrote you’ll find this code.
<link rel='shortlink' href='http://wp.me/pLamj-2Lz' />
Which was inserted when I published the post via Jetpack. Shortlinks are cool.
But if you use
curl -LI on that wp.me URL you see that it goes http -> http -> https which irks me.
$ curl -LI http://wp.me/pLamj-2Lz HTTP/1.1 301 Moved Permanently Location: http://blog.dembowski.net/?p=10637 HTTP/1.1 301 Moved Permanently Location: https://blog.dembowski.net/?p=10637 HTTP/1.1 301 Moved Permanently Location: https://blog.dembowski.net/2014/i-am-nginx-and-so-can-you/ $
I like https based URLs because I want the communication between my web server and your web browser to be encrypted.
My web server does 301 redirect the browser to the https version but I don’t want any plain text http in the mix. It’s not Jetpack’s fault, I’m passing the non-SSL URL to it to get the shortlink.
Having the shortlink point to a plain http URL doesn’t fit well with my tin foil hat. Since my web sites are SSL enabled there is no reason to use unencrypted http anymore.
YOURLS to the rescue
I am pretty sure that Jetpack’s URL shortner will handle SSL based URLs in a friendly encrypted way but I’d rather use YOURLS.
YOURLS stands for Your Own URL Shortner and I’ve been using my own installation for years. In December I blew up my multisite and disabled my YOURLS plugin (and several other things). Today I made a subtle change to my shortlink installation’s config.php file.
define( 'YOURLS_SITE', 'http://dn7.me' );
was changed to this with https.
define( 'YOURLS_SITE', 'https://dn7.me' );
And just like that my short URLs are now SSL based. The old http shortlinks continue to work fine.
WP-CLI should be used in all the things
I could not find where the heck my URLs were being generated as non-SSL. If I asked in the forums or looked at the wp_get_shortlink() source code I am sure I could figure it out. But I’m lazy and instead I just used wp-cli like so.
cd /to/my/multisite/directory wp db export ~/save-me.sql wp search-replace 'http://blog.dembowski.net' 'https://blog.dembowski.net' --network
The export command was my safety net incase my backups aren’t as good as I think they are. If this hurt anything then I could put the database back right before I munged it up.
Today I published a post and it has this code and shortlink.
<link rel='shortlink' href='https://dn7.me/2ou' />
Looking at that with
curl reveals this.
$ curl -LI https://dn7.me/2ou HTTP/1.1 301 Moved Permanently Location: https://blog.dembowski.net/2015/good-product-integration-is-important/ $
The https URL sends a 301 to the destination https URL with nothing else to see. My tin foil hat is now even a little tighter.
You do know that you use Jetpack, right Jan?
I’m not really concerned about data leakage and this really is just an excercise for me. I like Jetpack and understand the implications of continuing to use it.
When you setup a web server the default port is 80 without any encryption. SSL on port 443 needs to be configured and turned on manually with x509 certs. Wouldn’t it be great if you could do away with HTTP and just use HTTPS? That’s part of what Let’s Encrypt is trying to accomplish.
As a service it’s supposed to be available mid-2015 and I can’t wait to see how that goes. Encryption everywhere is a great idea and in the 21st century there’s no excuse not to use it.