https – CSS-Tricks https://css-tricks.com Tips, Tricks, and Techniques on using Cascading Style Sheets. Thu, 15 Apr 2021 15:46:21 +0000 en-US hourly 1 https://wordpress.org/?v=6.4.3 https://i0.wp.com/css-tricks.com/wp-content/uploads/2021/07/star.png?fit=32%2C32&ssl=1 https – CSS-Tricks https://css-tricks.com 32 32 45537868 HTTPS is Easy! https://css-tricks.com/https-is-easy/ https://css-tricks.com/https-is-easy/#comments Wed, 05 Feb 2020 21:19:46 +0000 https://css-tricks.com/?p=302802 I’ve been guilty of publicly bemoaning the complexity of HTTPS. In the past, I’ve purchased SSL certificates from third-party vendors and had trouble installing them. I’ve had certificates expire and had to scramble to fix them. I’ve had to poke …


HTTPS is Easy! originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

]]>
I’ve been guilty of publicly bemoaning the complexity of HTTPS. In the past, I’ve purchased SSL certificates from third-party vendors and had trouble installing them. I’ve had certificates expire and had to scramble to fix them. I’ve had to poke and prod hosting companies to help me ensure things were going to renew correctly, and left unsatisfied.

But I’d say in the last few years, this has really chilled out. CSS-Tricks went HTTPS around five years ago, so we’re well past any struggles with insecure content or anything like that. These days my host (and sponsor) Flywheel makes it a flip of a switch in their admin, so it’s entirely no-brainer. The things I have on Netlify are automatically HTTPS. I also tend to put Cloudflare in front of everything, because of all the flip-switch security and performance things they offer, mostly for free. HTTPS is just getting a lot easier.

The name of this blog post is the name of this little microsite project from Troy Hunt: HTTPS is Easy! It’s a four-part series of five-minute videos walking through the process of adding enterprise-grade security to a site quickly and for free with Cloudflare. It almost feels like an ad for Cloudflare, and I couldn’t care less if it is, but Troy says:

[…] this isn’t a commercial activity on my behalf; Cloudflare didn’t engage me to create this and it’ll come as a surprise to them the first time they see it.

It really is easy and free, so I feel like I’m doing my duty here in making up for past complaints about HTTPS.

Part of what helps me feel more confident is minimizing the number of setups I have for different things. All my WordPress sites are on Flywheel — they aren’t scattered around, so I don’t have to learn multiple systems. All my deployment is through Buddy. All my domains are on a single registrant, so what I learn in managing one domain is useful for all of them. All my sites run through Cloudflare, so I feel confident in my management skills there. This kind of consolidation is good at keeping my stress levels low.


HTTPS is Easy! originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

]]>
https://css-tricks.com/https-is-easy/feed/ 1 302802
Weekly Platform News: Upgrading Navigations to HTTPS, Sale of .org Domains, New Browser Engine https://css-tricks.com/weekly-platform-news-upgrading-navigations-to-https-sale-of-org-domains-new-browser-engine/ Thu, 05 Dec 2019 22:34:31 +0000 https://css-tricks.com/?p=299954 In this week’s roundup: DuckDuckGo gets smarter encryption, a fight over the sale of dot org domains, and a new browser engine is in the works.

Let’s get into the news!

DuckDuckGo upgrades and open-sources its encryption

DuckDuckGo has open-sourced …


Weekly Platform News: Upgrading Navigations to HTTPS, Sale of .org Domains, New Browser Engine originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

]]>
In this week’s roundup: DuckDuckGo gets smarter encryption, a fight over the sale of dot org domains, and a new browser engine is in the works.

Let’s get into the news!

DuckDuckGo upgrades and open-sources its encryption

DuckDuckGo has open-sourced its “Smarter Encryption” technology that enables upgrading from HTTP to HTTPS, and Pinterest (a popular social network) is already using it for outbound traffic — when people navigate from Pinterest to other websites — with great results: Their outbound HTTPS traffic increased from 60% to 80%.

DuckDuckGo uses its crawler to automatically generate and maintain a huge list of websites that support HTTPS, approximately 12 million entries. For comparison, Chromium’s HSTS Preload List contains only about 85 thousand entries.

(via DuckDuckGo)

Nonprofits oppose the sale of the .org domain

A coalition of organizations consisting of EFF, Wikimedia, and many others, are urging the Internet Society to stop the sale of the nonprofit organization that operates the .org domain to an investment firm.

Non-governmental organizations (NGOs) all over the world rely on the .org top-level domain. […] We cannot afford to put them into the hands of a private equity firm that has not earned the trust of the NGO community.

In a separate blog post, Mark Surman (CEO of Mozilla Foundation) urges the Internet Society to “step back and provide public answers to questions of interest to the public and the millions of organizations that have made dot org their home online for the last 15 years.”

(via Elliot Harmon)

A new browser engine is in development

Ekioh (a company from Cambridge, U.K.) is developing an entirely new browser engine for their Flow browser, which also includes Mozilla’s SpiderMonkey as its JavaScript engine. The browser can already run web apps such as Gmail (mostly), and the company plans to release it on desktop soon.

