SSL connectivity underway for all Central Repository users

UPDATED: Sunday, 03 August 2014

It is live! Within an extremely short turnaround time the Sonatype Operations team has coordinated certificates and other setup with our excellent CDN provider Fastly and you can now all enjoy the content of the Central Repository via HTTPS/SSL. Going forward we urge all upstream projects to adopt the secure URL as part of their default configuration. In the mean time we have updated the instructions for consuming components from the Central Repository with all the details necessary for your repository manager, build tool or other access mode you are using. We hope you enjoy this new feature and look forward to your feedback!

BEGIN ORIGINAL POST:

We’ve had quite a bit of public scrutiny recently over how we’ve chosen to provide SSL access to Central for the last two years. At Sonatype, we have a history of investments in the Maven Central community, all of which are focused on improving the quality of the contents, increasing reliability and performance of delivery, and yes, even strengthening security which is often not popular (how many gripes can you find about why we require PGP signatures on artifacts?).

Our Nexus customers were the first to start asking for SSL access a few years ago. At the time, for technical reasons[1] we decided it was prudent to focus on users really intending to leverage an SSL connection. We also recognized the importance of secure access and decided to make it available for anyone who desired it, not just Nexus Pro customers. This included ensuring that both Artifactory and Apache Archiva were able to support this new mode correctly along with Nexus OSS users.

In 2012 we weren’t sure how many people not already running repository managers were interested in SSL access. In the spirit of lean product development, rather than turning it on for every single request (which would require coordination across a very large ecosystem of tools), we decided to raise the signup friction just a tiny bit to see if this was a worthy pursuit. A fee of $10 seemed like a trivial amount with just enough friction to overcome the “Cost of Zero Cost” and provide an adequate gauge of true demand.

Our intention was not to profit from this, merely to figure out if such a service had even a tiny amount of perceived value to the users, and so rather than keeping the money, we decided to pledge an equivalent amount to open source foundations.

Depending on how you look at it in hindsight, the experiment was either a failure or success. Despite a talk at Java One (referenced in my original blog on this topic) about cross build injection highlighting the potential risk, until yesterday we had a grand total of…

12 signups for SSL access in 2 years.

That’s not a typo, that reads twelve. Now I’m not saying that means it’s not important (it clearly is) but it does help explain the blind spot we had in this case.

In the last 24 hours alone, we had 12 more signups.

Given all the attention from Heartbleed, Snowden and other high profile attacks, it’s not really surprising that people are clearly ready in 2014 for a more secure solution. My take: Hallelujah!

The outcry of attention this issue has received is evidence in spades that it’s time to eliminate the friction and provide SSL access by default. Again, you can argue that we should have seen this coming.

Fortuitously, we had been moving in this direction already and had negotiated SSL pricing at the scale of Central into our CDN contract renewal effective August 1st (for the curious, origin and CDN bandwidth for Central cost $150K last year and is growing at 40-50% annually). So, perhaps we did see it coming, just not quite in time. A few days it would seem.

We expect to have SSL access available for testing tomorrow and will announce it more broadly once we are sure there are no gotchas hiding in the various tooling integrations. Regardless, we will support the old non-SSL mode for a period to ensure compatibility as the migration proceeds.

We will continue to participate in the public debate about how to make a more secure software supply chain available for everyone. This includes pressing, among other things, issues like requiring trustworthy PGP signatures and good practices around component selection. After all, having a secure connection over which you download a known vulnerable component… well, perhaps that is a subject of a different post.

We would also like to thank Max Veytsman, the original blog poster for his willingness to challenge the status quo. We do strive to do the right thing for the community with plenty of anecdotal evidence to support this, and appreciate healthy debate, even if it is a bit painful sometimes.

P.S. If you are interested in contributing directly to the Apache Software Foundation, you may do so here.

[1] The provider used at the time did not support origin server (i.e. Sonatype’s servers behind the CDN edge caching servers) SSL certificate validation. Deploying SSL via this structure would have resulted in a potential man-in-the-middle attack as components were transported from origin to the CDN provider. We opted instead to provide SSL directly from our origin so that we were able to ensure end to end transport layer security.