Upload S3 incompatibili con la crittografia lato server

Bug
1

Sto cercando di migrare un server Discourse esistente in un nuovo ambiente basato su AWS, memorizzando gli upload in S3 in un bucket che utilizza la crittografia lato server con chiavi gestite dal cliente (SSE-C). Durante il processo di ripristino, gli upload non vengono inseriti in S3: ogni singolo upload fallisce. Con un uso giudizioso del debug tap|p, ho scoperto che l’upload viene effettuato, ma la validazione dell’etag restituito fallisce perché l’etag restituito da S3 dopo l’upload è diverso ogni volta. Ad esempio, questo è il valore restituito dalla chiamata put_object in due diversi tentativi di ripristino:

# Esecuzione 1
#<struct Aws::S3::Types::PutObjectOutput expiration=nil, etag="\"d49ec2006cfd6fe957af2f711edd9a4b\"", checksum_crc32=nil, checksum_crc32c=nil, checksum_sha1=nil, checksum_sha256=nil, server_side_encryption="aws:kms", version_id="xAF23wQ.zwpoxVmmGiTjxfX0svMZbHAe", sse_customer_algorithm=nil, sse_customer_key_md5=nil, ssekms_key_id="**redacted**", ssekms_encryption_context=nil, bucket_key_enabled=true, request_charged=nil>

# Esecuzione 2:
#<struct Aws::S3::Types::PutObjectOutput expiration=nil, etag="\"05edffee421c6aef950b3d4418ada293\"", checksum_crc32=nil, checksum_crc32c=nil, checksum_sha1=nil, checksum_sha256=nil, server_side_encryption="aws:kms", version_id="H2_8SVh.Yx2LKB4GIjhyPbVoj_.Vc1E2", sse_customer_algorithm=nil, sse_customer_key_md5=nil, ssekms_key_id="**redacted**", ssekms_encryption_context=nil, bucket_key_enabled=true, request_charged=nil>

(So che si tratta degli stessi file perché sto anche stampando la somma MD5 lato client e le opzioni di richiesta put_object, che includono il nome del file)

Si scopre che l’intestazione della risposta ETag si comporta… diversamente quando si utilizza SSE-C:

Gli oggetti crittografati con chiavi fornite dal cliente (SSE-C) o chiavi AWS Key Management Service (AWS KMS) (SSE-KMS) hanno ETags che non sono un digest MD5 dei loro dati oggetto.

L’unico modo che trovo per verificare l’integrità degli upload con SSE-C è inviare l’intestazione della richiesta Content-MD5, e lasciare che S3 faccia il rilevamento delle corruzioni. Si noti anche che il controllo “già caricato” si interromperà anche quando si utilizza SSE-C, ma almeno quello può essere disabilitato utilizzando SKIP_ETAG_VERIFY.

Non sto inviando una PR immediatamente perché ci sono due modi diversi per affrontare questo problema:

  1. estendere semplicemente SKIP_ETAG_VERIFY per includere la verifica post-upload, che è economica e una soluzione rapida, e richiede agli utenti di sapere che il loro uso di SSE-C significa che dovranno attivarla; o
  2. passare all’uso dell’intestazione Content-MD5 (preferibilmente sempre) per la protezione dell’integrità dell’upload, che ha il vantaggio di funzionare per tutti, al costo di una PR molto più ampia.

(Come nota a margine, sono piuttosto turbato dal fatto che nessuno abbia riscontrato questo problema prima: nessuno sta usando Discourse con SSE-C per gli upload???)

4 Mi Piace
2

La mia ipotesi è che “caricamenti sicuri” venga utilizzato solo in casi molto specifici, il che fa sì che il 99,8% di tutti i caricamenti vengano comunque serviti pubblicamente, il che rende inutile qualsiasi tipo di crittografia a riposo?

4

Non stai sbagliando, Matt, per quanto ne so è la prima volta che viene sollevato questo problema.

Il (2) mi sembra l’approccio corretto, se riesci a farlo.

Altrimenti, immagino che non avrai la certezza che tutti i file siano presenti correttamente.

Una volta che avrai caricato tutti i file nel tuo bucket S3, l’operatività generale di Discourse sarà OK? Sono necessarie altre modifiche per l’uso quotidiano (penso a cose come l’inventario che potrebbe rompersi, forse sono necessarie modifiche per gli URL pre-firmati, ecc.)?

5 Mi Piace
5

Proverò a farlo. Per fortuna, trovare ovunque venga menzionato “etag” dovrebbe essere sufficiente per individuare tutte le posizioni del codice che necessitano di modifiche, e la suite di test è ben organizzata in modo da poter trovare facilmente ciò che deve essere eseguito e modificato.

Per quanto riguarda altre cose che potrebbero rompersi, non sono ancora riuscito a ottenere un sito funzionante e continuerò a segnalare/inviare PR man mano che procedo. L’inventario non dovrebbe rompersi, perché solo il contenuto del file viene crittografato, non i nomi. Probabilmente non scoprirò se gli URL pre-firmati si romperanno, poiché non li sto utilizzando.

3 Mi Piace
6

Ho appena aperto questa PR che rimuove la verifica del caricamento basata su ETag durante la migrazione a S3. A quanto pare, viene utilizzata solo durante la migrazione a S3; durante il caricamento normale, viene semplicemente gestita con YOLO, il che mi ha reso la vita molto più facile. Con questa PR, e la PR per la disabilitazione delle impostazioni del sito ACL precedentemente inviata, ho ora un ripristino completato. Prossimo passo: testare le funzionalità.

6 Mi Piace
12

Penso che questo sia stato unito. :partying_face:

1 Mi Piace
13

Questo argomento è stato chiuso automaticamente dopo 2 giorni. Non sono più consentite nuove risposte.