Le chiavi API utente dovrebbero usare l'padding OAEP

Funzionalità
1

Un problema minore e forse uno più grande:

C’è un parametro nonce obbligatorio che non è menzionato nella documentazione:

  def require_params
    %i[public_key nonce scopes client_id application_name].each { |p| params.require(p) }
  end

Ora il problema più complicato. Discourse chiama il metodo public_encrypt senza argomenti:

Ciò significa che l’argomento padding viene impostato di default su PKCS1_PADDING. Dalla documentazione Ruby:

Cifra string con la chiave pubblica. padding è di default su PKCS1_PADDING, che è noto per essere insicuro ma viene mantenuto per compatibilità con le versioni precedenti.

Sfortunatamente, Node v20.14.0 (l’attuale LTS) restituisce un errore se si tenta di chiamare crypto.privateDecrypt con RSA_PKCS1_PADDING:

function decryptData(data: string, privateKey: string) {
  const buffer = Buffer.from(data, "base64");
  const decrypted = crypto.privateDecrypt(
    {
      key: privateKey,
      padding: crypto.constants.RSA_PKCS1_PADDING,
    },
    buffer
  );
  return decrypted.toString("utf8");
}

TypeError: RSA_PKCS1_PADDING non è più supportato per la decrittazione privata, questo può essere ripristinato con --security-revert=CVE-2023-46809

Una possibile soluzione per le app Node è eseguire Node con il flag insicuro:

node --security-revert=CVE-2023-46809

Una soluzione lato Discourse sarebbe facile, ma sospetto che romperebbe molte integrazioni esistenti:

public_key = OpenSSL::PKey::RSA.new(params[:public_key])
@payload = Base64.encode64(public_key.public_encrypt(@payload, OpenSSL::PKey::RSA::PKCS1_OAEP_PADDING))
3 Mi Piace
2

@simon Sì, questo sta decisamente causando problemi con Node v22. Sarebbe fantastico non dover ripristinare le patch di sicurezza. Sarebbe bello impostare un flag nella chiamata API o un’impostazione del sito in Discourse per scegliere il padding desiderato. (In questo modo le persone possono mantenere l’impostazione predefinita esistente, se lo desiderano.)

1 Mi Piace
3

Seguendo approssimativamente i passaggi qui, NodeRSA funziona

4

Sembra un’aggiunta piuttosto semplice?

5

Capisco che OAEP sia raccomandato per le nuove applicazioni che sono resistenti agli attacchi CCA / Bleichenbach. È un po’ triste che Node ci stia costringendo, ma immagino sia una cosa del tipo “bene superiore”.

Sono estremamente preoccupato di rendere questa un’altra opzione per un amministratore di Discourse a cui pensare, è un incubo.

Invece, dovremmo correggere Discourse Hub per supportare contemporaneamente le vecchie e le nuove versioni, avere qualcosa sulla nostra API che segnali la “versione” della chiave pubblica.

È un cambiamento complicato che attraversa diversi sistemi. La correzione che hai proposto è un problema perché Discourse Hub smetterà di funzionare per gli amministratori che passeranno a quella modalità.

3 Mi Piace
7

Grazie per il contesto aggiuntivo.

Per essere chiari, questa è una cosa con cui ho problemi durante lo sviluppo locale. Ma quando ci si collega alle nostre risorse distribuite su istanze AWS EC2, non è un problema. Suppongo che la loro versione di Node abbia alcune personalizzazioni o versioni di sottofondo in cui la libreria crypto non presenta questo problema.

8

Arrivo a freddo ma quell’errore sembra errato. Questa non è una funzionalità rimossa in Node, è un problema con alcune installazioni di OpenSSL. Dalla documentazione di Node:

L'uso di crypto.constants.RSA_PKCS1_PADDING in crypto.privateDecrypt() richiede che OpenSSL supporti il rifiuto implicito (rsa_pkcs1_implicit_rejection).

Vedi anche [Bug]: RSA_PKCS1_PADDING is no longer supported for private decryption · Issue #487 · bropat/eufy-security-client · GitHub

Testando localmente, questo funziona per me: An example of RSA Encryption implemented in Node.js · GitHub anche quando passo all’uso di crypto.constants.RSA_PKCS1_PADDING per il padding sia per la crittografia che per la decrittografia. Sono su OpenSSL 3.4.0 e Node 23.6.1.

La cosa complicata nell’usare un’impostazione del sito è che i client non sapranno quale padding la specifica istanza supporta. Ciò rende la compatibilità tra istanze/servizi più difficile da comprendere.

Penso che dovremmo chiarire l’implementazione esistente, cioè notare esplicitamente che stiamo usando RSA_PKCS1_PADDING e poi pensare a un aggiornamento. Forse dobbiamo introdurre il versionamento per questo endpoint, in modo che i client possano utilizzare correttamente il padding giusto prima/dopo tale versione.

2 Mi Piace
9

Per contesto, questa non è una richiesta di funzionalità da parte mia, è solo un’osservazione che ho fatto a giugno dello scorso anno.

2 Mi Piace