Category: Tech Insight


As part of our ongoing commitment to the services we provide to our “cloud-hosted” customers, we’ll shortly be upgrading all our client servers to support HTTP/2.

HTTP/2 is the first major new version of the HyperText Transfer Protocol (HTTP) for two decades, and will eventually replace the previous HTTP/1.1 protocol which was standardized way back in 1997.

The primary goal of HTTP/2 is to overcome many of the shortcomings of the twenty year old HTTP/1.1 protocol, particularly in relation to how content is delivered over the internet.

HTTP/2 focuses on optimizing the communication and flow of content between web servers and web browsers. When a user connects to a web site, their browser negotiates an HTTP session with the server. The type of session created will vary depending on the features supported by the browser and the server. If both ends support the latest HTTP/2 protocol, the server uses the HTTP/2 protocol to shape and optimize traffic before it passes through the network back to the browser.

Once the browser and server agree to use HTTP/2, they can utilize additional features such as compression and multiplexing to optimize the connection. If either the web server or the user’s web browser doesn’t support HTTP/2, the connection will fall back to the HTTP/1.1 protocol.

Benefits of HTTP/2

One of the main improvements over HTTP/1.1 is that HTTP/2 uses simultaneous connections (or multiplexing). Previously only one resource can be fetched from the server at a time, however with HTTP/2 multiple resources can be fetched over a single connection concurrently.

Another benefit is header optimization. Every request over HTTP contains header information. With HTTP/1.1, many of these headers are repeated over a single session. HTTP/2 removes redundant headers while compressing the remaining headers, leading to performance improvements.

Benefits to cloud-hosted MIDAS users

In terms of MIDAS, the benefit of our client servers supporting HTTP/2 is that users will see notable improvements in page load speed and responsiveness when using MIDAS.

In our pre-testing, we saw page load times via HTTP/2 improve by some 20% over the same pages loaded via HTTP/1.1

When will the upgrade happen?

We’ll be upgrading our client servers to support HTTP/2 over the coming weekend (15/16th July 2017), and other than a quick server restart, no additional downtime is expected. For more information, be sure to check our our dedicated Service Status site (which already supports HTTP/2!), and follow us on Twitter for updates.

Will I need to do anything?

No action is required on your part!

If you’re running a modern operating system and web browser, you won’t need to do anything – your browser will already support HTTP/2, you’ll still access MIDAS in exactly the same way, and once our servers are HTTP/2 enabled over the weekend, your browser will adjust accordingly.

If you’re not running a HTTP/2 compliant browser/operating system don’t worry, you’ll still be able to connect to your hosted MIDAS system over HTTP/1.1 as before, but you may like to consider upgrading your operating system & browser to one that supports HTTP/2 for a better MIDAS experience!

  • Edge Chrome Firefox Current versions of Edge, Chrome, and Firefox browsers fully support HTTP/2.
  • Safari Current versions of Safari support HTTP/2 on OSX 10.11+
  • Internet Explorer Internet Explorer 11+ supports HTTP/2 on Windows 10 only

UPDATE: Our network is now fully HTTP/2 enabled, and we’re seeing some great performance improvements too!

Disabling TLS 1.0 in early 2017

TLS stands for “Transport Layer Security” and is a cryptographic mechanism used to facilitate secure connections and communications over the internet. Several incarnations of the TLS protocol have been developed over the years (1.0, 1.1, and 1.2), with 1.0 being the oldest and now approaching the ripe old age of 18!

TLS 1.0 is now considered a “legacy protocol” and “weak” by today’s cryptographic standards, as it is susceptible to several vulnerabilities. Modern web browsers automatically default to preferring TLS 1.2 or TLS 1.1 over legacy TLS 1.0 connections, however some older browsers do not support the more modern and secure TLS 1.1/1.2 protocols.

As part of our ongoing commitment to security, in early 2017 we intend to drop support for legacy TLS 1.0 connections to our client servers. The vast majority of users will be unaffected by this change, but if you’re using an older web browser/operating system, you may need to update.

The minimum browser requirements for MIDAS v4.14 (and later) have also been updated accordingly.

The following table of web browsers provides additional guidance as to any action you may need to take to ensure you can continue to access our site/your hosted MIDAS system in 2017:

