SSL Archives - Dogsbody Technology

Google Chrome to Distrust Symantec SSL Certificates

23 Jan 2018/0 Comments/in Security/by Jim Carter

From 15 Mar 2018 Google Chrome will start distrusting Symantec SSL Certificates.

What is happening and why?

Over the past few years various concerns have been raised regarding Symantec’s process for issuing and revoking SSL certificates. As a result Google Chrome have announced that they will be distrusting SSL certificates issued by Symantec. It is important to note that since Symantec’s root certs are used by other certificate authorities the following will also be affected: Equifax, GeoTrust, RapidSSL, Thawte, and VeriSign.

In order to restore trust in future Symantec issued SSL certificates DigiCert have acquired Symantec SSL. Certificates issued after 1 Dec 2017 will be signed by DigiCert’s managed partner scheme and as such will remain trusted by Google Chrome.

Google are currently planning to distrust Symantec SSL Certificates in two main phases – the release of Chrome 66 and the release of Chrome 70.

How could this affect me?

If your site is using an invalid SSL certificate your users will receive a security warning. Since Google Chrome currently makes up over half of the browser market (you can check your analytics as exact percentages vary depending on your industry) it is likely a large proportion of your users will receive errors when visiting your site. Mozilla have announced they will be following suit.

How to check if your site is using an affected cert?

The easiest way to check this is to use Google Chrome developer tools:

Press F12 to open the developer tools
In the “Console” tab you will see the a warning if your certificate will be distrusted by a future Chrome release.

What should I do if I am using an affected cert?

Affected Certificates purchased before 1 Jun 2016 will need to be re-issued before Chrome 66 beta which is planned to be 15 Mar 2018 or Chrome 66 stable which release is planned for 17 Apr 2018
Affected Certificates purchased before 1 Dec 2017 will be need to be re-issued before Chrome 70 beta which will be roughly 13 Sep 2018 or Chrome 70 stable release which will be roughly 23 Oct 2018.

Your certificate may be going to expire before it is distrusted in Chrome in which case you don’t have anything to worry about since any certificates issued now will remain trusted.

If your certificate will be distrusted by Chrome before you would normally renew it then you will need to have it re-issued luckily this won’t cost you anything except the time it takes you.

In order to check when your SSL certificate was purchased and when it is valid until you can use the Google Chrome developer tools:

Press F12 to open the developer tools
Navigate to the “Security” tab
Click “View certificate” from here you should be able to see the “Issued On” and “Expires On” dates

If you are one of our customers then you don’t need to worry as we will be contacting you if any of your servers are affected.

If anyone else would like us to check if they are affected or help with the re-issuance process contact us.

Feature image – “Security Broken” by DennisM2 is licensed under CC0 1.0 Universal (CC0 1.0)

Switching a site from HTTP to HTTPS

11 Apr 2017/0 Comments/in Knowledge Base/by Rob Hooper

We love HTTPS and with its Security, Speed, SEO and Accessibility you should upgrade now!

Having helped customers through this process many times we have learnt a thing or two about how to make the process go smoothly. So here is our …

4 step HTTPS upgrade guide

1) Get a certificate

You can get an SSL certificate from 100’s of different resellers, we have a hefty spreadsheet to keeps track of the best.

There are many types of SSL certificate from various Certificate Authorities. For basic domain validated certificates we are a big fan of Lets Encrypt.

If you don’t know what certificate you need you can read our other articles (link above) or contact us and we’ll be glad to help.

2) Set up your web server to listen to HTTPS

This is an important step I wanted to split out, this doesn’t mean stop using HTTP. Just because you are ready for HTTPS doesn’t mean your site is and jumping over immediately can often cause unforeseen issues.

All good web-servers can listen to multiple ports at once so you can continue running your site over HTTP while you are working on HTTPS. If this process takes more than a day then you will probbaly want to firewall your new site off from the rest of the internet until it’s up and working as you wish.

At this step you can set up all sorts of new cool technologies. If you ever thought HTTPS was slower than HTTP wait until you try HTTP/2.0.

3) Configure the site to use HTTPS