(via Flow Browser)

More news…

Read more news in my weekly newsletter for web developers. Pledge as little as $2 per month to get the latest news from me via email every Monday.

More News →


Weekly Platform News: Upgrading Navigations to HTTPS, Sale of .org Domains, New Browser Engine originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

]]>
299954
Weekly Platform News: Impact of Third-Party Code, Passive Mixed Content, Countries with the Slowest Connections https://css-tricks.com/weekly-platform-news-impact-of-third-party-code-passive-mixed-content-countries-with-the-slowest-connections/ Thu, 10 Oct 2019 17:32:18 +0000 https://css-tricks.com/?p=297145 In this week’s roundup, Lighthouse sheds light on third-party scripts, insecure resources will get blocked on secure sites, and many country connection speeds are still trying to catch up to others… literally.


Measure the impact of third-party code during page…


Weekly Platform News: Impact of Third-Party Code, Passive Mixed Content, Countries with the Slowest Connections originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

]]>
In this week’s roundup, Lighthouse sheds light on third-party scripts, insecure resources will get blocked on secure sites, and many country connection speeds are still trying to catch up to others… literally.


Measure the impact of third-party code during page load

Lighthouse, Chrome’s built-in auditing tool, now shows a warning when the impact of third-party code on page load performance is too high. The pre-existing “Third-party usage” diagnostic audit will now fail if the total main-thread blocking time caused by third-parties is larger than 250ms during page load.

Note: This feature was added in Lighthouse version 5.3.0, which is currently available in Chrome Canary.

(via Patrick Hulce)

Passive mixed content is coming to an end

Currently, browsers still allow web pages loaded over a secure connection (HTTPS) to load images, videos, and audio over an insecure connection. Such insecurely-loaded resources on securely-loaded pages are known as “passive mixed content,” and they represent a security and privacy risk.

An insecurely-loaded image can allow an attacker to communicate incorrect information to the user (e.g., a fabricated stock chart), mutate client-side state (e.g., set a cookie), or induce the user to take an unintended action (e.g., changing the label on a button).

Starting next February, Chrome will auto-upgrade all passive mixed content to https:, and resources that fail to load over https: will be blocked. According to data from Chrome Beta, auto-upgrade currently fails for about 30% of image loads.

(via Emily Stark)

Fast connections are still not common in many countries

Data from Chrome UX Report shows that there are still many countries and territories in the world where most people access the Internet over a 3G or slower connection. (This includes a number of small island nations that are not visible on this map.)

(via Paul Calvano)

More news…

Read even more news in my weekly Sunday issue that can be delivered to you via email every Monday morning.

More News →


Weekly Platform News: Impact of Third-Party Code, Passive Mixed Content, Countries with the Slowest Connections originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

]]>
297145
Secure Contexts Everywhere https://css-tricks.com/secure-contexts-everywhere/ Fri, 19 Jan 2018 18:55:07 +0000 http://css-tricks.com/?p=265715 Anne van Kesteren for Mozilla says:

Effective immediately, all new features that are web-exposed are to be restricted to secure contexts. Web-exposed means that the feature is observable from a web page or server, whether through JavaScript, CSS, HTTP, media


Secure Contexts Everywhere originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

]]>
Anne van Kesteren for Mozilla says:

Effective immediately, all new features that are web-exposed are to be restricted to secure contexts. Web-exposed means that the feature is observable from a web page or server, whether through JavaScript, CSS, HTTP, media formats, etc. A feature can be anything from an extension of an existing IDL-defined object, a new CSS property, a new HTTP response header, to bigger features such as WebVR. In contrast, a new CSS color keyword would likely not be restricted to secure contexts.

In other words, if your site isn’t HTTPS, you won’t get new web tech features. Holy jeepers. The reasoning is the web should be using HTTPS, so this is our way of beating you with a stick if you try to use fancy features without going HTTPS first.

It’ll be fascinating to watch the first major feature drop and if they stick to their word here. The web dev forums of the internet will overflow with WHY DOESN’T grid-gap WORK WITH MY FLEXBOX? (or some likely coming-soon feature) questions and the answer will be: talk to your server team. What if they drop container queries behind this? That would be a hilarious devastating tornado of developer fury.

To Shared LinkPermalink on CSS-Tricks


Secure Contexts Everywhere originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

]]>
265715
Content Security Policy: The Easy Way to Prevent Mixed Content https://css-tricks.com/content-security-policy-easy-way-prevent-mixed-content/ https://css-tricks.com/content-security-policy-easy-way-prevent-mixed-content/#comments Tue, 14 Nov 2017 15:09:06 +0000 http://css-tricks.com/?p=262064 I recently learned about a browser feature where, if you provide a special HTTP header, it will automatically post to a URL with a report of any non-HTTPS content. This would be a great thing to do when transitioning a …


