December 10, 2013
*See an update on our global rollout of HTTPS by default here.
Starting today, we are transitioning the entire LinkedIn experience to HTTPS by default. Our members have had the ability to opt in to access our site via HTTPS since early 2012, and our mobile experience has always been over HTTPS.
HTTPS is the layering of the HTTP protocol on top of Transport Layer Security (TLS), and its predecessor Secure Sockets Layer (SSL). With HTTPS, all traffic from the browser to the webserver is encrypted.
We've started the rollout in the Netherlands, a country with a significant active member base and good HTTPS performance, and plan to complete it globally over the next several months.
Initially we will put members into a full-site HTTPS session as they log in using Firefox or Chrome (other browsers to follow), and their authentication cookie will be marked secure. Over time, we will upgrade existing HTTP sessions to HTTPS and issue a new authentication cookie that will also be marked secure.
While we roll out this feature globally, members in other countries can opt in to full-site HTTPS immediately by following the instructions here.
The Migration Process
Converting a large-scale site to HTTPS required a cross-functional team comprised of people from product development, security, CDN, network operations, site reliability, performance and ad operations. Below are some of the interesting challenges we've had to tackle:
- HTTP content: We used w3c Content-Security-Policy-Report-Only
extensively to report on insecure content on HTTPS pages. We process
these reports daily to identify insecure content. We also built
static and dynamic scanners to continuously catch insecure content
on HTTPS pages.
- HTTPS latency: Using client-side measurements we found that the
first page load latency increase for HTTPS over HTTP varied from 15%
in the US to 25% in some countries.
- In addition to the extra round trips for the SSL/TLS
handshake, some browsers have OCSP
checks of the server certificate or the certificate chain
enabled by default. OCSP performance varies by Certificate
Authority (CA) and by country, and OCSP response caching varies
by browser. We evaluated several CA providers for security and
performance and are in the process of rolling out certificates
with optimal size and OCSP performance.
- We use CDNs to cache static content such as CSS. CDN support
for HTTPS varies by geography. Overall there are fewer HTTPS
termination points than there are for HTTP, which can lead to
higher page load times for the user. We are working with our
CDN partners to improve HTTPS connection times.
- We maintain server-side SSL/TLS sessions to promote session reuse and an abbreviated SSL/TLS handshake. By reusing sessions when possible, we save one full roundtrip over a full SSL/TLS handshake, and also incur lesser computation costs.
- In addition to the extra round trips for the SSL/TLS handshake, some browsers have OCSP checks of the server certificate or the certificate chain enabled by default. OCSP performance varies by Certificate Authority (CA) and by country, and OCSP response caching varies by browser. We evaluated several CA providers for security and performance and are in the process of rolling out certificates with optimal size and OCSP performance.
- Ads: Our goal is to always serve the most relevant ads to our
members. These ads, which are embedded in an iframe, frequently
include images or beacons that may have hardcoded HTTP URLs within
them. We worked closely with our advertising customers to transition
their creatives into an SSL/TLS compliant format, which will be a
requirement moving forward. We worked with our ad serving provider
DoubleClick on a tool to render legacy ad tags and automatically
modify them to be SSL compliant. Lastly, we've also created a QA
process for testing new ad tags for compliance before they are
targeted on the site.
- Scaling: We conducted several rounds of performance testing using httperf modified to support session reuse. We simulated traffic with different ratios of new to existing SSL/TLS sessions, and varying number of requests per connection to estimate the capacity for SSL/TLS termination.
The Road Ahead
Here are some additional SSL improvements that we are continuing to work on:
- Headers: We plan to use the HTTP
Strict Transport Security (HSTS) header to instruct browsers
to only use HTTPS to communicate with our website. We currently
don't set this header because members who have opted into full-site
HTTPS may share their browser with others who have not. We plan to
set this header once all members have been ramped to full-site
HTTPS. It is also our goal to use the Content-Security-Policy default-src
to instruct the browser to load only content sourced over HTTPS.
Note that these policies are enforced only by modern browsers.
- Protocols and Ciphersuites: We use 2048-bit RSA keys and support
TLS 1.0 and SSL 3.0. We have plans to make the following changes:
- Support TLS 1.2 as it has better security properties than TLS
- Use Elliptic Curve Ephemeral Diffie-Hellman (ECDHE) for key
exchange to achieve Perfect
Forward Secrecy (PFS). With PFS, even if the webserver
private key is compromised, previously recorded encrypted HTTPS
traffic can't be decrypted.
- Use Elliptic Curve (EC) certificates for browsers that support
them. EC algorithms use smaller keys than RSA, allowing us to
provide equal or better security more efficiently.
- We are evaluating whether or not to continue support for SSL 3.0 and RC4.
- Support TLS 1.2 as it has better security properties than TLS 1.0.
- Pinning: Pinning is a mechanism by which a website can inform the
browser of the CAs the site uses. Without this feature, attacker can
use a compromised CA to impersonate websites. We plan to implement
pinning in order to protect against this issue.
- Performance: We will be working on a number of initiatives to further increase HTTPS performance. Part of this process will be the termination of connections closer to the network edge. Being closer to the end user means faster roundtrips and requests will be forwarded over persistent secure connections to our datacenter over a private network. We will also be adding support for TLS session tickets.
Here at LinkedIn, we are committed to putting our members first. Making the LinkedIn experience more secure is one of the many ways we do this every day. We appreciate reports of problems you may find with our HTTPS transition. Please follow the instructions here to report security vulnerabilities, report problems, or ask questions about our transition.