This is when you fix those unforeseen issues I mentioned earlier, people often forget that HTTPS is very strict when it comes to downgrading the connection and will block anything loaded over HTTP. This often ends up with the page missing CSS or Javascript.

Another catch that is often missed is getting your site to generate links as HTTPS. If the site continues to generate HTTP links each visitors click and item load happens twice once to redirect to HTTPS and again to load it over HTTPS, it doubles the traffic and load time of your site.

One common concern with HTTPS is that you lose all referral information when a user clicks from an HTTPS to a HTTP site. There are ways around this, we include the <meta name=”referrer” content=”always”> tag in all of the HTML on our site so we don’t lose this, but you can only do this on sites that you control.

4) Configure your web server to redirect to HTTPS

The last step, set up a permanent redirect to upgrade all of your traffic to browse your site via HTTPS. Permanent redirects differ from other redirects as the redirection is cached as well as having some SEO benefits.

If you are interested in more information or would like help with your migration then please feel free to drop us a message and see how we can help you upgrade.

Your website on the Tor network

4 Apr 2017/5 Comments/in Company/by Dan Benton

We are very proud to announce a unique service which enables any website to have a presence on the Tor network.

Hosting a website on the Tor network has previously been very challenging, requiring changes to both infrastructure and the site itself.

Dogsbody Technology Ltd. are now offering a turn-key solution to this problem, allowing almost any website to be placed on the Tor network without requiring expensive redevelopment.

We are launching this service based upon the work done by Alec Muffett on the The Enterprise Onion Toolkit. Alec is a stout maintainer of digital rights in the UK and is a member of the board of directors of the Open Rights Group. He led the team that implemented Facebook’s onion site and we are delighted to have Alec as a consultant on this project.

Tor enables people from anywhere on the planet to access sites and data that might otherwise be blocked. They may use Tor to browse sites and content without divulging their physical or online location, and Tor’s Onion Networking provides people with greater confidence regarding the authenticity of the site they are accessing

Tor users may already access your website anonymously and securely thanks to the Tor Network, however this does not protect their traffic from bad actors on the public internet or at rogue “exit nodes”. Providing a Tor “Onion Address” helps obviate these risks by giving people a trusted path to your site, a path that is owned by you. Onion addresses are “self-authenticating addresses“: the address itself is a cryptographic proof of the identity of the service. For example the Tor project website can also be found at http://expyuzz4wqqyqhjn.onion/ [NB: this link will only work in Tor-enabled browsers].

Adding an Onion address to your site gives a number of advantages:

Extra privacy for people that visit your site
Extra confidence that the site they have connected to is yours
Freedom from oversight and network surveillance
Access to your site cannot be blocked by an ISP, company or state
Enhanced communications integrity & tamper-proofing
Guaranteed use of a more security-aware browser, Tor Browser

Additionally: setting up an Onion address can provide less contention, more speed & more bandwidth to people accessing your site than they would get via Tor “exit nodes”.

Contact us now using the form below and we’ll help setup your site as an onion site on the Tor network.

HTTP/2

24 Jan 2017/1 Comment/in Technology/by Gary Rixon

HTTP/2 is a fairly new technology, offering significant improvements over its predecessors, whilst remaining backwards compatible with previous web browsers and services. HTTP/2 is only going to get bigger, and it’s certainly not going away any time soon, so here’s some stuff you should know about it.

Before we get too in depth with the advantages of HTTP/2 and the reasons you should be using it, it’s important we understand what HTTP is in the first place, and how it fits into modern internet use.

HTTP stands for Hyper Text Transfer Protocol, and it is one of the main parts of the modern web as we know it. It is a set of rules for how information should be sent and received between systems. Any text, images and media you see and interact with on a standard web page (including this one) would most likely have been sent to you using HTTP.

The downsides of regular ol’ HTTP

HTTP has been around for a long time. This of course is not inherently bad, but HTTP was designed a long time ago, and things have changed a lot since then. HTTP/1.1, which is the version that a very large majority of the modern web uses, was first standardised in 1997, and saw major development before that date too.