Content Security Policy: The Easy Way to Prevent Mixed Content originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

]]>
I recently learned about a browser feature where, if you provide a special HTTP header, it will automatically post to a URL with a report of any non-HTTPS content. This would be a great thing to do when transitioning a site to HTTPS, for example, to root out any mixed content warnings. In this article, we’ll implement this feature via a small WordPress plugin.

What is mixed content?

“Mixed content” means you’re loading a page over HTTPS page, but some of the assets on that page (images, videos, CSS, scripts, scripts called by scripts, etc) are loaded via plain HTTP.

A browser pop up window of a security warning about unsecure content.
A browser warning about mixed content.

I’m going to assume that we’re all too familiar with this warning and refer the reader to this excellent primer for more background on mixed content.

What is Content Security Policy?

A Content Security Policy (CSP) is a browser feature that gives us a way to instruct the browser on how to handle mixed content errors. By including special HTTP headers in our pages, we can tell the browser to block, upgrade, or report on mixed content. This article focuses on reporting because it gives us a simple and useful entry point into CSP’s in general.

CSP is an oddly opaque name. Don’t let it spook you, as it’s very simple to work with. It seems to have terrific support per caniuse. Here’s how the outgoing report is shaped in Chrome:

{
    "csp-report": {
        "document-uri":"http://localhost/wp/2017/03/21/godaddys-micro-dollars/",
        "referrer":"http://localhost/wp/",
        "violated-directive":"style-src",
        "effective-directive":"style-src",
        "original-policy":"default-src https: 'unsafe-inline' 'unsafe-eval'; report-uri http://localhost/wp/wp-json/csst_consecpol/v1/incidents",
        "disposition":"report",
        "blocked-uri":"http://localhost/wp/wp-includes/css/dashicons.min.css?ver=4.8.2",
        "status-code":200,
        "script-sample":""
    }
}

Here’s what it looks like in its natural habitat:

The outgoing report in the network panel of Chrome’s inspector.

What do I do with this?

What you’re going to have to do, is tell the browser what URL to send that report to, and then have some logic on your server to listen for it. From there, you can have it write to a log file, a database table, an email, whatever. Just be aware that you will likely generate an overwhelming amount of reports. Be very much on guard against self-DOSing!

Can I just see an example?

You may! I made a small WordPress plugin to show you. The plugin has no UI, just activate it and go. You could peel most of this out and use it in a non-WordPress environment rather directly, and this article does not assume any particular WordPress knowledge beyond activating a plugin and navigating the file system a bit. We’ll spend the rest of this article digging into said plugin.


Sending the headers

Our first step will be to include our content security policy as an HTTP header. Check out this file from the plugin. It’s quite short, and I think you’ll be delighted to see how simple it is.

The relevant bit is this line:

header( "Content-Security-Policy-Report-Only: default-src https: 'unsafe-inline' 'unsafe-eval'; report-uri $rest_url" );

There a lot of args we can play around with there.

  • With the Content-Security-Policy-Report-Only arg, we’re saying that we want a report of the assets that violate our policy, but we don’t want to actually block or otherwise affect them.
  • With the default-src arg, we’re saying that we’re on the lookout for all types of assets, as opposed to just images or fonts or scripts, say.
  • With the https arg, we’re saying that our policy is to only approve of assets that get loaded via https.
  • With the unsafe-inline and unsafe-eval args, we’re saying we care about both inline resources like a normal image tag, and various methods for concocting code from strings, like JavaScripts eval() function.
  • Finally, most interestingly, with the report-uri $rest_url arg, we’re giving the browser a URL to which it should send the report.

If you want more details about the args, there is an excellent doc on Mozilla.org. It’s also worth noting that we could instead send our CSP as a meta tag although I find the syntax awkward and Google notes that it is not their preferred method.

This article will only utilize the HTTP header technique, and you’ll notice that in my header, I’m doing some work to build the report URL. It happens to be a WP API URL. We’ll dig into that next.

Registering an endpoint

You are likely familiar with the WP API. In the old days before we had the WP API, when I needed some arbitrary URL to listen for a form submission, I would often make a page, or a post of a custom post type. This was annoying and fragile because it was too easy to delete the page in wp-admin without realizing what it was for. With the WP API, we have a much more stable way to register a listener, and I do so in this class. There are three points of interest in this class.

In the first function, after checking to make sure my log is not getting too big, I make a call to register_rest_route(), which is a WordPress core function for registering a listener:

function rest_api_init() {

    $check_log_file_size = $this -> check_log_file_size();
    if( ! $check_log_file_size ) { return FALSE; }

    ...                

    register_rest_route(
        CSST_CONSECPOL . '/' . $rest_version,
        '/' . $rest_ep . '/',
        array(
           'methods'  => 'POST',
           'callback' => array( $this, 'cb' ),
        )
    );

}

That function also allows me to register a callback function, which handles the posted CSP report:

function cb( \WP_REST_Request $request ) {

    $body = $request -> get_body();
    $body = json_decode( $body, TRUE );
    $csp_report = $body['csp-report'];

    ...

    $record = new Record( $args );
    $out = $record -> get_log_entry();

}

In that function, I massage the report in it’s raw format, into a PHP array that my logging class will handle.

