Default HTTPS Update
June 11, 2014
At LinkedIn we are committed to putting our members first and making our experience more secure is one of the many ways we do this every day. We started transition of the LinkedIn site to default HTTPS in December 2013. We are happy to report that we are now serving member traffic for all users in US and EU by default over HTTPS.
We worked on a number of initiatives early this year before reaching this first wide ramp of HTTPS.
Session Upgrade
We introduced a mid-session HTTP -> HTTPS upgrade that does not require user to go through the login flow to transition to default HTTPS. As part of this HTTPS upgrade, we issue a new authentication cookie that is marked secure and we also invalidate the old authentication cookie. Through these changes, we ensure that the old HTTP session is destroyed and user's authentication cookie after default HTTPS is never in the clear in the network. As before we also put users into default HTTPS at time of login and issue them a secure authentication cookie.
Mixed Content
One of the biggest challenges we had to address before ramping widely was mixed HTTP content on HTTPS pages. We used several strategies to deal with this mixed content:
- We wrote a static source code analyzer to parse Dust and JSP templates to identify use of HTTP resources on page and to generate patches.
- We modified our selenium test framework to fail tests when rendered pages had HTTP resources on HTTPS pages.
- We set Content-Security-Policy-Report-Only header on 1% of HTTPS responses and analyzed violation reports to identify bugs.
Display Ads
We updated our Ad specification to require SSL compliance and we worked with our ad vendors, Doubleclick, and other companies to identify non-compliant ads in the system. In order to deal with legacy non-compliant ads already in the system, we developed a tool AdFullSsl (see https://github.com/linkedin/adfullssl) to fix ad creatives to be SSL compliant when possible. Creatives modified this way are considered compliant only when requests generated when ad is rendered on HTTP matches requests when the same ad is rendered on HTTPS. AdFullSsl can handle a variety of different ad unit formats including template, flash, and 3rd party creatives. The tool integrates with Doubleclick API for downloading creatives and for writing successfully modified creatives. AdFullSsl can also be run in standalone mode working with creatives on the local filesystem. Down the road we plan to add more features including checks for compliance with size, cookies, etc. We have opensourced AdFullSsl under Apache 2.0 license for the benefit of companies who deal with 3rd party display ads.
Road Ahead
Performance
The transition them from HTTP to HTTPS in the US and EU did not result in a significant page load performance hit for our members. Our tests show that HTTPS will increase page load time outside the US and EU. We are actively working on the following initiatives to enable us to roll out HTTPS to our remaining members:
- We are building more Points-of-Presence (POP) globally so that we can terminate connections closer to the user for improved connection and content download time.
- We are working with CDN partners to have them upgrade their HTTPS serving infrastructure.
- We are deploying certificates for our primary and CDN domains issued by Certificate Authority (CA) with best performance and availability.
In addition, we have cross-functional team working site speed initiatives this year to improve overall page load time for all users. We are actively experimenting with the following:
- Improving SSL session re-use using TLS session tickets and increasing server side session timeouts.
- Increasing TCP initial window size to reduce base page content download time.
- Testing protocols such as SPDY.
- Enabling OCSP stapling to reduce connection time.
Security
Stay tuned for the following security improvements:
- HTTP Strict Transport Security
- TLS 1.2
- Perfect Forward Secrecy
- Public Key Pinning
Please follow the instructions here to report problems with HTTPS including insecure configuration, mixed content issues, or to ask questions about default HTTPS transition.