That’s 20 years ago now, and in that time the internet has gone from something connecting only large enterprises and government facilities, into a truly global communications utility used daily by billions of people.

The original HTTP/1.1 spec was never designed with this sense of scale and use in mind, and so it has shortcomings in the modern day, resulting in the need for often time-consuming and complex workarounds.

One of the biggest drawbacks of HTTP/1.1 is the need for new connections on every request. This adds overheads, which are amplified due to the large number of assets used on most modern websites, and amplified even further by the additional overhead of negotiating HTTPS connections when loading assets securely.

What is HTTP/2 and what are the advantages?

HTTP/2 is the newest version of HTTP, and was standardised in mid-2015, taking influence from the earlier SPDY protocol, initially designed by Google. HTTP/2 offers significant improvements over previous versions in the following ways

Server push – the web server running your website can push assets to visitors before they request them, speeding up the overall load times of pages
Concurrency – all communication can happen via one connection, removing the overhead and complexity of establishing and maintaining multiple connections, which again results in speed improvements
Dependency specifications – you can now specify which of the items on your page are most important, and make sure the most important ones are dealt with first. This means the content somebody wants to see can be displayed sooner
Header compression – decreases the amount of data to be transferred by compressing the metadata in messages being sent and received, lowering bandwidth usage and once again decreasing load times

All of these advantages, combined with sites and applications making the most of them, can result in significant improvements in page load speeds, particularly on mobile devices, and a much nicer overall experience on the web.

An interesting point on HTTP/2 is that although there is nothing in the RFC that specifies HTTP/2 should only support encrypted connections (using TLS or SSL), some major browsers such as Firefox and Chrome have stated they will not support HTTP/2 over plain-HTTP connections. This means that in a lot of cases, you’ll have to support HTTPS in order to reap the benefits that HTTP/2 provides, but you should really be using HTTPS by now anyway, so this is not too big a deal.

Sound good? We can help!

If HTTP/2 sounds like something you’re interested in, then just get in touch and we’re more than happy to help. We’ve been running HTTP/2 on our website for quite a while now, and we’d love to help you get it running on yours!

Types of SSL Certificates

18 Oct 2016/1 Comment/in Technology/by Rob Hooper

The number of businesses that use SSL have increased tremendously over the past few years and the reasons for which SSL is used has also increased, for example:

Some businesses need SSL to simply provide confidentiality (i.e. encryption)
Some businesses like to use SSL to add more trust or confidence in security and identity (they want you to know that they are a legitimate company and can prove it)

As the reasons companies use for SSL have become wider, three different types of SSL Certificates have been established:

Extended Validation (EV) SSL Certificates
Organization Validation (OV) SSL Certificates
Domain Validation (DV) SSL Certificates

Extended Validation (EV) SSL Certificates are issued only when a Certificate Authority (CA) checks to make sure that the applicant actually has the right to the specific domain name plus the CA conducts a very THOROUGH vetting (investigation) of the organization. The issuance process of EV Certificates is standardized and is strictly outlined in the EV Guidelines, which was created at the CA/Browser Forum in 2007, specifies the required steps that a CA must do before issuing an EV certificate:

Must verify the legal, physical & operational existence of the entity
Must verify that the identity of the entity matches official records
Must verify that the entity has the exclusive right to use the domain specified in the EV Certificate
Must verify that the entity has properly authorized the issuance of the EV Certificate

EV Certificates are used for all types of businesses, including government entities and both incorporated & unincorporated businesses.

A second set of guidelines are for the actual CA and it establishes the criteria to which a CA needs to be audited before being allowed to issue an EV Certificate. It is called, the EV Audit Guidelines, and they are always done every year to ensure the integrity of the issuance process.

Takes 7-14 days to provision
Expect costs to be at least £150+
Gives a green bar in the browser

We recommend EV certificates if you are asking for sensitive details such as credit card information on your website.

Organization Validation (OV) SSL Certificates are issued only when a Certificate Authority (CA) checks to make sure that the applicant actually has the right to the specific domain name plus the CA does some vetting (investigation) of the said organization. This additional vetted company info is displayed to customers when the Secure Site Seal is clicked on, this gives enhanced visibility to who is behind the site which in turn gives enhanced trust in the site.