Creating a log file

In this class, I create a directory in the wp-content folder where my log file will live. I’m not a big fan of checking for stuff like this on every single page load, so notice that this function first checks to see if this is the first page load since a plugin update, before bothering to make the directory.

function make_directory() {

    $out = NULL;

    $update = new Update;
    if( ! $update -> get_is_update() ) { return FALSE; }

    $log_dir_path = $this -> meta -> get_log_dir_path();
    $file_exists = file_exists( $log_dir_path );

    if( $file_exists ) { return FALSE; }

    $out = mkdir( $log_dir_path, 0775, TRUE );

    return $out;

}

That update logic is in a different class and is wildly useful for lots of things, but not of special interest for this article.

Logging mixed content

Now that we have CSP reports getting posted, and we have a directory to log them to, let’s look at how to actually convert a report into a log entry,

In this class I have a function for adding new records to our log file. It’s interesting that much of the heavy lifting is simply a matter of providing the a arg to the fopen() function:

function add_row( $array ) {

    // Open for writing only; place the file pointer at the end of the file. If the file does not exist, attempt to create it.
    $mode = 'a';

    // Open the file.
    $path   = $this -> meta -> get_log_file_path();
    $handle = fopen( $path, $mode );

    // Add the row to the spreadsheet.
    fputcsv( $handle, $array );

    // Close the file.
    fclose( $handle );

    return TRUE;

}

Nothing particular to WordPress here, just a dude adding a row to a csv in a normal-ish PHP manner. Again, if you don’t care for the idea of having a log file, you could have it send an email or write to the database, or whatever seems best.

Caveats

At this point we’ve covered all of the interesting highlights from my plugin, and I’d advice on offer a couple of pitfalls to watch out for.

First, be aware that CSP reports, like any browser feature, are subject to cross-browser differences. Look at this shockingly, painstakingly detailed report on such differences.

Second, be aware that if you have a server configuration that prevents mixed content from being requested, then the browser will never get a chance to report on it. In such a scenario, CSP reports are more useful as a way to prepare for a migration to https, rather than a way to monitor https compliance. An example of this configuration is Cloudflare’s “Always Use HTTPS“.

Finally, the self-DOS issue bears repeating. It’s completely reasonable to assume that a popular site will rack up millions of reports per month. Therefore, rather than track the reports on your own server or database, consider outsourcing this to a service such as httpschecker.net.

Next steps

Some next steps specific to WordPress would be to add a UI for downloading the report file. You could also store the reports in the database instead of in a file. This would make it economical to, say, determine if a new record already exists before adding it as a duplicate.

More generally, I would encourage the curious reader to experiment with the many possible args for the CSP header. It’s impressive that so much power is packed into such a terse syntax. It’s possible to handle requests by asset type, domain, protocol — really almost any combination imaginable.


Content Security Policy: The Easy Way to Prevent Mixed Content originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

]]>
https://css-tricks.com/content-security-policy-easy-way-prevent-mixed-content/feed/ 4 262064
Switching Your Site to HTTPS on a Shoestring Budget https://css-tricks.com/switching-site-https-shoestring-budget/ https://css-tricks.com/switching-site-https-shoestring-budget/#comments Mon, 04 Sep 2017 14:17:11 +0000 http://css-tricks.com/?p=259594 Google’s Search Console team recently sent out an email to site owners with a warning that Google Chrome will take steps starting this October to identify and show warnings on non-secure sites that have form inputs.

Here’s the notice that …


Switching Your Site to HTTPS on a Shoestring Budget originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

]]>
Google’s Search Console team recently sent out an email to site owners with a warning that Google Chrome will take steps starting this October to identify and show warnings on non-secure sites that have form inputs.

Here’s the notice that landed in my inbox:

The notice from the Google Search Console team regarding HTTPS support

If your site URL does not support HTTPS, then this notice directly affects you. Even if your site does not have forms, moving over to HTTPS should be a priority, as this is only one step in Google’s strategy to identify insecure sites. They state this clearly in their message:

The new warning is part of a long term plan to mark all pages served over HTTP as “not secure”.

Current Chrome’s UI for a site with HTTP support and a site with HTTPS

The problem is that the process of installing SSL certificates and transitioning site URLs from HTTP to HTTPS—not to mention editing all those links and linked images in existing content—sounds like a daunting task. Who has time and wants to spend the money to update a personal website for this?

I use GitHub Pages to host a number sites and projects for free—including some that use custom domain names. To that end, I wanted to see if I could quickly and inexpensively convert a site from HTTP to HTTPS. I wound up finding a relatively simple solution on a shoestring budget that I hope will help others. Let’s dig into that.

Enforcing HTTPS on GitHub Pages

Sites hosted on GitHub Pages have a simple setting to enable HTTPS. Navigate to the project’s Settings and flip the switch to enforce HTTPS.

The GitHub Pages setting to enforce HTTPS on a project

But We Still Need SSL

