On Tue Feb 04 20:31:49 2014, dvanliere wrote:

Forward secrecy is a property of key-agreement protocols that ensures
that a
session key derived from a set of long-term keys will not be
compromised if one
of the long-term keys is compromised in the future.

This ticket tracks the progress towards this elusive goal.

Indeed elusive it is. So FS is a difficult target given the current state of things. It is a property of Diffie-Hellman key exchanges. It differs slightly from Perfect Forward Secrecy in that in FS every conversation (connection) is encrypted with a different session key while in PFS every message is encrypted with a different session key. This difference means PFS is much more demanding and as such makes sense only using Elliptic Curve cryptography. There already is a page in wikitech for this and other https related work, so I will not recap that, but merely post the link:
https://wikitech.wikimedia.org/wiki/HTTPS/Future_work

Status changed from 'new' to 'open' by RT_System

"
In the nutshell, these are some of the suites you might want to enable3 and
push (close) to the top:
* TLS_ECDHE_RSA_WITH_RC4_128_SHA
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
* TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
* TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
https://www.ssllabs.com/ssltest/analyze.html?d=en.wikipedia.org
https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy
But i know Ryan has definitely had his reasons not to do it in the past
already, and there is a Bugzilla for this too afair

Reference to ticket #2517 added by dzahn

dvanliere wrote:

Relevant bugzilla ticket: https://bugzilla.wikimedia.org/show_bug.cgi?id=53259

Bugzilla ticket 53259 added by dzahn

Reference by ticket #7281 added by dzahn

Reference by ticket #7534 added by fgiunchedi

this ticket may be a bit general, if it's asking to support that on the actual
nginx prod cluster for the wikis it's a different story than supporting it on
misc. servers like Bugzilla and others

On Tue May 20 14:35:09 2014, dzahn wrote:

this ticket may be a bit general, if it's asking to support that on
the actual
nginx prod cluster for the wikis it's a different story than
supporting it on
misc. servers like Bugzilla and others

we have deployed PFS on the wikis some weeks ago:
https://www.ssllabs.com/ssltest/analyze.html?d=en.wikipedia.org
feels like this can be resolved?
Cipher Suites (SSL 3 suites in server-preferred order; deprecated and SSL 2
suites always at the end)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH 256 bits (eq. 3072 bits
RSA) FS
128
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH 256 bits (eq. 3072 bits
RSA) FS
256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH 256 bits (eq. 3072 bits
RSA) FS
128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH 256 bits (eq. 3072 bits RSA)
FS
128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH 256 bits (eq. 3072 bits
RSA) FS
256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH 256 bits (eq. 3072 bits RSA)
FS
256
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c)
128
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d)
256
TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) ECDH 256 bits (eq. 3072 bits RSA) FS
128
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)
128
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
128
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d)
256
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
256
TLS_RSA_WITH_RC4_128_SHA (0x5)
128
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x84)
256
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x41)
128

Issue taken by fgiunchedi

i think we can resolve it per Filippo's comment above. unless we want it to
also cover ALL misc. services. we did it where possible but some of them need
Apache 2.4 . chmarkine keeps track of it in a very nice HTML page
https://wikitech.wikimedia.org/wiki/User:Chmarkine/HTTPS

agreed, resolving

Status changed from 'open' to 'resolved' by fgiunchedi