Takes 1-3 days to provision
Expect costs in the range of £40 to £100

Perfect certificate for any businesses website.

Domain Validation (DV) SSL Certificates are issued when the CA checks to make sure that the applicant actually has the right to the specific domain name. No company identity information is vetted and no information is displayed other than encryption information within the Secure Site Seal. DV certs can be issued immediately.

Instant provisioning
Usually around £10. However notably Lets Encrypt provides free certificates

This is perfect for securing every day websites like blogs.

Let’s Encrypt: Security Everywhere

21 Jun 2016/1 Comment/in Technology/by Rob Hooper

Let’s Encrypt is a new Certificate Authority (CA) who are making waves in the web community. They have lowered the access barrier for SSL certificates significantly and are pushing their competition to improve; fast.

“A Certificate Authority is an entity that validates other digital certificates… …Creating a Chain of Trust between a website and the browser.”

Read more about Certificate Authorities or how to trust over the Internet.

Why Lets Encrypt is revolutionary:

Let’s Encrypt removes the pay wall for SSL certificate’s making them free for everyone.
Its quick. Seemingly instant certificate authentication and provisioning.
Open client options for many different programming languages and environments.
Certbot (the official client, developed by the Electronic Frontier Foundation (EFF)) is incredibly simple to set up and run HTTPS in seconds. See for yourself.
Automated SSL regeneration. A new certificate just when the old one expires.
Raising the standards for CA security checks. Let’s Encrypt have implemented new security checks which ensure that you are the domains owner and that it’s secure to issue you the certificate. Read more.
Short validation periods. Let’s Encrypt certificates are only valid for three months which in comparison to other CA signed certificates is shorter. You may be thinking this is bad, long validation periods means less work to maintain. But should the next Heartbleed vulnerability come along and your certificate is leaked to the public, the perpetrator only has less than three months to use it then it will no longer be valid.
Supported, as of last year Let’s Encrypt are trusted in most browsers. Test it for yourself. Read more.

It’s free, easy and simple to do so there is no reason not to get started straight away.

Quick (nearly instant) certificate provisioning is our favourite benefit. We often have new customers come to us that have been caught out by expiring SSL certificates not leaving enough time for the renewal to take place, which with Extended Validation certificates can be weeks! Let’s Encrypt is our first port of call to mitigate the missing certificate. Giving us a temporary solution while their other certificate is renewed.

At Dogsbody Technology we love SSL and have already started implementing Let’s Encrypt when we can. If you want to see the benefit of SSL drop us a line.

Feature image made by Got Credit licensed CC BY 2.0.

Certificate Authorities or how to trust over the internet

19 May 2016/3 Comments/in Technology/by Rob Hooper

A common misconception we see all the time is that HTTPS is only useful for scrambling (encrypting) connections between you and a website, but this is only half of its potential.

So how do we know we are connected to Facebook’s servers when we access www.facebook.com?

HTTPS ensures this, by making two important aspects of security possible: encryption and authentication. It does this by sending additional data (SSL certificates) before each connection. This certificate tells the client how to encrypt their connection and which Certificate Authority will authenticate who they are.

A Certificate Authority is an entity that validates other digital certificates. They do this by “signing” certificates (with each others keys) and creating a Chain of Trust between a website and the browser.

This is the chain of trust for https://www.dogsbody.com (feel free to check this yourself in your browser now)