Sure, that first step was a breeze, but it’s not the full picture of what we need to do to meet Google’s definition of a secure site. The reason is that enabling the HTTPS setting neither provides nor installs a Secure Sockets Layer (SSL) certificate to a site that uses a custom domain. Sites that use the default web address provided by GitHub Pages are fully secure with that setting, but those of us that use a custom domain have to go the extra step of securing SSL at the domain level.

That’s a bummer because SSL, while not super expensive, is yet another cost and likely one you may not want to incur when you’re trying to keep costs down. I wanted to find a way around this.

We Can Get SSL From a CDN … for Free!

This is where Cloudflare comes in. Cloudflare is a Content Delivery Network (CDN) that also provides distributed domain name server services. What that means is that we can leverage their network to set up HTTPS. The real kicker is that they have a free plan that makes this all possible.

It’s worth noting that there are a number of good posts here on CSS-Tricks that tout the benefits of a CDN. While we’re focused on the security perks in this post, CDNs are an excellent way to help reduce server burden and increase performance.

From here on out, I’m going to walk through the steps I used to connect Cloudflare to GitHub Pages so, if you haven’t already, you can snag a free account and follow along.

Step 1: Select the “+ Add Site” option

First off, we have to tell Cloudflare that our domain exists. Cloudflare will scan the DNS records to verify both that the domain exists and that the public information about the domain are accessible.

Cloudflare’s “Add Website” Setting

Step 2: Review the DNS records

After Cloudflare has scanned the DNS records, it will spit them out and display them for your review. Cloudflare indicates that it believes things are in good standing with an orange cloud in the Status column. Review the report and confirm that the records match those from your registrar. If all is good, click “Continue” to proceed.

The DNS record report in Cloudflare

Step 3: Get the Free Plan

Cloudflare will ask what level of service you want to use. Lo and behold! There is a free option that we can select.

Cloudflare’s free plan option

Step 4: Update the Nameservers

At this point, Cloudflare provides us with its server addresses and our job is to head over to the registrar where the domain was purchased and paste those addresses into the DNS settings.

Cloudflare provides the nameservers for updated the registrar settings.

It’s not incredibly difficult to do this, but can be a little unnerving. Your registrar likely has instructions for how to do this. For example, here are GoDaddy’s instructions for updating nameservers for domains registered through their service.

Once you have done this step, your domain will effectively be mapped to Cloudflare’s servers, which will act as an intermediary between the domain and GitHub Pages. However, it is a bit of a waiting game and can take Cloudflare up to 24 hours to process the request.

If you are using GitHub Pages with a subdomain instead of a custom domain, there is one extra step you are required to do. Head over to your GitHub Pages settings and add a CNAME record in the DNS settings. Set it to point to <your-username>.github.io, where <your-username> is, of course, your GitHub account handle. Oh, and you will need to add a CNAME text file to the root of your GitHub project which is literally a text file named CNAME with your domain name in it.

Here is a screenshot with an example of adding a GitHub Pages subdomain as a CNAME record in Cloudflare’s settings:

Adding a GitHub Pages subdomain to Cloudflare

Step 5: Enable HTTPS in Cloudflare

Sure, we’ve technically already done this in GitHub Pages, but we’re required to do it in Cloudflare as well. Cloudflare calls this feature “Crypto” and it not only forces HTTPS, but provides the SSL certificate we’ve been wanting all along. But we’ll get to that in just a bit. For now, enable Crypto for HTTPS.

The Crypto option in Cloudflare’s main menu

Turn on the “Always use HTTPS” option:

Enable HTTPS in the Cloudflare settings

Now any HTTP request from a browser is switched over to the more secure HTTPS. We’re another step closer to making Google Chrome happy.

Step 6: Make Use of the CDN

Hey, we’re using a CDN to get SSL, so we may as well take advantage of its performance benefits while we’re at it. We can speed up performance by reducing files automatically and extend browser cache expiration.

Select the “Speed” option in the settings and allow Cloudflare to auto minify our site’s web assets:

Allow Cloudflare to minify the site’s web assets

We can also set the expiration on browser cache to maximize performance:

Set the browser cache in Cloudflare’s Speed settings

By moving the expiration out date a longer than the default option, the browser will refrain itself from asking for a site’s resources with each and every visit—that is, resources that more than likely haven’t been changed or updated. This will save visitors an extra download on repeat visits within a month’s time.

Step 7: Make External Resource Secure

If you use external resources on your site (and many of us do), then those need to be served securely as well. For example, if you use a Javascript framework and it is not served from an HTTP source, that blows our secure cover as far as Google Chrome is concerned and we need to patch that up.

If the external resource you use does not provide HTTPS as a source, then you might want to consider hosting it yourself. We have a CDN now that makes the burden of serving it a non-issue.

Step 8: Activate SSL

Woot, here we are! SSL has been the missing link between our custom domain and GitHub Pages since we enabled HTTPS in the GitHub Pages setting and this is where we have the ability to activate a free SSL certificate on our site, courtesy of Cloudflare.

From the Crypto settings in Cloudflare, let’s first make sure that the SSL certificate is active:

Cloudflare shows an active SSL certificate in the Crypto settings

