#wi-fi authentication

By Dr Chris Spencer, CTO, GlobalReach Technology

It's been 16 years since HTTP 1.1 (RFC2616) became a standard. Yes you read that right -  16 years - and I expect that a few of us are now feel very old as we read that.

But, a new faster securer standard has now been approved. It’s known as HTTP/2.

Most modern browsers already have support for HTTP/2. From a user’s perspective it’s seamless, but the biggest improvements are the  faster page load times, which means a faster and greater user experience.

GlobalReach Technology has already deployed the backend infrastructure to deliver all our captive portal pages over HTTP/2 to supported clients. (another GlobalReach first).

The benefit is that captive portal delivery over HTTP/2 greatly improves performance and loading times.

The Problem with HTTP/1.1

HTTP/1.1 has served the internet well for more than 16 years, but its age is starting to show, and it's lost its shine. In the face of today’s user demand for ever-increasing speed and content, it isn’t built to handle the future volumes.

Loading a web page now takes more resource than ever, and because HTTP really only allows one outstanding request per TCP connection. loading all of those assets (css, images, jQuery, JavaScript) efficiently is difficult.

In the past, browsers have used multiple TCP connections to issue parallel requests. However, there are limits to this; if too many connections are used, it’s both counter-productive (TCP congestion), and it’s fundamentally unfair because browsers are taking more than their share of the network resources.

At the same time, the large volume requests means that there’s a lot of duplicated data in transit over the network. Backhaul whether that fibre, cable or in the air, is at a premium.

Both of these factors means that HTTP/1.1 requests have a lot of overhead associated with them. If too many requests are made, performance suffers both on the network and at the server.

This has forced the industry into a corner where it’s considered best practice to do things like data: inlining, domain sharding, concatenation and putting content into multiple content delivery networks. These tricks are indications of underlying problems in the protocol itself, and cause a number of headaches when they’re used.

The Nuts & Bolts

HTTP/2 (originally named HTTP/2.0) is the second major version of the HTTP network protocol used by the World Wide Web. It is based on SPDY, an HTTP-compatible protocol developed by Google and supported in Chrome, Opera, Firefox, Internet Explorer 11, Safari, and Amazon Silk browsers.

HTTP/2 is was developed by the Hypertext Transfer Protocol working group of the Internet Engineering Task Force. HTTP/2 is the first new version of HTTP since HTTP 1.1, which was standardized in RFC 2616 in 1999. The working group presented HTTP/2 to IESG for consideration as a proposed standard in December 2014, and IESG approved it to publish as proposed standard on Feb 17, 2015.

The standardization effort came as an answer to SPDY. The working group charter mentions several goals and issues of concern:

Negotiation mechanism that allows clients and servers to elect to use HTTP 1.1, 2.0, or potentially other non-HTTP protocols.

Maintain high-level compatibility with HTTP 1.1 (for example with methods, status codes, and URIs, and most header fields).

Support common existing use cases of HTTP, such as desktop web browsers, mobile web browsers, web APIs, web servers at various scales, proxy servers, reverse proxy servers, firewalls, and content delivery networks.

Decrease latency to improve page load speed in web browsers by considering:

1. Data compression of HTTP headers 2. Server push technologies 3. Fixing the head-of-line blocking problem in HTTP 1 4. Loading page elements in parallel over a single TCP connection

The Difference With HTTP 1.1

The proposed changes do not require any changes to how existing web applications work, but new applications can take advantage of new features for increased speed.

HTTP/2 leaves most of HTTP 1.1's high level syntax, such as methods, status codes, header fields, and URIs, the same. The element that is modified is how the data is framed and transported between the client and the server.

Websites that are efficient minimize the number of requests required to render an entire page by minifying (reducing the amount of code and packing smaller pieces of code into bundles, without reducing its ability to function), resources such as images and scripts. However, minification is not necessarily convenient nor efficient, and may still require separate HTTP connections to get the page and the minified resources.