Browser Version Comments
Microsoft Internet Explorer 11 OK (If you see the “Stronger security is required” error message, you may need to turn off the “Use TLS 1.0” setting via Internet Options → Advanced)
9-10 OK (When running Windows 7 or newer, however you’ll need to enable TLS 1.1 and TLS 1.2 in Internet Explorer by selecting the “Use TLS 1.1” and “Use TLS 1.2” boxes via Internet Options → Advanced)
Upgrade Required (Windows Vista, XP and earlier are incompatible and cannot be configured to support TLS 1.1 or TLS 1.2 – Please update your operating system)
8 (or lower) Please update to a more recent version of Internet Explorer
Microsoft Edge All Versions OK – No action required
Mozilla Firefox 27+ OK – No action required
23-26 OK (Use about:config to enable TLS 1.1 or TLS 1.2 by updating the security.tls.version.max config value to 2 for TLS 1.1 or 3 for TLS 1.2)
22 (or lower) Please update to a more recent version of Firefox
Google Chrome (Desktop) 38+ OK – No action required
22-37 OK – No action required (Provided you’re running Windows XP SP3, Vista, or newer, OS X 10.6 (Snow Leopard) or newer)
21 (or lower) Please update to a more recent version of Chrome
Google Chrome (Mobile) Android 5.0+ (Lollipop) OK – No action required
Android 4.4.x (KitKat) Device Dependent (Some Android 4.4.x devices may not support TLS 1.1 or higher. Please refer to your device manufacturer if unsure)
Android 4.3 (Jelly Bean) (or lower) Please update to a more recent version of Android
Apple Safari (Desktop) 7+ OK – No action required
6 (or lower) Please update to a more recent version of Safari
Apple Safari (iOS) iOS 5+ OK – No action required
iOS 4 (or lower) Please update to a more recent version of iOS

Important Information For Hosted API users:

If you’re a cloud-hosted MIDAS customer utilizing the optional MIDAS API, please ensure that your applications and the underlying programming language you develop in can support (and are correctly configured for) TLS 1.1/1.2 connections. For instance Java 6 (1.6) (and lower) and .NET 3.5 (and lower) languages don’t support TLS 1.1/1.2.
If your applications/programming languages do not support at least TLS 1.1, your MIDAS API calls will begin to fail in early 2017 once we disable TLS 1.0.
Please refer to the vendor of your programming language if you’re unsure whether it supports TLS 1.1/1.2, or for assistance enabling such support in your development environment.

UPDATE: 1st April 2017

In advance of dropping TLS 1.0 support across our entire network this year, we’ve initially dropped TLS 1.0 support on our dedicated Service Status site. If you’re not sure whether or not you’ll still be able to access your hosted MIDAS system once TLS 1.0 support is dropped in the near future, please visit https://midas.network. If you’re able to visit this site without issue, then you’ll still be able to access MIDAS going forward.

UPDATE: 1st July 2017

As of today, our servers no longer accept TLS 1.0 connections. If you’re unable to access our site/a hosted MIDAS system, please upgrade your web browser.

We are delighted to announce the completion of our roll out of dedicated sub domains for all our cloud hosted customers!

Following a desire expressed by a few of our existing customers to be able to have their cloud-hosted MIDAS systems accessible via dedicated sub-domains of mid.as, at the start of this year we began providing this to all new customers who chose a cloud hosted edition of MIDAS.

For instance, if you purchased a cloud-hosted edition of MIDAS in 2016 and your company was called “My Organization”, you would have been able to chose the dedicated MIDAS domain https://my-organization.mid.as for your hosted scheduling system.

However, if your company was called “My Organization” and you purchased a cloud-hosted edition of MIDAS prior to 2016 – before dedicated mid.as sub-domains were available – you’d instead have been accessing your MIDAS system via https://mid.as/my-organization

The good news is that from today, we’ve now rolled out dedicated mid.as sub-domains to all our hosted customers who purchased prior to 2016 as well!

So, if you previously accessed your hosted MIDAS system via https://mid.as/my-organization, you’ll now have the dedicated sub-domain https://my-organization.mid.as (Old mid.as/my-organization URL’s will continue to work and redirect to my-organization.mid.as for some time)

If you purchased a cloud-hosted MIDAS system prior to 2016, we’d like to encourage you to update your bookmarks & links to point to your new dedicated mid.as sub-domain going forward!

