• Immutable Page
• Info
• Attachments
• More Actions: Raw Text Print View Render as Docbook Delete Cache ------------------------ Check Spelling Like Pages Local Site Map ------------------------ Rename Page Delete Page ------------------------ Subscribe User ------------------------ Remove Spam Revert to this revision Package Pages Sync Pages ------------------------ Load Save SlideShow

DRAFT: Reducing the cost of SSL

The majority of our time right now is lost in network speed. Very roughly, from eyeball webpagetest.org analysis, SSL negotiation accounts for 50% of this time. Thus, in theory, the biggest available win from a single change would be to switch off SSL: that would save about 30%.

That said, we can't simply switch off SSL. Some parts of the site need to stay protected. Moreover, we should consider whether other changes might significantly reduce the cost of SSL.

Reducing SSL Use

Risk analysis

Level 0

Everything is SSL

Current status

Level 1

Anonymous access (GET of publicly-accessible information) is not over SSL

I don't see any additional risk. The benefit isn't really there for most of our high-importance users. This might help OEM folks though.

Level 2

Anonymous access and equivalent Authorized access (GET of publicly-accessible information) is not over SSL

XXX There is a risk of leaked data. A publicly accessible URL may show private information for a given authenticated user. We would need to identify the potentially leaked data and how valuable it is. A first cut is that private bugs (security-related), private branches (security-related), and (hypothetical?) private teams and projects all have high-risk data. On the face of it, it seems like something we would need to take very seriously, but could handle. Note also that search is a GET, as it should be, but that's another place where security bits might obviously leak.XXX

We've discussed two options for level 2 and beyond. I'm not sure how valuable they are, but I record them here.

1. Users could specify that they wanted all of their interactions over HTTPS. (This might be a flag on the user, or something as simple as "once you are using HTTPS, we don't switch you back.")
2. Projects could have an intermediate designation: protected (not private, but only accessible over HTTPS.)

Level 3

Level 2, plus some POSTs are allowed over HTTP.

XXX This level gets into all kinds of excitement. Things that might not be as obvious as others include merge proposal approvals sometimes kicking off merges, and package changes pushing code out to Ubuntu users. If this is approached at all, it's likely that it would need to be a whitelist. We'd need to assemble a whitelist to prove there was even sufficient win for us to pursue this. XXX

Implementation challenges

Beyond handling the security risks identified...

Separate session (auth) cookies for HTTP and HTTPS: necessary and pretty easy

Switching back and forth between HTTP and HTTPS makes some browsers complain/warn the user.

Other Possible Changes

• Streamlined connection reuse in the browser so SSL cost is once (per parallel connection) (Librarian is particularly a problem on the front page).
• Reduce things to download on page/improve caching of page elements. If a the first page had the SSL cost but subsequent pages only downloaded the new page content because the JS, CSS, and images were all reused, that would be fantastic for many reasons, SSL cost not least among them. (Question for mars: could we make an automated test for this in Windmill? We should certainly be able to do this with a page alarm on webpagetest.org...) This would obviously not help for people visiting Launchpad for the first time, but our most important audiences use Launchpad as a daily or hourly tool.