Default HTTPS

*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.

The Rollout

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.
• 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 1.0.
    
  • 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.
• 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 public-key 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.