[ruby-core:67195] [ruby-trunk - Feature #10672] [Open] Enable SSL on cache.ruby-lang.org

[ruby-core:67195] [ruby-trunk - Feature #10672] [Open] Enable SSL on cache.ruby-lang.org

[eric]

Issue #10672 has been reported by Eric Mill.

----------------------------------------
Feature #10672: Enable SSL on cache.ruby-lang.org
https://bugs.ruby-lang.org/issues/10672

* Author: Eric Mill
* Status: Open
* Priority: Normal
* Assignee: 
* Category: Project
* Target version: 
----------------------------------------
(I apologize if this is not the best place for this -- I'm happy to move this to a different place if it's more appropriate.)

Ruby's official distribution server, cache.ruby-lang.org, is not served over HTTPS. When accessing the server over HTTPS, it presents a certificate from Fastly that is invalid for the domain.

I strongly believe that downloads of public builds of Ruby should be secure, private, and resistant to tampering. HTTPS provides all of those properties.

Some clients, like ruby-build and rvm, use client-side hashes to verify build integrity. Not all clients or users will do this verification, and so baking it into the cache.ruby-lang.org server will ensure that a broader set of Ruby users has a secure, verified download of Ruby.

Even when clients do perform client-side integrity checking, there is always a privacy implication to downloading information. Downloading Ruby without SSL leaks information about the client performing the download through request headers, and informs anyone watching the connection what version of Ruby is likely to be running on the downloading machine. In addition, traffic can be correlated in unpredictable ways: for example, a user agent sent to connect to a download of a Ruby build may appear later to download other information, providing a pattern of client behavior.

In any case, the web is, in general, moving to favor encrypted connections. SSL is faster, CAs like SSLMate and Let's Encrypt are emerging to make the process simpler, and web browsers are starting to encourage encrypted connections and discourage unencrypted ones. 

I request that the Ruby team:

* install a valid certificate on cache.ruby-lang.org.
* update any links to cache.ruby-lang.org controlled by the Ruby team to use the https:// version.
* notify the community of the SSL availability with a tiny announcement post.

Thank you for considering my request.



-- 
https://bugs.ruby-lang.org/

[ruby-core:67196] [ruby-trunk - Feature #10672] Enable SSL on cache.ruby-lang.org

[shibata.hiroshi]

Issue #10672 has been updated by Hiroshi SHIBATA.


Who will pay your plan? SSL certificates and CDN are provided by our sponsors support. 

----------------------------------------
Feature #10672: Enable SSL on cache.ruby-lang.org
https://bugs.ruby-lang.org/issues/10672#change-50674

* Author: Eric Mill
* Status: Open
* Priority: Normal
* Assignee: 
* Category: Project
* Target version: 
----------------------------------------
(I apologize if this is not the best place for this -- I'm happy to move this to a different place if it's more appropriate.)

Ruby's official distribution server, cache.ruby-lang.org, is not served over HTTPS. When accessing the server over HTTPS, it presents a certificate from Fastly that is invalid for the domain.

I strongly believe that downloads of public builds of Ruby should be secure, private, and resistant to tampering. HTTPS provides all of those properties.

Some clients, like ruby-build and rvm, use client-side hashes to verify build integrity. Not all clients or users will do this verification, and so baking it into the cache.ruby-lang.org server will ensure that a broader set of Ruby users has a secure, verified download of Ruby.

Even when clients do perform client-side integrity checking, there is always a privacy implication to downloading information. Downloading Ruby without SSL leaks information about the client performing the download through request headers, and informs anyone watching the connection what version of Ruby is likely to be running on the downloading machine. In addition, traffic can be correlated in unpredictable ways: for example, a user agent sent to connect to a download of a Ruby build may appear later to download other information, providing a pattern of client behavior.

In any case, the web is, in general, moving to favor encrypted connections. SSL is faster, CAs like SSLMate and Let's Encrypt are emerging to make the process simpler, and web browsers are starting to encourage encrypted connections and discourage unencrypted ones. 

I request that the Ruby team:

* install a valid certificate on cache.ruby-lang.org.
* update any links to cache.ruby-lang.org controlled by the Ruby team to use the https:// version.
* notify the community of the SSL availability with a tiny announcement post.

Thank you for considering my request.



-- 
https://bugs.ruby-lang.org/

[ruby-core:67198] [ruby-trunk - Feature #10672] [Assigned] Enable SSL on cache.ruby-lang.org

[shibata.hiroshi]

Issue #10672 has been updated by Hiroshi SHIBATA.

Status changed from Open to Assigned
Assignee set to Hiroshi SHIBATA

----------------------------------------
Feature #10672: Enable SSL on cache.ruby-lang.org
https://bugs.ruby-lang.org/issues/10672#change-50676

* Author: Eric Mill
* Status: Assigned
* Priority: Normal
* Assignee: Hiroshi SHIBATA
* Category: Project
* Target version: 
----------------------------------------
(I apologize if this is not the best place for this -- I'm happy to move this to a different place if it's more appropriate.)

Ruby's official distribution server, cache.ruby-lang.org, is not served over HTTPS. When accessing the server over HTTPS, it presents a certificate from Fastly that is invalid for the domain.

I strongly believe that downloads of public builds of Ruby should be secure, private, and resistant to tampering. HTTPS provides all of those properties.

Some clients, like ruby-build and rvm, use client-side hashes to verify build integrity. Not all clients or users will do this verification, and so baking it into the cache.ruby-lang.org server will ensure that a broader set of Ruby users has a secure, verified download of Ruby.

Even when clients do perform client-side integrity checking, there is always a privacy implication to downloading information. Downloading Ruby without SSL leaks information about the client performing the download through request headers, and informs anyone watching the connection what version of Ruby is likely to be running on the downloading machine. In addition, traffic can be correlated in unpredictable ways: for example, a user agent sent to connect to a download of a Ruby build may appear later to download other information, providing a pattern of client behavior.

In any case, the web is, in general, moving to favor encrypted connections. SSL is faster, CAs like SSLMate and Let's Encrypt are emerging to make the process simpler, and web browsers are starting to encourage encrypted connections and discourage unencrypted ones. 

I request that the Ruby team:

* install a valid certificate on cache.ruby-lang.org.
* update any links to cache.ruby-lang.org controlled by the Ruby team to use the https:// version.
* notify the community of the SSL availability with a tiny announcement post.

Thank you for considering my request.



-- 
https://bugs.ruby-lang.org/

[ruby-core:67207] [ruby-trunk - Feature #10672] Enable SSL on cache.ruby-lang.org

[eric]

Issue #10672 has been updated by Eric Mill.


There are two costs: the certificate, and Fastly's charge for custom domain SSL.

* `https://www.ruby-lang.org` already has a wildcard SSL certificate installed that is valid for `*.ruby-lang.org`. So that cost is already paid.
* I would ask Fastly if they would be willing to waive their charge for custom domain SSL for the Ruby project. Failing a waiver, a serious discount. If Fastly is not willing to do this, I encourage Ruby to look at other options, like [Cloudflare](https://www.cloudflare.com/), which does not charge money for SSL support.

----------------------------------------
Feature #10672: Enable SSL on cache.ruby-lang.org
https://bugs.ruby-lang.org/issues/10672#change-50684

* Author: Eric Mill
* Status: Assigned
* Priority: Normal
* Assignee: Hiroshi SHIBATA
* Category: Project
* Target version: 
----------------------------------------
(I apologize if this is not the best place for this -- I'm happy to move this to a different place if it's more appropriate.)

Ruby's official distribution server, cache.ruby-lang.org, is not served over HTTPS. When accessing the server over HTTPS, it presents a certificate from Fastly that is invalid for the domain.

I strongly believe that downloads of public builds of Ruby should be secure, private, and resistant to tampering. HTTPS provides all of those properties.

Some clients, like ruby-build and rvm, use client-side hashes to verify build integrity. Not all clients or users will do this verification, and so baking it into the cache.ruby-lang.org server will ensure that a broader set of Ruby users has a secure, verified download of Ruby.

Even when clients do perform client-side integrity checking, there is always a privacy implication to downloading information. Downloading Ruby without SSL leaks information about the client performing the download through request headers, and informs anyone watching the connection what version of Ruby is likely to be running on the downloading machine. In addition, traffic can be correlated in unpredictable ways: for example, a user agent sent to connect to a download of a Ruby build may appear later to download other information, providing a pattern of client behavior.

In any case, the web is, in general, moving to favor encrypted connections. SSL is faster, CAs like SSLMate and Let's Encrypt are emerging to make the process simpler, and web browsers are starting to encourage encrypted connections and discourage unencrypted ones. 

I request that the Ruby team:

* install a valid certificate on cache.ruby-lang.org.
* update any links to cache.ruby-lang.org controlled by the Ruby team to use the https:// version.
* notify the community of the SSL availability with a tiny announcement post.

Thank you for considering my request.



-- 
https://bugs.ruby-lang.org/

[ruby-core:69490] [Ruby trunk - Feature #10672] Enable SSL on cache.ruby-lang.org

[rubylang]

Issue #10672 has been updated by Rogier Mulhuijzen.


Heya,

This is Doc from Fastly. Just wanted to let you know that if you send an email with a request to be added to our shared (subjectAltName) cert to "support at fastly dot com", and mention you're on the open source plan, you should get HTTPS service for free.

Open Source projects get CDN services, including HTTPS, for free.

Cheers,

   DocWilco



----------------------------------------
Feature #10672: Enable SSL on cache.ruby-lang.org
https://bugs.ruby-lang.org/issues/10672#change-52792

* Author: Eric Mill
* Status: Assigned
* Priority: Normal
* Assignee: Hiroshi SHIBATA
----------------------------------------
(I apologize if this is not the best place for this -- I'm happy to move this to a different place if it's more appropriate.)

Ruby's official distribution server, cache.ruby-lang.org, is not served over HTTPS. When accessing the server over HTTPS, it presents a certificate from Fastly that is invalid for the domain.

I strongly believe that downloads of public builds of Ruby should be secure, private, and resistant to tampering. HTTPS provides all of those properties.

Some clients, like ruby-build and rvm, use client-side hashes to verify build integrity. Not all clients or users will do this verification, and so baking it into the cache.ruby-lang.org server will ensure that a broader set of Ruby users has a secure, verified download of Ruby.

Even when clients do perform client-side integrity checking, there is always a privacy implication to downloading information. Downloading Ruby without SSL leaks information about the client performing the download through request headers, and informs anyone watching the connection what version of Ruby is likely to be running on the downloading machine. In addition, traffic can be correlated in unpredictable ways: for example, a user agent sent to connect to a download of a Ruby build may appear later to download other information, providing a pattern of client behavior.

In any case, the web is, in general, moving to favor encrypted connections. SSL is faster, CAs like SSLMate and Let's Encrypt are emerging to make the process simpler, and web browsers are starting to encourage encrypted connections and discourage unencrypted ones. 

I request that the Ruby team:

* install a valid certificate on cache.ruby-lang.org.
* update any links to cache.ruby-lang.org controlled by the Ruby team to use the https:// version.
* notify the community of the SSL availability with a tiny announcement post.

Thank you for considering my request.



-- 
https://bugs.ruby-lang.org/

[ruby-core:69615] [Ruby trunk - Feature #10672] Enable SSL on cache.ruby-lang.org

[sparkyjg007]

Issue #10672 has been updated by JEFFREY GENERAO.


Hello Hiroshi,

We are ready for the TLS implementation process at your request.  Your ticket number is 13354, for your reference.

Please contact me with any questions.

Best regards,

Jeff Generao

----------------------------------------
Feature #10672: Enable SSL on cache.ruby-lang.org
https://bugs.ruby-lang.org/issues/10672#change-52958

* Author: Eric Mill
* Status: Assigned
* Priority: Normal
* Assignee: Hiroshi SHIBATA
----------------------------------------
(I apologize if this is not the best place for this -- I'm happy to move this to a different place if it's more appropriate.)

Ruby's official distribution server, cache.ruby-lang.org, is not served over HTTPS. When accessing the server over HTTPS, it presents a certificate from Fastly that is invalid for the domain.

I strongly believe that downloads of public builds of Ruby should be secure, private, and resistant to tampering. HTTPS provides all of those properties.

Some clients, like ruby-build and rvm, use client-side hashes to verify build integrity. Not all clients or users will do this verification, and so baking it into the cache.ruby-lang.org server will ensure that a broader set of Ruby users has a secure, verified download of Ruby.

Even when clients do perform client-side integrity checking, there is always a privacy implication to downloading information. Downloading Ruby without SSL leaks information about the client performing the download through request headers, and informs anyone watching the connection what version of Ruby is likely to be running on the downloading machine. In addition, traffic can be correlated in unpredictable ways: for example, a user agent sent to connect to a download of a Ruby build may appear later to download other information, providing a pattern of client behavior.

In any case, the web is, in general, moving to favor encrypted connections. SSL is faster, CAs like SSLMate and Let's Encrypt are emerging to make the process simpler, and web browsers are starting to encourage encrypted connections and discourage unencrypted ones. 

I request that the Ruby team:

* install a valid certificate on cache.ruby-lang.org.
* update any links to cache.ruby-lang.org controlled by the Ruby team to use the https:// version.
* notify the community of the SSL availability with a tiny announcement post.

Thank you for considering my request.



-- 
https://bugs.ruby-lang.org/

[ruby-core:69683] [Ruby trunk - Feature #10672] Enable SSL on cache.ruby-lang.org

[sparkyjg007]

Issue #10672 has been updated by JEFFREY GENERAO.


Hello Hiroshi,

I had sent in another ticket update for your request to add TLS to your Fastly domain cache.ruby-lang.org.

Please let me know how you'd like to proceed.

Best regards,

Jeff Generao
Fastly Customer Support

----------------------------------------
Feature #10672: Enable SSL on cache.ruby-lang.org
https://bugs.ruby-lang.org/issues/10672#change-53055

* Author: Eric Mill
* Status: Assigned
* Priority: Normal
* Assignee: Hiroshi SHIBATA
----------------------------------------
(I apologize if this is not the best place for this -- I'm happy to move this to a different place if it's more appropriate.)

Ruby's official distribution server, cache.ruby-lang.org, is not served over HTTPS. When accessing the server over HTTPS, it presents a certificate from Fastly that is invalid for the domain.

I strongly believe that downloads of public builds of Ruby should be secure, private, and resistant to tampering. HTTPS provides all of those properties.

Some clients, like ruby-build and rvm, use client-side hashes to verify build integrity. Not all clients or users will do this verification, and so baking it into the cache.ruby-lang.org server will ensure that a broader set of Ruby users has a secure, verified download of Ruby.

Even when clients do perform client-side integrity checking, there is always a privacy implication to downloading information. Downloading Ruby without SSL leaks information about the client performing the download through request headers, and informs anyone watching the connection what version of Ruby is likely to be running on the downloading machine. In addition, traffic can be correlated in unpredictable ways: for example, a user agent sent to connect to a download of a Ruby build may appear later to download other information, providing a pattern of client behavior.

In any case, the web is, in general, moving to favor encrypted connections. SSL is faster, CAs like SSLMate and Let's Encrypt are emerging to make the process simpler, and web browsers are starting to encourage encrypted connections and discourage unencrypted ones. 

I request that the Ruby team:

* install a valid certificate on cache.ruby-lang.org.
* update any links to cache.ruby-lang.org controlled by the Ruby team to use the https:// version.
* notify the community of the SSL availability with a tiny announcement post.

Thank you for considering my request.



-- 
https://bugs.ruby-lang.org/

[ruby-core:69846] [Ruby trunk - Feature #10672] [Closed] Enable SSL on cache.ruby-lang.org

[shibata.hiroshi]

Issue #10672 has been updated by Hiroshi SHIBATA.

Status changed from Assigned to Closed

I launched https CDN at 03/07/2015 JST. 
Please use https://cache.ruby-lang.org 

I appreciated fastly's suppot.

----------------------------------------
Feature #10672: Enable SSL on cache.ruby-lang.org
https://bugs.ruby-lang.org/issues/10672#change-53246

* Author: Eric Mill
* Status: Closed
* Priority: Normal
* Assignee: Hiroshi SHIBATA
----------------------------------------
(I apologize if this is not the best place for this -- I'm happy to move this to a different place if it's more appropriate.)

Ruby's official distribution server, cache.ruby-lang.org, is not served over HTTPS. When accessing the server over HTTPS, it presents a certificate from Fastly that is invalid for the domain.

I strongly believe that downloads of public builds of Ruby should be secure, private, and resistant to tampering. HTTPS provides all of those properties.

Some clients, like ruby-build and rvm, use client-side hashes to verify build integrity. Not all clients or users will do this verification, and so baking it into the cache.ruby-lang.org server will ensure that a broader set of Ruby users has a secure, verified download of Ruby.

Even when clients do perform client-side integrity checking, there is always a privacy implication to downloading information. Downloading Ruby without SSL leaks information about the client performing the download through request headers, and informs anyone watching the connection what version of Ruby is likely to be running on the downloading machine. In addition, traffic can be correlated in unpredictable ways: for example, a user agent sent to connect to a download of a Ruby build may appear later to download other information, providing a pattern of client behavior.

In any case, the web is, in general, moving to favor encrypted connections. SSL is faster, CAs like SSLMate and Let's Encrypt are emerging to make the process simpler, and web browsers are starting to encourage encrypted connections and discourage unencrypted ones. 

I request that the Ruby team:

* install a valid certificate on cache.ruby-lang.org.
* update any links to cache.ruby-lang.org controlled by the Ruby team to use the https:// version.
* notify the community of the SSL availability with a tiny announcement post.

Thank you for considering my request.



-- 
https://bugs.ruby-lang.org/

[ruby-core:69866] [Ruby trunk - Feature #10672] Enable SSL on cache.ruby-lang.org

[eric]

Issue #10672 has been updated by Eric Mill.


This is really great, and addresses the hardest part of my request. Thank you to Fastly for supporting the open source Ruby project with TLS for cache.ruby-lang.org, and to the Ruby project for enabling it!

I'll move the latter part of my request -- to update ruby-lang.org to use the HTTPS links by default -- over to the GitHub repo for the website at https://github.com/ruby/www.ruby-lang.org/.

----------------------------------------
Feature #10672: Enable SSL on cache.ruby-lang.org
https://bugs.ruby-lang.org/issues/10672#change-53270

* Author: Eric Mill
* Status: Closed
* Priority: Normal
* Assignee: Hiroshi SHIBATA
----------------------------------------
(I apologize if this is not the best place for this -- I'm happy to move this to a different place if it's more appropriate.)

Ruby's official distribution server, cache.ruby-lang.org, is not served over HTTPS. When accessing the server over HTTPS, it presents a certificate from Fastly that is invalid for the domain.

I strongly believe that downloads of public builds of Ruby should be secure, private, and resistant to tampering. HTTPS provides all of those properties.

Some clients, like ruby-build and rvm, use client-side hashes to verify build integrity. Not all clients or users will do this verification, and so baking it into the cache.ruby-lang.org server will ensure that a broader set of Ruby users has a secure, verified download of Ruby.

Even when clients do perform client-side integrity checking, there is always a privacy implication to downloading information. Downloading Ruby without SSL leaks information about the client performing the download through request headers, and informs anyone watching the connection what version of Ruby is likely to be running on the downloading machine. In addition, traffic can be correlated in unpredictable ways: for example, a user agent sent to connect to a download of a Ruby build may appear later to download other information, providing a pattern of client behavior.

In any case, the web is, in general, moving to favor encrypted connections. SSL is faster, CAs like SSLMate and Let's Encrypt are emerging to make the process simpler, and web browsers are starting to encourage encrypted connections and discourage unencrypted ones. 

I request that the Ruby team:

* install a valid certificate on cache.ruby-lang.org.
* update any links to cache.ruby-lang.org controlled by the Ruby team to use the https:// version.
* notify the community of the SSL availability with a tiny announcement post.

Thank you for considering my request.



-- 
https://bugs.ruby-lang.org/