Securedrop: Update Apache/AppArmor rules to follow updated process to prove .onion ownership to CA

[integratedderivative]

Bug

Update Apache/AppArmor rules to follow updated process to prove .onion ownership to CA.

Description

Our documentation does a fine job documenting the process to obtaining and installing an HTTPS EV cert to the source interface, and thanks to #2603 (fixing #2602) we now have some logic to allow an admin to add arbitrary .htm or .html files to a specific directory .well-known/.

However, recently an admin reported to the team that DigiCert, a CV that provides EV certs for .onion URLs, has recently changed their validation steps.

Here's an excerpt from a support email to this admin (specific details redacted):

To confirm you have control of the following domains, we need you to set up a web page at each url listed that we can access. Each page should contain the provided token.

domain: [source interface onion]
url: [source interface onion]/.well-known/pki-validation/[string].txt
token: [token]

Where _[token]_ and _[string].txt appear to be different hashes.

Thus, we need to update Apache and AppArmor rules to:

1. Allow an admin to create a directory called pki-validation/ within .well-known (so .well-known/pki-validaton/)
2. Put an arbitrary .txt file, and
3. Serve that file so a CA may check that the admin does indeed own the .onion URL

Steps to Reproduce

1. Be a SecureDrop Admin with an .onion
2. Buy a fancy EV cert for said .onion
3. Notice that the instructions sent to you differ from the SecureDrop documentation
4. Fail to create a pki-validation directory and put an arbitrary .txt file in said directory

Expected Behavior

An admin would expect to follow the CA's documentation and be able to create a pki-validation directory, insert a .txt file, and serve it to the CA, as directed.

Actual Behavior

Literally nothing, as one can't serve a file to a CA to prove ownership. The CA gets sad, the admin gets sad, and we get sad. Fancy and pricey EV certs go unused.

Comments

I am not an expert in AppArmor rules, but looking at #2603, it _appears_ to be a relatively "trivial" fix. Perhaps a competent Ops person can fix? :)

[Anonymous26]

I would like to work on this issue.

[ghost]

@Anonymous26 consider yourself assigned to this issue :-) Thanks for volunteering !

[integratedderivative]

Thanks, @Anonymous26! Thank you very much for taking this on! Much appreciated.

[jcurrutia]

Please, someone help me with this issue.
JC

[redshiftzero]

Hi @Anonymous26 - did you get a chance to look at this?

Apologies for the delay @jcurrutia, we'll see if we can get a fix for this out.

[Anonymous26]

@redshiftzero I'm really sorry I totally forgot about this issue, this won't happen again.

[conorsch]

Thanks for following up, @Anonymous26. Glad to have you involved in future work—we wanted to make sure the fix got out in the upcoming release, and we're on track for that.

[redshiftzero]

No worries @Anonymous26 :)

[redshiftzero]

Hey @jcurrutia - we have a fix for this now (#3116, #3118) which will be released in SecureDrop 0.6 on Tuesday, March 13th. After that date, you'll be able to prove .onion ownership to Digicert, but let us know if you encounter any other problems.