Hashemian Blog
Web, Finance, Technology, Running

A Simple Post-HTTP-to-HTTPS SEO Checklist

by @ 3:21 pm
Filed under: google,web — Tags: , ,

With Chrome version 62 arriving next month Google will begin making good on the promise of warning users when they land on non-secure (non-SSL, non-TLS) sites. This will be subtle at first with a light gray warning on pages that contain any input forms. This warning message will get progressively prevalent and prominent with every new version of Chrome and one must imagine other browsers will follow suit.

Another angle where HTTPS is being pushed is with AMP pages. Secure AMP pages are widely preferred by Google over the non-secure ones. In fact it seems non-secure AMP pages are not even picked up by Google News. That should give content and news sites a serious dose of inducement to go secure if they'd want better representation in the mobile world.

This blog has already covered available options to make a site secure, but once secure what can sites do to effectively promote their new secure status to search engines and by extension to their audience?

Here is checklist of steps to take once a site is migrated to the secure HTTPS/SSL.

  • Test the site with a reputable SSL/TLS utility such as https://www.ssllabs.com/ssltest/ and aim for a high grade.Make sure all pages get a green padlock. For that, all page elements' URLs must be relative or start with https:// or //. Either manually update them, use plugins for CMS's like WordPress, or use mods for servers, for example mod_substitute for apache.
  • Use header Content-Security-Policy: upgrade-insecure-requests or its meta tag equivalent. Not all browsers support this CSP header but majority do. This header instructs the browser to upgrade all HTTP elements on the page to HTTPS equivalents.
  • Use canonical headers or link tags to point to the HTTPS versions of your pages. ala, https://support.google.com/webmasters/answer/139066. The canonical tag is used to point search engines to the most desirable and valid version of a page.
  • Redirect all your HTTP pages to their HTTPS versions. What you want here is a hard or permanent redirect, also known as 301 redirect. This is best accomplished as a header response code and for that access to web server configuration is needed. There are alternative redirection methods such as using the refresh meta tag or the javascript location object, but server response header works best.
  • Use Google Search Console (previously known as Webmaster Tools) to advise Google of your site and to some extent instruct Google on crawling and indexing your pages via Sitemaps. If you already have the non-secure version of your site in Search Console that’s not enough. You must now include the HTTPS version of your site. Search Console is also a great tool for monitoring how Google interacts with your site. It even sends emails if it runs into any issues such as inability to crawl your side or finding malware.
  • If you use freebie certs, use a reputable certificate authority. For example StartSSL certificates are no longer trusted by some browsers, but Let’s Encrypt is fast gaining momentum. There are drawbacks such as lack of wildcard certificates or shorter validity durations so it takes a bit more management effort in return for no cost.
  • Utilize HTTP Strict Transport Security (HSTS) policy for your site. This policy instructs browsers to only interact with your site via HTTPS for a specified duration of time. This is strictly a response header field so access to the server configuration is necessary. It is doubtful that HSTS will improve search engine rankings, but it certainly doesn’t hurt and if a site has migrated to HTTPS, HSTS would be a wise security policy.

Like it or not, migrating to HTTPS is no longer a choice, unless one doesn’t mind being left behind. The prudent way of dealing with it is mapping out an HTTPS migration plan and once secure, taking steps to promote the new secure site.

WordPress Global Replace http to https

by @ 12:00 pm
Filed under: web — Tags: ,

If you are dealing with the pain of migrating your site from non-secure plain http to secure SSL/TLS https, then you are also dealing with the headache of making sure the elements on your pages such as images have https sources instead of http.

The reason is that if your pages are accessed over https but they contain http elements they are considered broken (mixed content) by just about all browsers. The point is that if a page is secure, everything in that page must be secure as well.

Different page elements are treated differently by browsers. As of now, Chrome loads non-secure images in the page, but the URL color goes grey instead of the reassuring green with the secure lockpad. Non-secure scripts are not even loaded, leading to page malfunction in many cases.

If you use WordPress, you know how much of a pain it is to mass replace all the image sources in your past posts from http to https. You can manually update posts which will take forever, update the backing MySQL database via SQL but that’s risky, or use a plugin but that may be overkill.

A quick way to handle this is to add a filter to transform all http occurrences to https on the fly. It won’t change the actual posts, only how they are sent to the browser. And it’s not 100%, but it’s good enough for most sites, including this one. And worst case, you can always remove it and you’ll be back to where you started.

As for the filter code, it’s a one-liner that you add to the functions.php file of your theme. It actually converts http URLs for image src’s to protocol-relative, and that does the job. Here it is and good luck:

add_filter('the_content',function($a){return preg_replace("#src=([\"'])http://#i","src=$1//",$a);});

The Long, Hard and Possibly Foolish Path to SSL/TLS Security

by @ 10:57 pm
Filed under: internet,web — Tags: , , , , , ,