*.dogsbodytechnology.com
The first certificate your browser receives is the site certificate. This certificate details all of the domains that it is applicable for, in this case any domain ending dogsbodytechnology.com. As well as an “Issued By” field which details the certificate that signed it, giving your browser the information to verify it.
When setting up a secure website (HTTPS) one of the first steps is to get a certificate authority to sign your certificate. Their signature connects you to a root certificate which browsers and software knows it can trust.
Comodo signed our certificate so our “Issued By” field points to them.
COMODO RSA Domain Validation Secure Server CA
This is one of Comodo’s many intermediate certificates. There can be multiple intermediate certificates in the certificate hierarchy however each extra hop reduces trust.
This certificate is not known by the browser so the webserver should send this certificate (and all intermediate certs) with the site certificate. This is sometimes known as the certificate bundle.
This certificate’s “Issued By” field links to the root certificate giving us the next link in the chain to verify this certificate.
COMODO RSA Certification Authority
This is a root certificate, it is stored locally on your operating system (OS) with other root certificates your OS trusts. These are the master certificates of certificate authorities who have been thoroughly authenticated so your browser can trust them definitively.
Some products such as FireFox for example, provide their own selection of root certificates which is used over the operating systems.
While each certificate stores the field “Issued By” to verify it, root certificates are Issued By themselves, so no further checking is possible or necessary, they are trusted absolutely. This is a Trust Anchor, the end of the verification process.

Now that the browser can link your certificate with a root certificate it knows it is talking to authorized servers for the site and the rest of the connection can continue.

We secure websites every week contact us today and see how we can help you.

HTTPS Everywhere

12 Apr 2016/2 Comments/in Technology/by Alex Last

“HTTPS Everywhere” is an increasingly popular trend among websites which gives added security, speed and SEO benefits. In August 2014, Google announced that it would be adjusting it’s search engine ranking algorithm to benefit HTTPS only sites, this was one of the key announcements that started the trend of sites going HTTPS everywhere. There’s also been numerous leaks and blog posts talking about the NSA & GCHQ intercepting communications to and from insecure HTTP sites.

In the past, one of reasons websites weren’t HTTPS everywhere was due to the added latency from the overhead of the HTTPS connection. With a slow internet connection and slower servers by todays standard this caused the sites to become sluggish which obviously isn’t great from a user experience point of view. Now that bandwidth and server performance has improved, the overhead is negligible, there have also been improvements such as SPDY and HTTP/2 which can drastically improve a websites performance over HTTPS, we will be covering how these work in future blog posts.

There are a few steps you can do to get your website running HTTPS everywhere:

Redirecting all HTTP requests to HTTPS; this can be done in your apache or nginx configuration and will tell web browsers that any request they make for content over HTTP should be redirected to the HTTPS equivalent URL. Ideally you would use a 301 (permanent) redirect for this, redirecting HTTP requests to HTTPS is something we do for the Dogsbody Technology site.
Add the HSTS (HTTP Strict Transport Security) header to your website; again this is done in your apache or nginx configuration. This header tells browsers that it should only access the website over HTTPS, the browser will make sure not to request HTTP pages until the “max-age” time is reached (how long the browser should cache the HSTS setting for). There is also an option “includeSubdomains” which tells the browser any subdomain on for the site should also be served over HTTPS, you should be careful when setting this if you have any subdomains that won’t work over HTTPS. We don’t include subdomains in our HSTS settings as we have a few subdomains out of our control that can’t be served over HTTPS.
The last thing you should do, only if you have the “includeSubdomains” setting mentioned above is add your website to the HSTS preload list. The HSTS preload list is a list of domains included by browsers that will serve over HTTPS by default without having to perform an initial HTTP request to the website. For this to work you will also need an additional “preload” option specified in your web servers HSTS configuration. You can submit your site to the HSTS preload list here.

Another good option is the HTTPS Everywhere browser plugin from the EFF, it works to achieve the same result as using HSTS preload and act as a list of rules browsers should follow for websites. It allows a finer grain control than HSTS and is perfect for domains like ours where we can’t include every subdomain, you can write your own ruleset for the plugin and do a git pull request to get your website in the next release they do. You can see our pull request where we added the rules for dogsbodytechnology.com & dogsbodyhosting.net and some specific subdomains.

Once you’ve done all of the above steps you can be pretty happy that your site is HTTPS everywhere, and the majority of all traffic to your website will be served over HTTPS (some older browsers don’t support the HSTS header).

If you think going HTTPS everywhere is the next step for you be sure to get in contact with us and we can help you achieve that!

Tag Archive for: SSL