Tag Archive for: HTTPS

HTTP/2
Rob Hooper

Switching a site from HTTP to HTTPS

/0 Comments/in /by

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.

HTTP/2
Gary Rixon

HTTP/2

/1 Comment/in /by

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!

Rob Hooper

Let’s Encrypt: Security Everywhere

/1 Comment/in /by

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.

Rob Hooper

Certificate Authorities or how to trust over the internet

/3 Comments/in /by

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)

CA_Hierarchy

  1. *.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.
  2. 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.
  3. 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.

HSTS Header
Alex Last

HTTPS Everywhere

/2 Comments/in /by

“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!

Rob Hooper

DROWN vulnerability

/0 Comments/in /by

Dogsbody Technology maintenance customers are already protected against the newly disclosed DROWN attack, but as of the 1st March, 33% of all HTTPS sites are affected by this vulnerability.

The DROWN (Decrypting RSA with Obsolete and Weakened eNcryption) vulnerability affects HTTPS and other services that rely on SSL and TLS, these cryptographic protocols that make security over the Internet possible.

The attack affects all SSLv2 servers and allows attackers to decrypt HTTPS traffic during transfer letting them spy on traffic. In some cases encryption can be broken within minutes!

The fix web servers is to disable SSLv2 support:

  • For Apache: SSLProtocol all -SSLv2 -SSLv3
  • For Nginx: ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

For more information on the attack and research paper take a look at the official DROWN Attack website.

Dogsbody Technology are Linux SysAdmin’s, building secure scalable reliable servers for the internet. We keep our servers up-to date and in doing so have already mitigated this attack.

If you want your site checked or have any questions please contact us.

Dan Benton

CVE-2014-3566 – POODLE

/0 Comments/in /by

What is POODLE

The POODLE (Padding Oracle On Downgraded Legacy Encryption) vulnerability allows an attacker to obtain data transferred with the SSL 3.0 protocol.  An attacker acting as a man in the middle can downgrade a TLS connection to SSL 3.0 and then use a padding-oracle attack to access sensitive information such as cookies.  Since stealing a user’s cookies will allow an attacker to login as that user, they are the most likely target of a POODLE attack.

Prevention

This vulnerability can be fixed either on the server or in the client.

Site owners can protect their users against POODLE attacks by disabling TLS fallback or SSL 3.0 (Note that disabling SSL 3.0 will break the site for IE6 users):

  • For Apache: SSLProtocol all -SSLv2 -SSLv3
  • For Nginx: ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Browsers are rolling out fixes but for users the quickest fix is to disable SSL 3.0:

  • In Firefox this is done by going to about:config and setting security.tls.version.min to 1
  • Chrome users have to use the command line flag --ssl-version-min=tls1

Going deeper

This attack is possible because SSL pads requests to fill the last block before encryption.  SSL 3.0 only requires the last byte to be checked by the server; it must have a value equal to the number of bytes that have been used for padding.  The values of the other padding bytes are not validated, this allows an attacker to move the block they want to decrypt to the the last block and try all 256 possible values until the server accepts the request, allowing them to decode one byte of the cookie.  An attacker in a privileged network position (or sharing public WiFi) just needs to downgrade the SSL connection from TLS to SSL 3.0 and then use JavaScript to quickly obtain a cookie one byte at a time.

For more technical information I would recommend this article by ImperialViolet.

Feature image made by Koji Ishii licensed CC BY 2.0