There are a few things to note when updating your bookmarks/links:

  1. If your hosted MIDAS URL previously contained any underscores (_), you’ll need to change these to hypens () when updating your bookmarks/links, for example:
    https://mid.as/my_organization would now become https://my-organization.mid.as

  2. If your hosted MIDAS URL previously contained a domain name (other than mid.as) (i.e. .co.uk, .com, etc), you’ll need to remove this part when updating your bookmarks/links, for example:
    https://mid.as/myorganization.com would now become https://myorganization.mid.as

  3. If your hosted MIDAS URL previously contained any period characters (.) (other than the initial period in the primary “mid.as” domain), you’ll need to remove these when updating your bookmarks/links, for example:
    https://mid.as/my.organization would now become https://myorganization.mid.as

If you have any questions, or aren’t sure what the new dedicated sub-domain for your particular hosted MIDAS system is, please don’t hesitate to contact us and we’ll be happy to help!

As part of our ongoing commitment to security, you may notice that “Security Enhancements” often appears in the changelog when we release new builds.

In this blog post we’ll shed some light on some of these “security enhancements” that were recently introduced in MIDAS v4.11 and v4.12.

IP Change Detection

Starting with MIDAS v4.12, If a logged in user’s IP address changes whilst they are logged in, then the system will automatically log the user account out, forcing the user to login again.

It’s rare that a user’s IP address would legitimately change mid-session, and so this additional security enhancement will not be noticed by the majority of our users.

What it does do however is strengthen user sessions against a “session hijack“. In general terms, a “session hijack” is when a malicious attacker takes over a user account by gaining access to the unique identifying token (or cookie) of an active user session.

With the new IP Change Detection implemented in MIDAS v4.12, should a user fall victim to a session hijack, the session would be immediately invalidated as the originating IP address would suddenly change from the valid user’s IP address, to the IP address of the attacker.

→ Tip: User’s IP addresses are also logged in each MIDAS system’s Recent Activity Log

Shorter Cookie Persistence

We’ve all come across website with “Remember Me” or “Keep Me Logged In” tick boxes on login screens, meaning that you don’t have to remember your username & password for the site each time you come to login. When you select this box, information is stored in a browser “cookie” and retrieved the next time you visit.

MIDAS has included a “Remember Me” tickbox on the login screen since v4.07 (September 2014). Previously, the cookie saved by your browser would persist until 1st January 2020 – some 4 years in the future!

This meant that if you were to login to MIDAS today, you could come back to the same browser in a few years time, and still login without needing to remember your credentials.

We felt this was a little too long for your browser to be retaining such data, and as such from MIDAS v4.12 the “Remember Me” option will only remember your details for a period of 90. If you do not login to MIDAS again within that period, you’ll have to manually enter your email address/password again.

Why is this better? Well, it ensures that “dormant” user accounts (i.e. accounts not logged into for over 90 days) don’t have lingering login details persisting in client-side cookies.

→ Tip: MIDAS Administrators can choose to disable the “Remember Me” option completely (via MIDAS Admin Options → Manage MIDAS → Security)

Improved Session Control

In MIDAS v4.11, we introduced a new security setting (MIDAS Admin Options → Manage MIDAS → Security → Session Control) to automatically log out any users that have remained logged in for more than a set number of hours.

This is different to existing “inactivity” logout setting, which causes users to be logged off after a period of no activity. The additional “Always force logout after…” setting will automatically log users off after a set period of time, regardless if they are “active” or not.

Why is this useful? Well, web browser extensions/addons exist which allow you to “reload” a web page (or part of a web page) on a recurring interval. This could potentially allow a user account to remain logged in indefinitely, even if the “Inactivity forces logout after…” setting was set.

For example, if “Inactivity forces logout after…” setting in MIDAS was set to “1 hour”, then usually 1 hour after a user’s last interaction with MIDAS, they will be automatically logged off. However, if an addon/extension were setup to “reload” part of MIDAS every 30 minutes, this would look like “user activity” to MIDAS, and so the account would never be automatically logged out.

To combat this, the new additional “Always force logout after…” setting was introduced for v4.11. If your business usually runs 9am-5pm, you could set this setting to 8 hours. This will mean that no user account can remained logged in for more than 8 hours in total. So if a user was to login at 9am and use a browser addon/extension to effectively remain logged in all day, they will still be automatically logged out of MIDAS at 5pm.

New Session Manager

MIDAS can be configured to allow concurrent logins to user accounts from multiple browsers/devices. When enabled, this would allow a user to be logged into MIDAS from their laptop, phone, and tablet all at the same time.