HTTP/2 allows the server to "push" content, that is to respond with data for more queries than the client requested. This allows the server to supply data it knows a web browser will need to render a web page, without waiting for the browser to examine the first response, and without the overhead of an additional request cycle.

Additional performance improvements in the first draft of HTTP/2 (which was a copy of SPDY) come from multiplexing of requests and responses to avoid the head-of-line blocking problem in HTTP 1 (even when HTTP pipelining is used), header compression, and prioritisation of requests.

SPDY

SPDY was a research project spearheaded by Google that is also an applicable protocol, designed for the transportation of information and other content on the web.

SPDY primarily focuses on reducing latency. SPDY uses the same TCP pipe but different protocols to accomplish this reduction. The basic changes made to HTTP 1.1 to create SPDY include: "true request pipelining without FIFO restrictions, message framing mechanism to simplify client and server development, mandatory compression (including headers), priority scheduling, and even bi-directional communication."

The biggest difference between HTTP/1.1 and SPDY, is that each user action in SPDY is given a "stream ID", meaning there is a single TCP channel connecting the user to the server. SPDY splits requests into either control or data, which is a "simple to parse binary protocol with two types of frames." SPDY has shown evident improvement from HTTP, with a new page load speedup ranging from 11.81% to 47.7%.

HTTP/2 uses SPDY as a jumping-off point; though SPDY is an improvement on HTTP 1.1, it does have some limitations. SPDY communicates separately with each host, which means that multiplexing happens only at one host at a time, no matter how many connections are open. This means that SPDY can only download things from one host at a time. The improvement HTTP/2 makes on this is that it allows multiplexing to happen at different hosts at the same time. This makes downloading multiple web pages or content from the Internet significantly faster.

HTTP/2 also uses a fixed Huffman code-based header compression algorithm, instead of SPDY's dynamic stream-based compression. This helps to reduce the potential for attacks on the protocol.

On February 9, 2015, Google announced plans to remove support for SPDY in Chrome, in favour of support for HTTP/2, by early 2016. This, started with Chrome 40.

Encryption

HTTP/2 is defined for both HTTP URIs (for now in the clear) and for HTTPS URIs (over TLS, where TLS 1.2 or newer is required).

Some implementations, such as Firefox, have stated that they will only support HTTP/2 when it is used over an encrypted connection.

The Faster Web is Just Around the Corner. Fasten your Seat Belts…..

By Dr Chris Spencer, CTO, GlobalReach Technology

Hypertext Transfer Protocol Secure (HTTPS) is the secure version of HTTP, the protocol over which data is sent between your browser and the website that you are connected to. It plays a crucial part in successful Wi-Fi authentication. This article tells you what you need to know about HTTPS vs HTTP.

 The 'S' at the end of HTTPS stands for 'Secure'. It means all communications between your browser and the website are encrypted. HTTPS is often used to protect highly confidential online transactions like online banking and online shopping order forms, clients’ registration information or subscribers’ user credentials.

Web browsers such as Internet Explorer, Firefox and Chrome also display a padlock icon in the address bar to visually indicate that a HTTPS connection is in effect.

When a user requests a HTTPS connection to a webpage, the website will initially send its SSL certificate to the browser. This certificate contains the public key needed to begin the secure session. Based on this initial exchange, the browser and the website then initiate the 'SSL handshake'. The SSL handshake involves the generation of shared secrets to establish a uniquely secure connection between the client browser and the website.

When a trusted SSL digital certificate is used during a HTTPS connection, users will typically see a padlock icon in the browser address bar. When an extended validation certificate is installed on a web site, the address bar will turn green.

How does HTTPS Work?