If the certificate is active, move to “Page Rules” in the main menu and select the “Create Page Rule” option:

Create a page rule in the Cloudflare settings

…then click “Add a Setting” and select the “Always use HTTPS” option:

Force HTTPS on that entire domain! Note the asterisks in the formatting, which is crucial.

After that click “Save and Deploy” and celebrate! We now have a fully secure site in the eyes of Google Chrome and didn’t have to touch a whole lot of code or drop a chunk of change to do it.

In Conclusion

Google’s push for HTTPS means front-end developers need to prioritize SSL support more than ever, whether it’s for our own sites, company sites, or client sites. This move gives us one more incentive to make the move and the fact that we can pick up free SSL and performance enhancements through the use of a CDN makes it all the more worthwhile.

Have you written about your adventures moving to HTTPS? Let me know in the comments and we can compare notes. Meanwhile, enjoy a secure and speedy site!


Switching Your Site to HTTPS on a Shoestring Budget originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

]]>
https://css-tricks.com/switching-site-https-shoestring-budget/feed/ 30 259594
Just Another HTTPS Nudge https://css-tricks.com/just-another-https-nudge/ https://css-tricks.com/just-another-https-nudge/#comments Fri, 03 Mar 2017 13:56:29 +0000 http://css-tricks.com/?p=251929 I was strongly reminded about the scariness of non-secure websites the other day.

I’m using Xfinity as an internet service provider, and they give you a device that is both a cable modem and a router.

Here’s a tiny bit …


Just Another HTTPS Nudge originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

]]>
I was strongly reminded about the scariness of non-secure websites the other day.

I’m using Xfinity as an internet service provider, and they give you a device that is both a cable modem and a router.

Here’s a tiny bit of backstory. I use a VPN, and I discovered that in using their modem directly, the VPN wouldn’t work. I’m not sure why. I didn’t dig into it very far, because I have a modem of my own I’d prefer to use. So I plugged that in, which worked… but not particularly well. The connection was spotty and slow, even right in my own house.

I think (maybe?) it was competing WiFi signals from the two routers sitting right next to each other. Don’t quote me on that. The reason I think that is because, fortunately, I was able to turn off the router on the Xfinity device, and that solved the problem. Thde speed and connectivity was back. To their credit, it was really fast. The Xfinity device has a featured called “Bridge Mode” that is specifically for turning off the router so that you can use your own. I was able to enable that, use my own router, get the speed back, and connect to the VPN.

Win! That lasted for a few months. Then recently there was some weird big internet outage in our area. Xfinity notified us about it. They had to push some updates or something to our device, and that broke everything again. I struggled with it for days, but what ultimately worked was turning off Bridge Mode, and turning it back on again (isn’t it always?).

In those in-between days, the only thing I could figure out to get online was to connect to the SSID “xfinitywifi” that this router seemed to be emitting. This “xfinity” network is unusual because it behaves kinda like a coffee shop or university hotspot in that it pops up that weird browser modal and you have to log in with your (Xfinity) credentials. It’s a value-add kinda thing for their service. Their routers are dotted all over the place, so if you’re a customer of theirs, you get internet (“for free”) a lot of places. My fiance was at the doctor the other day, and she was using it there.

If that’s the network you’re connected to, Xfinity performs man-in-the-middle attacks on websites to send you messages. Here’s an example of me just looking at a (non-secure) website:

Man-in-the-middle, meaning, this website had no such popup in its code. Xfinity intercepted the request, saw it was a website, and forcefully injected its own code into the site. In this case, to advertise an app and to tell you about security. Ooozing with irony, that.

