JakeHillion/storj
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Linksharing TLS Support Testplan (#5448)

Browse Source 
Testplan for pro account only Linksharing TLS

Co-authored-by: Antonio Franco (He/Him) <antonio@storj.io>
This commit is contained in:
nadimhq 2023-04-20 09:31:54 -04:00 committed by GitHub
parent 19e9ca921a
commit 78029ec3fb
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 31 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
docs/testplan/linksharing-tls-support.md Normal file
View File

@ -0,0 +1,31 @@
# Linksharing TLS Support Testplan
&nbsp;
## Background
This testplan is going to cover our secure custom domain support for Linksharing. It will go over the linksharing secure custom domain support blueprint - [Paid Tier TLS](https://github.com/storj/storj/blob/main/docs/blueprints/paid-tier-tls.md)
&nbsp;
&nbsp;
Test Scenario | Test Case | Description | Comments
-- | -- | -- | --
General | Pro Account Only | Only pro accounts should be able to use Linksharing TLS |  
| | HTTPS Support | Storj linksharing Service should support HTTPS for custom domains
  | Host TLS certificates | Linksharing server should host TLS certificates generated by Storj on behalf of our customers (CertMagic: storage backend for storing certificates) |  
  | Certificate Generation | Storj should generate certificates on behalf of users if users have a way to prove ownership of domain to generate said certificate |  
  | Custom Domain URL | Linksharing URLs generated w/ custom domain should also have an additional URL that contains said custom domain | this should be automated as its one of the requirements of the customers; they want/need to have a custom domain that is secured with TLS for their content
  | BYO Certificate | (In the future) customers should be able to bring their own certificate rather than rely on our generated certificate, so they should be allowed to upload their said certificate | OUT OF SCOPE
  | uplink CLI share request | Customer should be able to make a share request with uplink CLI and be able to update their DNS info w/ output from uplink cli |  
  | Share Access 1 | When a share is accessed, linksharing should load the certificate matching the SNI and should attempt to connect said hostname at the start of the handshake |  
  | Share Access 2 | Once trying to connect to hostname, linksharing should check for certificate in the cache first and then if it is not there it will check the store |  
  | Valid/Invalid Handshake | If the certificate doesn't exist in the store and the CNAME is valid, then there should be a request for a certificate store domain-lock else this is an invalid handshake and handshake fails/request is dropped |  
  | Successful domain-lock | If the domain-lock succeeds, then the certificate should be requested and the certificate validation process should run afterwards with the new certificate being added to the store |  
  | Multiple Request on domain-lock | When requesting a certificate, additional requests made to the instance holding the lock can be held while the certificate is issued |  
Migration Impact | Valid Certificate Return | After the migration, existing customers migrated to TLS custom domains should receive a valid cert whenever there is an https request for custom domains |  
  | Warning For HTTPS Support | After TLS custom domain migration, if a customer uses https only mode enabled there should be no warning stating that the site doesn't support HTTPS |  
  | Opt-in TLS Custom Domains | Customers should be allowed to opt-in to TLS custom domains during initial rollouts (to work out potential issues) and should not be enabled by default | this eliminates edge-case described by Paul (if a customer uses a proxy service to use https and expect the self-signed cert serving a valid cert instead could cause an outage) in his research on how existing customers would be impacted when migrated to custom TLS domains
Certificates | Storing | Certificates should only be stored in one private Storj controlled DCS bucket and said bucket should share certificates and other TLS resources needed for the challenges between all linksharing instances |  
  | On-access Renewal | If a certificate expires in less than 30 days and it is accessed, it should then be renewed & if it doesn't expire in less than 30 days it should not be renewed on access |  
  | Expired Certificate | If a certificate expires before it is accessed or after is it accessed for a set time (30 days), then it should be reissued on next access since it will be in process for garbage collection |