Are Foundation servers able to withstand Online Certificate Status Protocol certificate revocations, such as might occur according to RFC 5280 when a government agency declares a private key compromised because of secret evidence?
I have been informed off-list that the answer to my question is no, and asked to open a phabricator task to allow for fail-over alternate certificate utilization in the case of revocations via OCSP or revocation list-based revocation.
I am strongly in favor of doing so, but I don't know how to categorize such a task or the group to assign it to. Any ideas?
On Sun, Jan 29, 2017 at 8:32 PM, James Salsman jsalsman@gmail.com wrote:
Are Foundation servers able to withstand Online Certificate Status Protocol certificate revocations, such as might occur according to RFC 5280 when a government agency declares a private key compromised because of secret evidence?
On Mon, Jan 30, 2017 at 10:06 AM, James Salsman jsalsman@gmail.com wrote:
I have been informed off-list that the answer to my question is no, and asked to open a phabricator task to allow for fail-over alternate certificate utilization in the case of revocations via OCSP or revocation list-based revocation.
I am strongly in favor of doing so, but I don't know how to categorize such a task or the group to assign it to. Any ideas?
The HTTPS tag (https://phabricator.wikimedia.org/project/profile/162/) and the Traffic component (https://phabricator.wikimedia.org/project/profile/1201/) would both seem reasonable.
Bryan
Bryan Davis wrote:
The HTTPS tag (https://phabricator.wikimedia.org/project/profile/162/) and the Traffic component (https://phabricator.wikimedia.org/project/profile/1201/) would both seem reasonable.
Thanks Brian, will do. I'm working on a fail-over method which won't allow the kind of MITM attacks which WhatsApp is vulnerable to under default settings. In the mean time, the White House web site apparently has a certificate which was working last week but now indicates it was revoked last May:
https://crt.sh/?q=60a5d3648459f4eb88700db0d08cda7f6139359c
Would it be a good idea to have HTTP ready to go in case HTTPS becomes unstable?
On Mon, Jan 30, 2017 at 10:06 AM, James Salsman jsalsman@gmail.com wrote:
I have been informed off-list that the answer to my question is no, and asked to open a phabricator task to allow for fail-over alternate certificate utilization in the case of revocations via OCSP or revocation list-based revocation.
I am strongly in favor of doing so, but I don't know how to categorize such a task or the group to assign it to. Any ideas?
On Sun, Jan 29, 2017 at 8:32 PM, James Salsman jsalsman@gmail.com wrote:
Are Foundation servers able to withstand Online Certificate Status Protocol certificate revocations, such as might occur according to RFC 5280 when a government agency declares a private key compromised because of secret evidence?
On Thursday, February 2, 2017, James Salsman jsalsman@gmail.com wrote:
Bryan Davis wrote:
The HTTPS tag (https://phabricator.wikimedia.org/project/profile/162/) and the Traffic component (https://phabricator.wikimedia.org/project/profile/1201/) would both seem reasonable.
Thanks Brian, will do. I'm working on a fail-over method which won't allow the kind of MITM attacks which WhatsApp is vulnerable to under default settings. In the mean time, the White House web site apparently has a certificate which was working last week but now indicates it was revoked last May:
https://crt.sh/?q=60a5d3648459f4eb88700db0d08cda7f6139359c
Would it be a good idea to have HTTP ready to go in case HTTPS becomes
unstable?
No. We are comitted to https due to hsts. It is not something that can just be turned off without downtime.
Also im pretty sure we already have redundant certificates ready to go in case of a revokation incident since its (accidentally) happened in the past. (See https://phabricator.wikimedia.org/T148131 and https://wikitech.wikimedia.org/wiki/Incident_documentation/20161013-GlobalSi... for the original context).
Last of all, the whatsapp key changing issue is not relavent to us. Whatsapp is using a different trust model than web pki does. -- bawolff
wikitech-l@lists.wikimedia.org