... or TLS 1.2 on Fedora Core 14/FC14 and other older Linux versions

With the chorus of secure browsing  getting louder and becoming more prevalent,  HTTPS migration is becoming inevitable. Going secure is a pretty major undertaking, fraught with numerous pitfalls. It starts with the source files that produce the html pages and it could get ugly if there's even one element in a page that is called over http rather than https, no green padlock in that case. The Protocol-relative URL (//) instead of the hard-coded http:// or https:// is quite helpful to that end. That's one of side of the equation. The other is the server itself.

I run my site on an older server with an old Fedora Core OS (FC14) and by extension an older version of web server software, Apache 2.2.17. Over the years I have updated a few components here and there and fixed and customized a bunch of others, especially after new vulnerabilities have popped up. Updating the server to the latest and greatest version would be a non-trivial task for me. The old hardware may not be sufficiently supportive, much of the OS customizations will be lost, migrating the data and config files will be a pain and there will be downtime as well. Yet FC14 cannot support the newer and safer SSL/TLS technologies considered acceptable by today's browsers.

At my day job, I have access to resources to overcome this problem by fronting the web server with other servers running newer technologies. For example a combination of HAProxy and Varnish provides excellent web acceleration, load balancing, and SSL termination without making any updates to the core web server. No such luck for a small time operator such as myself with limited resources, so what to do?

One approach would be to only upgrade parts of the OS and Apache (httpd program) that deal with encryption but there isn't much in terms of online resources dealing with this topic other than the customary advice to upgrade the OS. In the end this became a long process of trial and error but it was a successful endeavor with a good bit of leaning as a bonus. Here's how I did it.

Apache 2.2.17 running on Fedora Core 14 can be configured for SSL, however it can only provide support for up to TLS1.0, with older cipher suites and the weak RSA key exchange. I had already patched OpenSSL after the Heartbleed bug had become public but what I needed were newer version of libcrypto.so.1.0.0 and libssl.so.1.0.0 libraries used by mod_ssl.so, a module used by httpd to enable SSL.

I downloaded the source and built OpenSSL version 1.0.1u. Building applications from source code in Linux is usually a three-step process, configure, make, and make install. After 'make install' The new OpenSSL libraries were placed in an alternate directory, /usr/local/ssl, instead of overwriting their main system counterparts.

Next step was to incorporate the new libcrypto.so.1.0.0 and libssl.so.1.0.0 libraries into mod_ssl.so and my tool of choice for that was patchelf. I downloaded and built patchelf 0.9.

Before using patchelf I took one step which I am not sure if it were necessary in hindsight. That step was adding the location of these new libraries to a conf file under /etc/ld.so.conf.d and executing the ldconfig command to add this new location to the library cache /etc/ld.so.cache used by the linker.

Here's an example of a command I used to replace one of the libraries in mod_ssl.so, I did the same for the other:

./patchelf --replace-needed libcrypto.so.1.0.0 libcrypto.so.1.0.0 mod_ssl.so

Then I used the ldd command to make sure mod_ssl.so was now linking to these new libraries.

Following an httpd restart and checking one of the secure pages I had the encouraging green padlock on Chrome browser. Indeed the page was using TLS1.2 now with a strong encryption/cipher. Yet the key exchange was using the obsoleted RSA. The new OpenSSL libraries had certainly made an improvement to mod_ssl.so but the strong key exchange element was missing.

To overcome that issue I had to rebuild mod_ssl.so with a newer version of Apache source code. That was version 2.2.32. configure was done with the following parameters:

./configure --enable-mods-shared="ssl"  --with-ssl=/usr/local/ssl

And after make I found the new mod_ssl.so in one of the subdirectories of the source files. I skipped the make install step to avoid possible complications of the new version installing itself in the system. Interestingly the new mod_ssl.so was already linked to the new libcrypto.so.1.0.0 and libssl.so.1.0.0 libraries I had created in the previous step. I suppose adding that directory to the library cache had helped with that.

I placed mod_ssl.so in the folder to be loaded by /etc/httpd/conf.d/ssl.conf and restarted httpd. And it failed to start with a message about a missing symbol ap_map_http_request_error! Obviously mod_ssl.so couldn't call into this function of the older httpd (or some library) version.

To fix that error I edited the file modules/ssl/ssl_engine_io.c and replaced the line:

return ap_map_http_request_error(rv, HTTP_INTERNAL_SERVER_ERROR);



I admit, this is a blind alteration with possible adverse repercussions, so I don't vouch for it. Executing make once again yielded a new mod_ssl.so and this time httpd started just fine, this time with a strong key exchange added in. Testing the site with SSL Labs gave additional confirmation that SSL encryption was indeed working fine.

If wondering, I use Let's Encrypt for free SSL certificates. The recommended utility for obtaining certificates is certbot but that tool with its overly complex and finicky python virtual environment wouldn't work under FC14. The tool that worked beautifully was getssl. It's a simple and clean, yet powerful and flexible script written as one executable file in bash script. Kudos to the getssl team for creating this robust tool.