HTTPS pages typically use one of two secure protocols to encrypt communications - either SSL (Secure Sockets Layer) or TLS (Transport Layer Security). Both the TLS and SSL protocols use what is known as an 'asymmetric' Public Key Infrastructure (PKI) system. An asymmetric system uses two 'keys' to encrypt communications, a 'public' key and a 'private' key. Anything encrypted with the public key can only be decrypted by the private key and vice-versa.

 As the names suggest, the 'private' key should be kept strictly protected and should only be accessible the owner of the private key. In the case of a website, the private key remains securely ensconced on the web server. Conversely, the public key is intended to be distributed to anybody and everybody that needs to be able to decrypt information that was encrypted with the private key.

What is a SSL certificate?

When you request a HTTPS connection to a webpage, the website will initially send its SSL certificate to your browser. This certificate contains the public key needed to begin the secure session. Based on this initial exchange, your browser and the website then initiate the 'SSL handshake'. The SSL handshake involves the generation of shared secrets to establish a uniquely secure connection between yourself and the website.

Problems with Captive Portals

A Wi-Fi captive portal works by intercepting, impersonating, and altering the connection between client and web server. So, in essence, a captive portal is what’s known as a ‘man-in-the-middle’ attack. It has good intentions, but it is a man-in-the-middle all the same.

Intercepting ANY HTTPS traffic and redirecting to an alternative destination will always prompt a user to be aware of this with any modern browser or operating system. This is a fundamental part of the security that HTTPS incorporates.

For example, if a guest attempted to get to their online banking site (either via wireless or wired) and their traffic was intercepted and redirected to a different site with no warning this would be seen as an industry wide security concern, users could be redirected to phishing sites as an example with no warning.

A captive portal used correctly has a good intention, but not everyone would use it for the same reason. Intercepting any HTTPS request and redirecting to a different destination should always warn the user so that the user can make a choice if to proceed or not.

 So, What are the Options for my WLAN Gateway?

There currently appears to be three different industry approaches to the issue:

Intercept any HTTPS (or HTTP) and return a captive portal: This will ALWAYS display a warning that the site is being intercepted and that the traffic is being redirected.There is little that can be done in this circumstance, as outlined in this document HTTPS is designed to stop this very thing from happening and a warning will be triggered.

Allow all HTTPS traffic by default for all un-authenticated devices: By allowing all traffic applications and HTTPS driven websites would function normally in an unauthenticated state with the hope that the device will eventually make a HTTP call that can be intercepted and trigger the captive portal. This raises a few concerns, namely in accounted traffic. A users’ traffic is not normally allocated to their account until they are authenticated. Any traffic that device generate over HTTPS will be unaccounted for. As more and more of the internet converts to HTTPS then there are less chances to intercept the user and return a captive portal.

Drop all HTTPS traffic: The users’ device would not gain access to resources delivered over HTTPS. Their device would eventually see “a page can not be found” type message in their browser as the request would simply end up timing out.

Where bandwidth and customer access is not a major concern then option 2 maybe the best one to look at. But, where bandwidth is extremely costly, for example on an aeroplane, often they resort to option 3. Ultimately it is a trade between usability and effective interception.

The Future

The Wi-Fi industry is aware of the necessity to have the ability to put a captive portal/interstitial/T&Cs in front of certain users’ access to networks and has working groups assigned to this need. GlobalReach Technology has a representative sat on joint industry bodies looking and collaborating for a usable solution.

 There has been a standard proposed, RFC7710. This defines an extension to the DHCP protocol such that the captive portal location can be provided during the IP address assignment within an option packet, eliminating all the guessing and probing that we need to do with today's captive portal detection. The current status of this standard is 'proposed', and now has a wider industry importance to this as more and more of the internet becomes SSL-enabled. It may improve things in the future, but for now HTTPS carries the above warnings.

 Google Chromium Browser is also looking into utilising a new browser tab for captive portals information although we can not discuss this currently as this is under NDA.

About GlobalReach Technology

GlobalReach Technology is the brand behind Odyssys, the most complete, scalable Wi-Fi authentication and provisioning platform. Its software and cloud-based platform powers some of the world’s most complex Wi-Fi services, delivering billions of authentications a year. These include San Francisco, San Jose, London, Sydney, Mexico and throughout Europe.