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 to the owner of the private key. In the case of a website, the private key remains securely ensconced on the webserver. 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 an 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 an HTTP call that can be intercepted and trigger the captive portal. This raises a few concerns, namely in accounted for traffic. A users’ traffic is not normally allocated to their account until they are authenticated. Any traffic that the device generates over HTTPS will be unaccounted for. As more and more of the internet converts to HTTPS then there are fewer 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 may be 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 Dr Chris Spencer
A specialist in secure, high-performance wireless. Chris helped to design and build solutions for international cities and enterprises. A thought leader in secure, seamless sign-on and Passpoint, he is involved in the specification and delivery of Next Generation Hotspot, leads and co-leads working groups for the WBA, Hospitality Technology Next Generation (HTNG), and the Seamless Air Alliance (SAA).