If they can do that, imagine what else they can do. (Highly recommended listening: ShopTalk #250) They could get even more forceful with advertising. Swap out existing advertising with their own. Install a keylogger. Report back information about what you’re doing and where you are. You might not even know if anything is happening at all.

This might seem a little tin foil hatish, but realize: they’ve already been incentivized to do this. All the incentive is there to keep milking value out of this superpower they have.

Some good news: Individual websites can stop this with HTTPS. That’s a massively good step. With HTTPS, the traffic packets are encrypted and Xfinity can’t read or manipulate them effectively. Through metadata, they might be able to guess what they are (e.g. know you’re streaming a video and throttle speed), but there isn’t much else they can do.

It’s not just this one indiscretion, Xfinity also uses this tactic to send you other messages.

It’s this double whammy of scary:

  • Seriously?! You require me to have a box in my house that broadcasts a public WiFi hotspot that I can’t turn off? You’re automatically opted into it, but you can turn it off.
  • Seriously?! You use that hotspot to perform man-in-the-middle attacks on anybody using it?

I’m sure it’s not just Xfinity, it’s just that’s what I’m using now and have now seen it with my own eyes. To be clear, I’m sure I signed something that allows them to do everything they are doing and I don’t think anything they are doing is technically illegal (again, don’t quote me on that).

Being upset at them, and telling them about it, is a good step. Fighting back is another. Internet access is vital, so you have to use something, but if you have an option, is there an ISP that doesn’t do this available to you? Use them. Money talks.

Again, HTTPS solves this on a per-website basis. Jeff Atwood sums this up pretty well:

  1. You have an unalienable right to privacy, both in the real world and online. And without HTTPS you have zero online privacy – from anyone else on your WiFi, from your network provider, from website operators, from large companies, from the government.

  2. The performance penalty of HTTPS is gone, in fact, HTTPS arguably performs better than HTTP on modern devices.

  3. Using HTTPS means nobody can tamper with the content in your web browser. This was a bit of an abstract concern five years ago, but these days, there are more and more instances of upstream providers actively mucking with the data that passes through their pipes. For example, if Comcast detects you have a copyright strike, they’ll insert banners into your web contentall your web content! And that’s what the good guy scenario looks like – or at least a corporation trying to follow the rules. Imagine what it looks like when someone, or some large company, decides the rules don’t apply to them?

The move to HTTPS is non-trivial, and introduces somewhat complicated dependencies. It’s easy to forget to renew your certificate and break your entire website just like that. I’m not arguing against HTTPS (exactly the opposite), but you should know that it requires some upfront work and some diligent maintenance.

If you’re on WordPress like me, I wrote up how I moved to all-HTTPS going on two years ago. It involved a little database work even, getting URL’s pointing to the right places.

SSL certificates (the main prerequisite for HTTPS) also have traditionally cost money. No more! Let’s Encrypt is here:

Lets Encrypt is a free, automated, and open Certificate Authority.

There is an in-progress WordPress plugin for it. Let’s hope that gets off the ground. Just a few days ago I used the Let’s Encrypt Plesk extention to put HTTPS on ShopTalk’s website and it took me like 5 minutes. I’ll have to write that up soon.

Also check out the really excellent Moving To HTTPS Guide:

A community site to help site owners migrate to HTTPS with a simple tested process. Allowing you to filter the plan based on multiple platforms (WordPress, Magento, and more), hosting environments (cPanel, Apache, and more) along with the level of control / access you have over the site.


Just Another HTTPS Nudge originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

]]>
https://css-tricks.com/just-another-https-nudge/feed/ 14 251929
Moving to HTTPS on WordPress https://css-tricks.com/moving-to-https-on-wordpress/ https://css-tricks.com/moving-to-https-on-wordpress/#comments Fri, 06 Mar 2015 17:59:44 +0000 http://css-tricks.com/?p=197099 I just recently took CSS-Tricks “HTTPS everywhere”. That is, every URL on this site enforces the HTTPS (SSL) protocol. Non-secure HTTP requests get redirected to HTTPS. Here are some notes on that journey.

Why do it?

  • General security. When you


Moving to HTTPS on WordPress originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

]]>
I just recently took CSS-Tricks “HTTPS everywhere”. That is, every URL on this site enforces the HTTPS (SSL) protocol. Non-secure HTTP requests get redirected to HTTPS. Here are some notes on that journey.

Why do it?

  • General security. When you enforce HTTPS, you’re guaranteeing no information passed between the server and client can be intercepted and stolen or messed with in any way. That’s great for a site like this that has a login system and accepts credit cards in some places and things like that.
  • The site as it is intended. I’ve heard of examples like hotel WiFi system and even ISPs that mess with HTTP traffic and do things like insert their own advertising code. Can’t do that over HTTPS.
  • SEO. Google says you’ll rank higher. Horse’s mouth.
  • Prereq. I can’t seem to find any good links on this, but I’m under the assumption that HTTPS is required for some/all of the stuff for SPDY / HTTP/2 – which everyone agrees is awesome and super fast. I want to make sure I’m ready so I can start moving forward on that.
  • Geek cred. Duh.

1. Get an SSL certificate

Not optional. This is how it works. I’ve done this a bunch of times in my life and it’s never overly comfortable. You just need to follow instructions closely. I’ve bought them in the past from discount providers and actually had it work fine, but it’s a more manual process.

CSS-Tricks is happily on Media Temple, and they provide SSL as a service, and I’m more than happy to pay for that to have it installed painlessly by professionals.

When the SSL certificate is installed properly, you should be able to visit your site (any URL) at either HTTP or HTTPS and have it come up fine. There may be errors on HTTPS though, and we’ll get to that.

2. Start with the Admin

In WordPress-land, you might as well get HTTPS going in the admin area first. It’s set up to handle it and there probably won’t be any errors. (I keep saying “errors”, I mostly mean “mixed content warnings” which I promise we’ll get to.)

To force HTTPS in the admin area, put this line in your wp-config.php file at the root of your WordPress install:

define('FORCE_SSL_ADMIN', true);

Make sure you test that HTTPS is working properly first! Go to https://yoursite.com/wp-admin/ to check. Otherwise you’ll be forcing URLs that don’t work and that’s bad. If you have trouble, remove that line right away.

All goes well, you’ll get a secure connection:

3. Try to get one page working on the front end

The next step is to get your front end on HTTPS. Forcing it all right away is probably going to be tough, so just start with one target page. For me, it was the signup page for The Lodge. That page can take credit cards, so really, it had to be HTTPS. This was the motivator for me early on to get this set up.

