Changes between Initial Version and Version 1 of https-for-all


Ignore:
Timestamp:
Apr 11, 2012, 2:19:44 AM (9 years ago)
Author:
Daniel Kahn Gillmor
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • https-for-all

    v1 v1  
     1[[PageOutline]]
     2= HTTPS for all MF/PL members =
     3
     4Every website hosted by MF/PL should provide HTTPS access.  It should also be simple for members to update their web site to require HTTPS.
     5
     6[ticket:5561 This is a work in progress].  This documentation is for server administrators to understand what's going on.  Regular MF/PL members shouldn't need to learn these details (but i'm happy if they want to!)
     7
     8== canonical key, certificate, and CSR locations on MOSHes ==
     9
     10Each MOSH should have a separate key for each web site it hosts.  Those keys should be stored in a predictable place.  The active X.509 certificate associated with that key should also be stored in a reasonable place, as should any needed intermediate certificates.  The MOSH should also be willing to createa reasonable CSR for any web site it controls and make that CSR available to the member.
     11
     12I propose the following locations, all derived from the numeric ID of the red "web configuration" object, represented here as WEBID:
     13
     14 secret key:: `/etc/ssl/private/member_keys/WEBID.key`
     15 server certificate (cert):: `/etc/ssl/member_certs/WEBID_cert.pem`
     16 certificate signing request (CSR):: `/etc/ssl/member_csrs/WEBID.csr`
     17 intermediate CA certs (iCAs):: `/etc/ssl/member_certs/WEBID_intermediates.pem`
     18 backups:: Automatically backed-up files would go in `/etc/ssl/mfpl-backups/` and would have the timestamp (to 1Hz precision, ISO-8601 format) of the backup prefixed to their name with a dot (e.g. `/etc/ssl/mfpl-backups/2012-05-23_03:32:55.WEBID_cert.pem`)
     19
     20A mosh would examine its list of active web configurations from red.  for each webconfig WC, with numeric ID WEBID, it would scan these files for trouble, creating or generating them as needed.
     21
     22=== Secret key ===
     23Creation:
     24 * create the file, ownership root:root, mode 0400
     25 * if apache config stanza contains [https://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslcertificatekeyfile SSLCertificateKeyFile], copy the contents from there.
     26 * otherwise, generate and store a 2048-bit RSA key, no passphrase
     27
     28Mandatory checks:
     29 * permission should be 0400, owned by root (otherwise: report an error and fix the ownership and mode)
     30 * must parse as a valid PEM-encoded, passphraseless secret key (otherwise: backup and regenerate)
     31
     32Optional checks:
     33 * the secret key should be RSA, 2048 bits (otherwise: report an error)
     34
     35=== Server Certificate ===
     36Creation:
     37 * create the file, ownership root:root, mode 0400
     38 * if apache config stanza contains [https://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslcertificatefile SSLCertificateFile], copy the contents from there.
     39 * if the red web configuration object contains a blob for the Server Certificate, verify the cert against the mandatory checks below, and place the blob's contents into the file if they pass (report an error if they don't all pass).
     40 * generate and store a self-signed cert from the secret key with a Subject of CN=ServerName, and subjectAltName extensions of dNSNames pointing to ServerName and every ServerAlias.
     41
     42Mandatory checks (unless otherwise noted, if these checks fail, the certificate should be backed up and replaced with a re-generated self-signed cert):
     43 * owned by root, mode 0444 (otherwise: report an error and fix the ownership and mode)
     44 * must parse as a single PEM-encoded X.509 certificate
     45 * the public key contained in the cert should match the public key of the secret key
     46 * the cert's Subject should have a leaf CN that matches the web configuration's ServerName directive
     47 * the cert's X.509v3 extensions should include a subjectAltName field of type dNSName that matches the web configuration's ServerName directive
     48 * the cert's creation date should be in the past.
     49 * the cert's certificateKeyUsage must include Signing and Key Encipherment
     50 * the cert's extendedKeyUsage must include TLS Web Server Authentication (OID 1.3.6.1.5.5.7.3.1)
     51
     52Optional checks:
     53 * the cert's X.509v3 extensions should include a subjectAltName field of type dNSName that matches each of the items in the web configuration's ServerAlias directive. (otherwise: one-time warning?  we don't want to hassle people about example.mayfirst.org not being included in a cartel-issued cert)
     54 * the cert's expiration date should be in the future (otherwise: warning)
     55 * OCSP/CRL checking?
     56
     57=== Certificate Signing Request ===
     58Creation:
     59 * generate and store a CSR with:
     60  * DN of `/CN=ServerName/`
     61  * subjectAltName extensions of dNSNames pointing to ServerName and every ServerAlias
     62  * certificateKeyUsage includes Signing and Key Encipherment
     63  * extendedKeyUsage of TLS Web Server Authenicatiyon (OID 1.3.6.1.5.5.7.3.1)
     64
     65Mandatory checks (if any of these checks fail, the CSR should be backed up and replaced with a re-generated CSR):
     66 * the public key contained in the CSR should match the public key of the secret key
     67 * the CSR's Subject should have a leaf CN that matches the web configuration's ServerName directive
     68 * the CSR's X.509v3 extensions should include a subjectAltName field of type dNSName that matches the web configuration's ServerName directive
     69 * the CSR's creation date should be no older than 1 year ago
     70 * the CSR's creation date should be in the past.
     71
     72=== Intermediate CA certificates ===
     73Creation:
     74 * if apache config stanza contains [https://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslcertificatechainfile SSLCertificateChainFile], copy the contents from there.
     75
     76Mandatory checks (if any of these fail, report an error, back the file up, and truncate it to zero length):
     77 * must be a list of 0 or more PEM-encoded CAs
     78 * must start with a CA certifying the Server Certificate
     79 * each subsequent CA must certify the CA before it
     80
     81Optional checks (report an error):
     82 * Must not include any self-signed certificates
     83
     84== mosh server changes ==
     85
     86Perhaps we want to expose `/etc/ssl/member_csrs` directly to the web under the mosh's canonical hostname?  That way we could link to them directly (or include them in an iframe) in the control panel's web UI.
     87
     88== red changes ==
     89
     90Once the above files are populated on every server, we need to change red's web configuration items:
     91
     92 * SSLCertificate* directives should not be allowed in the apache stanza, but should be auto-generated for https web configs
     93 * SSLEngine directive should not be allowed in the apache stanza, but should be auto-generated for https web configs
     94 * display of a web configuration item should include a link or iframe containing the CSR
     95 * editing a web configuration should add a textarea for pasting in a Server Certificate
     96 * update of an apache config stanza should cause the above checks to be run on the node for the modified web configuration
     97
     98If the above can all happen smoothly, the next steps would be:
     99
     100 * remove the http/https option for the web configuration object
     101 * auto-generate duplicate apache stanzas from web configuration object: one for port 80, one for port 443.
     102 * port 443 stanza should include additional `SSLEngine On` and SSLCertificate* directives.
     103 * add new "https" dropdown, with three options: enabled, enforced, permanent (see below for meaning)
     104
     105=== new HTTPS option ===
     106this new option for the web configuration object should have three states:
     107
     108  enabled:: normal port 80 config stanza
     109  enforced:: port 80 stanza retains only ServerName and ServerAlias options from apache config, adds auto-generated mod_rewrite rules to send the user's browser to `https://$ServerName`
     110  permanent:: as with "enforced", but also adds a Strict-Transport-Security header with a 6-month duration
     111
     112== Toolchain ==
     113
     114At the moment, i lean toward perl as the language to do this in.  I have no idea how to integrate that cleanly with red.
     115
     116== Status ==
     117
     118None of this is implemented yet, alas.
     119
     120== Unhandled Scenarios/future work ==
     121
     122As of yet, there are a few corner cases this scheme doesn't permit.
     123
     124=== CSRs that need to embed a challenge ===
     125
     126I have yet to encounter a reasonably-priced CA that requires these for certificate issuance
     127
     128=== Wildcard Certs ===
     129
     130Maybe we can handle this as a special case?  How many of these do we currently support on moshes?
     131
     132=== sites with multiple, non-wildcard names that want distinct certs ===
     133
     134I don't think we should even try to support this use case.  The member can simply make a new web config in this scenario.
     135
     136=== Embedding OpenPGP indicators ===
     137
     138It's not clear to me whether the auto-generated certificates and CSRs should contain the [http://www.imc.org/ietf-openpgp/mail-archive/msg05320.html PGPExtension] or [https://lists.riseup.net/www/arc/monkeysphere/2011-03/msg00027.html the NullSignatureUseOpenPGP extension].  Doing so would be a nice way to extend monkeysphere access on all MF/PL machines, though.
     139
     140=== using MF/PL CA for initial Server Certificates ===
     141
     142We don't need to just use self-signed certs for the initial setup; we could also sign them with the MF/PL CA, or with a subordinate CA for that purpose.