MIDAS v4.11 introduced a new “Session Manager” allowing users to see other devices they’re currently logged in from (including IP address and browser) and remotely log each of them out!

Improved Password Change Behavior

Given that MIDAS provides the ability (if enabled) to allow multiple concurrent logins to the same user account, In v4.11 we’ve enhanced security and made it so that if a user changes their MIDAS password, then all other devices they’re currently logged into from will be automatically logged out. Previously, changing a password from one device wouldn’t take affect on other devices a user was logged into until the next time they logged in.

Cryptographically-secure Random Number Generation

MIDAS stores passwords which are SHA512 hashed and randomly “salted”. The “randomness” of this “salt” has been improved starting with v4.11. Now, if the Perl module “Math::Random::Secure” is available on the server where a MIDAS system resides, then MIDAS will utilize this module to generate Cryptographically-secure random numbers.

You might also be interested in:
Tips For Keeping Your MIDAS Secure

One of our customers recently contacted us to report a strange issue whereby booking requests made through their MIDAS scheduling system were seemingly vanishing from their system.

The “Booking Request” features of MIDAS, allow people to submit booking “requests” which then require approval by an administrator before becoming a “confirmed” booking.

There are a number of reasons why a booking request may legitimately appear to “vanish” from the system; first of all, another administrative user may have already rejected the original booking request, or the original requestor may have changed their mind and canceled their own request.

When a person makes a booking request, MIDAS automatically send them an email notification containing details of the request they’ve submitted. These email notifications also contain a “booking request cancellation link” allowing them to cancel their request if for whatever reason they’ve changed their mind before their request is approved.

Inspecting the provided “Recent Activity Log” for the customer’s MIDAS system, there was no evidence to suggest that another user had simply rejected the missing booking requests.

There was however evidence that the booking request cancellation links, contained within the notification emails sent to original requestors had been clicked.

The customer was confident that no-one had clicked these cancellation links in their emails.

Now, the “Recent Activity Log” within MIDAS is very useful – not only does it record actions performed within a MIDAS system, it also records the user who performed the action (where applicable), the time/date the action occurred, and the IP address of the device which performed the action.

This allowed us to correlate booking request cancellation link clicks with the IP addresses from which each originated.

Interestingly, the IP addresses could all be traced back to Barracuda Networks, Inc, a company offering security products, including email security and spam filters.

So what was going on?

Once upon a time spam filters could easily detect spam email messages, as spammers tended to the same domains in their spam. As a result, spam filtering software could simply scan the content of an email message, and cross-reference any links contained within against a list of known spamming domains (known as a “blacklist”).

Many spam filters still behave in this way, however, in an attempt to stay one step ahead of the spammers, some spam filtering software/services – such as those provide by Barracuda Networks, Inc, go one step further and actively “click” EVERY link in every email they scan. The purpose behind this is to analyze the content and domain every link points to.

Whilst this will most likely help reduce spam further for the recipient, it can have a number of undesired consequences for users!

For example, if the recipient subscribes to any newsletters/mailing lists which contain a one-click unsubscribe link at the bottom, they will be automatically unsubscribed simply by receiving the email itself, before they even open it – let alone click the unsubscribe link!

The same thing was happening for our customer’s booking request notification emails – the booking request cancellation links were being automatically “clicked” by the spam filtering software/services which were scanning the recipient’s email.

Balancing user convenience vs aggressive mail scanners

We’ve always believed in making things as easy as possible for users – which is why we originally made canceling booking requests as simple as a “one-click” link – click once, and your request is canceled.

However, in light of these recent issues, we’re making a small change for MIDAS v4.12. Canceling a booking request will now unfortunately be a two-step process. Clicking a booking request cancellation link in a notification email will take the requestor to a web page where they will need to then click a confirm button in order to cancel their request.

The introduction of this second confirmation step, whilst less convenient for the end-user, will at least prevent aggressive mail filtering software/services which automatically “click” every link in every email, from automatically canceling booking requests without any human interaction.

The same “two-step” behavior will also be applied for links in booking/invoice reminder emails to suppress future reminders from a MIDAS system.

In the meantime, if you’re running an earlier version of MIDAS, and notice your booking requests being automatically canceled without any intervention, please check and adjust the settings in your mail scanning/filtering software to “whitelist” email from your MIDAS system or prevent the automatic following of links within email.