There is a plugin that can help with this: WordPress HTTPS (SSL). With that plugin, you get a checkbox on Posts/Pages to force it to be SSL.

4. Mop up Mixed Content Warnings

What you’re really trying to avoid is this:

Mixed Content Warning

That’s like: “Hey nice trying being HTTPS but you aren’t fully so NO GREEN LOCK FOR YOU!”

If you open the console, you’ll likely get messaging like this:

In this case, it was some images being used in a CodePen embed with an HTTP src.

But it could be anything. HTTP <script>s, HTTP CSS <link>s, HTTP <iframe>s. Anything that ends up making an HTTP request that isn’t HTTPS will trigger the error.

You just need to fix them. All.

5. Protocol Relative URLs! (or just relative URLs)

You know, those ones that start with //, like this:

<img src="//example.com/image.jpg" alt="image">

Those are your friend. They will load that resource with whatever protocol the current page is. And links that are just relative to begin with will be fine, like:

<img src="/images/image.jpg" alt="image">

I ended up finding them all over the place. I even had Custom Fields to fix:

6. Harder problem: images within legacy content

There are thousands and thousands of pages on this site, and lots and lots of images within those pages. Right in the content itself. There are a bunch on this very page you’re looking at. The problem is those images had fully qualified HTTP links on them.

I didn’t relish the idea of using some WordPress filter on content to kinda hotswap those URL’s out – I just wanted to fix the issue. I hired Jason Witt to help me with this. The first thing we did was run some SQL on the database to fix the URL’s. Essentially fixing the src of images to be protocol relative.

After backing up the database, and testing it locally, this worked great:

UPDATE wp_posts 
SET    post_content = ( Replace (post_content, 'src="http://', 'src="//') )
WHERE  Instr(post_content, 'jpeg') > 0 
        OR Instr(post_content, 'jpg') > 0 
        OR Instr(post_content, 'gif') > 0 
        OR Instr(post_content, 'png') > 0;

And another to catch single-quoted ones, just in case:

UPDATE wp_posts 
SET   post_content = ( Replace (post_content, "src='http://", "src='//") )
WHERE  Instr(post_content, 'jpeg') > 0 
        OR Instr(post_content, 'jpg') > 0 
        OR Instr(post_content, 'gif') > 0 
        OR Instr(post_content, 'png') > 0;

We even fixed the Custom Fields in much the same way:

UPDATE wp_postmeta 
SET meta_value=(REPLACE (meta_value, 'iframe src="http://','iframe src="//'));

7. Make sure new images are protocol relative

With the legacy content mopped up, we need to make sure new content stays OK. That means fixing the media uploader/inserter thingy so it inserts images with protocol relative URLs. Fortunately I already customize that to insert with <figure> tags, so it was just an adjustment of that. Jason ultimately helped me move a lot of my custom functions.php code into a plugin, so this is a little out of context, but I think you’ll get the picture and see the relevant filters and stuff:

class CTF_Insert_Figure {

  /**
   * Initialize the class
   */
  public function __construct() {
    add_filter( 'image_send_to_editor', array( $this, 'insert_figure' ), 10, 9 );
  }
  
  /**
     * Insert the figure tag to attched images in posts
     *
     * @since  1.0.0
     * @access public
     * @return string return custom output for inserted images in posts
     */
  public function insert_figure($html, $id, $caption, $title, $align, $url) {
    // remove protocol
    $url = str_replace(array('http://','https://'), '//', $url);
    $html5 = "<figure id='post-$id' class='align-$align media-$id'>";
    $html5 .= "<img src='$url' alt='$title' />";
    if ($caption) {
        $html5 .= "<figcaption>$caption</figcaption>";
    }
    $html5 .= "</figure>";
    return $html5;
  }
}

8. Your CDN needs SSL too

If you have a CDN set up (I use MaxCDN through W3 Total Cache) that means the CDN is totally different server and URL and all that and it needs to be able to serve over HTTPS as well. Fortunately MaxCDN handles it.

9. Start forcing HTTPS everywhere

This is what I do in the .htaccess file at the root:

# Force HTTPS
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Once that is in place, you can turn off the plugin and remove the bit from the wp-config.php file, as those are redundant now.

You’ll also want to change the URL settings in General Settings to be https:// – so all the links in WordPress are constructed properly and redirects don’t need to come into play:

10. Keep mopping up

Inevitably after going HTTPS everywhere, you’ll find pages with mixed content warnings. You just need to keep investigating and fixing.

Good luck! (and let me know if I’ve fouled anything up)


Update! Speaking of mopping up… Content Security Policy (CSP) is a technology that might be incredibly helpful for you here. There is a directive for it, upgrade-insecure-requests, that can force the browser to use HTTPS for any HTTP resources it finds. A bit of a sledgehammer, but could be super useful.


Moving to HTTPS on WordPress originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

]]>
https://css-tricks.com/moving-to-https-on-wordpress/feed/ 36 197099