The BBC’s role as a trusted destination on the Web makes it extremely important that we present a service to our audience that is trusted, secure and protects their privacy. Paul Tweedy, Lead Technical Architect in the Online Technology Group, explains how browsing across BBC Online will become more secure with the release of a new update.
One of our roles in the Online Technology Group of BBC Design & Engineering is to ensure BBC Online is secure at the point of access, in a constantly-evolving world of Web standards, security vulnerabilities, hackers and malware. We work with the software engineering and operational teams across the division who build our services to achieve this.
In mid April, we made a small but significant step towards ensuring the security and safety of our audience: We enabled HTTPS (secure HTTP) on the domestic BBC Homepage and Travel News and mobile Weather sites, with more to come.
Technical Context
The World Wide Web was designed during the relative infancy of the Internet, when the number of users was small and access was relatively closed. One of the Web’s initial strengths was that it was simple to implement and debug; security was an afterthought.
HTTPS has been around since 1996, but, for the first 15 years of the Web, HTTPS was mainly used to selectively secure the transmission of sensitive information, e.g. credit card details, for e-commerce and similar use cases. This was usually due to the cost of implementing HTTPS being high - both in financial terms and in technical complexity, which also meant that it was prohibitive to serve high traffic peaks when major news or sport stories break, as the BBC often has to.
Behind the scenes, BBC Online has been using HTTPS for many years, allowing its components to be hosted anywhere without the need to trust any intervening network, and using X.509 client certificates to authenticate each other.
However, it’s taken many years of steady technical progress for it to become practical for large web sites to move all of their public traffic to HTTPS - not just for e-commerce purposes, but to:
- Provide server authenticity - users have a measure of trust that they are actually connecting to the sites they intend to.
- Protect users against common hacking attacks - man-in-the-middle, DNS hijacking, etc.
- Keep up with stricter Web and browser security standards.
- Allow use of modern Web standards such as HTTP/2.
- Allow users to “sign in” to sites for a personalised experience, and for their data to be transported securely.
So, why didn’t we just enable HTTPS years ago, like other some large web sites? The real challenges for us were:
- Enabling HTTPS via our CDN partners, to maintain functionality at times when we deliver BBC Online through a CDN, required a host of technical & contractual changes.
- The CPU overhead of TLS encryption has historically been significant. We’ve done a lot of work behind the scenes to improve both the software and hardware layers to minimise the load impact of TLS whilst also improving security.
- We required several internal software changes. e.g. sites didn’t always make use of scheme-relative URLs, so required development work to make them scheme-agnostic or HTTPS-only.
- As a public service broadcaster, we have to be as inclusive as possible when it comes to device support, but this often proves difficult. Devices such as smart TVs and Internet radios are key to the availability of services such as iPlayer, but bring unique challenges for managing HTTPS configurations, and many don’t support HTTPS at all!
Therefore before this year, HTTPS was limited to a small set of functions on BBC sites, such as signing in to BBC iD, online voting, and other areas which dealt with personalised data.
Earlier in 2016, the Chromium development team decided to implement a change to Google Chrome, preventing access to certain in-browser features on ‘insecure’ (non-HTTPS) web pages. In practice, this meant that key features of certain products, such as the location-finding feature within the Homepage, Travel News and Weather sites, would stop working if we didn’t enable HTTPS for those services.
Within our department, we had been preparing for this future for some time, lobbying technology providers to support current standards, updating TLS configurations and deprecating older versions. However, this brought the need to make HTTPS work for these products forward.
We set ourselves the deadline of mid-April to roll out this first phase of HTTPS delivery and through working with the product engineering teams, our operational colleagues and our CDN partners, we achieved the required support in our infrastructure to allow our product teams to migrate to HTTPS as they need to.
What this means for you
Now, when you access the BBC Homepage or Travel News sites, you might see a green padlock appear in your browser’s address bar. This means that you can trust that the connection between you and the BBC servers is secure, keeping your data safer in transit and protecting your privacy. It also gives us confidence that the content provided by the BBC remains intact and unaltered on its journey to your devices, no matter where you happen to be.
As BBC sites roll out support for HTTPS across the year, you will see the green padlock more and more as you browse BBC Online, even if you aren't signed in with BBC ID. Our aim is to make secure browsing the default experience for most of our audience by the end of 2016.
There are always practical limitations to site-wide technical changes, and HTTPS Everywhere is no different. Sites and content we consider ‘archival’ that involve no signing in or personalisation, such as the News Online archive on news.bbc.co.uk, will remain HTTP-only. This is due to the cost we’d incur processing tens of millions of old files to rewrite internal links to HTTPS when balanced against the benefit.
Next steps & challenges
There’s plenty more to do over the coming months. We’ll be focussing on:
- Gradual roll-out of HTTPS as and when products are ready – aiming to be HTTPS across BBC Online within the next 12 months.
- Evaluating audio/video delivery via HTTPS.
- Support for the next version of the HTTP standard, HTTP/2.
- Optimising HTTPS/TLS for performance, particularly on low-powered devices such as smartphones.
- Examining compatibility with old devices, particularly consumer electronics, that can’t be easily updated.
Big thanks go to Andrew Hutson, Craig Taylor and Neil Craig, all architects in my team who are tracking the standards and making this happen. Thanks also to the Homepage and Travel product teams, who we worked with closely to achieve this important first phase.
Finally, this is an exciting area, and we’re always recruiting - so if you’re an engineer or architect with a strong interest and/or expertise in HTTP(S), Internet security and secure content delivery, take a look at two roles open now for a Senior Software Engineer (Media Analytics) and a Junior Software Engineer (Cloud Platform).