So there you have it for enabling modern SSL/TLS in an older environment, in this case FC14. The prevailing wisdom is to abandon the old OS and start off fresh with a newer platform. I don't disagree with that philosophy and I set out to do just that when I started on this journey. In the end, my way was possibly more difficult and more prone to pitfalls but ultimately it ended up being more satisfying and more instructive.

I haven't migrated the entire site to HTTPS yet, but you can click secure whoami to view and examine the first secure page.


Knee ACL Injury? Meniscus Tear? Stress Fracture? MRI Diagnosis

by @ 9:28 pm
Filed under: health,running-hiking — Tags: , , ,

I have been a runner for a major part of my life. Not champion material, not elite, not even great, just average. My marathon times are in the 4:10-ish area, but I do run consistently and over the decades it has become an inexorable part of my life.

Problem is that running and aging don't coexist very well. Sure you see news articles about octogenarians, nonagenarians, and centenarians running marathons but that's why these folks make the news. They are a rare breed. When is the last time an average 20 year-old made the news for running an average time marathon?

I am certainly not immune to the ravages of aging. There have been back issues, herniated discs, sprained ankles, joint pain, muscle tension and breathing and stamina problems. So far I have been lucky that many of the symptoms have healed or at least improved allowing me to resume running after some period of rest.

The latest challenge was severe knee pain that ended up sidelining me for three months. It all started simple and small enough. A few months ago I started noticing a bit of pain in my right knee after long runs. I have had some knee pain for years arising from knee cap scraping but it has been tolerable. This pain was noticeably different but it would subside after a day and so I continued with my normal running schedule.

Turns out that I should have listened to my body and reduced the level of activity because a few weeks later I was hobbling, almost unable to walk, let alone run. There was considerable pain in the lateral side (the crotch side) of the right knee and it wasn't healing. Pain medication, icing, sports gels, and knee braces weren't helping. I suddenly became sedentary and had to use a stick to walk even a short distance. Even sleeping was difficult as I couldn't fully extend and straighten my right leg without feeling excruciating knee pain.

I searched for my symptoms online and talked with coworkers who might have had sports injuries themselves or had children with sports injuries. The most mentioned diagnoses were ACL injury and meniscus tear. I was able to eliminate ACL injuries or tears rather quickly. As I was explained, an ACL tear would have led to an inability to even stand up. That wasn't quite my issue. I could stand or even walk, albeit with much pain.

A meniscus tear seemed like a much more likely candidate. My symptoms were very similar to those mentioned online and others with meniscus tear experience. There was pain on the side of the knee (lateral side), I couldn't straighten my leg, and the location of the pain was tender to the touch.

And so as I finally visited my orthopedic doctor, I resigned myself to the fact that I had a meniscus tear, possibly requiring surgery. My doctor seemed to be in agreement but of course needed more evidence and so an MRI was ordered.

A couple of weeks later with the MRI results online, I pored over the images comparing them to online images of torn meniscus but my untrained eye couldn't determine if there was a tear or not. Here is one of the images.

A few days later, at the orthopedic office, my doctor, handed me the MRI report, telling me that there was no tear. Say what? The circled area is the meniscus. Lots of white around that area indicating fluid and bone bruising, but as it turned out, no tears. This was in the report conclusion:

MRI findings suggestive of a subchondral nondisplaced fracture centered at the mid aspect of the medial femoral condyle

No discrete meniscal or ligament tear seen

In other words, and as my doctor explained, this was one or more small stress fractures with some amount of fluid surrounding it. His orders were to stay off running for 3 months, take pain killers and ice as necessary.

Over the next few weeks I took short walks, painful at first, and less painful as time passed. As the pain slowly subsided, I took longer walks, discarded the tree branch I was using as a walking stick. Eventually my knee became pain-free.

A couple of weeks ago I finally had my first small jog, and today I had an 8-mile run, slow, gentle, but pain-free.

My grandfather used to say, pain arrives in an instant and takes a long time to leave. This one didn't exactly arrive in an instant but it sure took a long time to leave, dropping me a few lessons during its unwelcome stay. Listen to your body, pain is telling you to slow down or stop. Ignore the pain and you will pay the price. It's ok to pause a habitual activity such as running while recovering. Walking isn't the same but it's a good low impact substitute. And finally, Internet searches and anecdotal accounts are interesting and educational but no substitute for a professional diagnosis.

Powered by

Read Financial Markets  |   Home  |   Blog  |   Web Tools  |   News  |   Articles  |   FAQ  |   About  |   Privacy  |   Contact
Donate Bitcoin: 1K9TzBvQ2oaEb4tX9t2vKDtZouMcpfV6QF
© 2001-2017 Robert Hashemian   Powered by Hashemian.com