È possibile avere un'API RESTful crittografata senza TLS? [chiuso]

1

Mi chiedevo se fosse possibile implementare un server che ha solo dati e autorizzazioni crittografati (quindi senza TLS che richiede anche l'autenticazione del certificato). Simile a SSH ma funziona con piattaforme di sviluppo di app per dispositivi mobili (iOS / Android / React Native / etc).

Modifica: Non vogliamo installare manualmente le chiavi su ciascun client né eseguire un'autorità di certificazione (CA) personalizzata. E la maggior parte dei dispositivi verrà eseguita su LAN privata utilizzando indirizzi IP riservati, pertanto le CA standard non emetteranno certificati poiché non è più consentito per gli indirizzi IP riservati. Questo è essenzialmente il problema emergente dell'IoT di avere trasferimenti di dati crittografati su reti private. Ma sembra che le piattaforme mobili comuni DEVONO utilizzare SSL / TLS per ottenere la crittografia. SSH andrebbe bene, tranne che non sembrano esserci buone soluzioni disponibili per piattaforme mobili come React Native, Nativescript, Ionic, ecc.

    
posta Jason 03.03.2017 - 00:55
fonte

3 risposte

3

Sì, è possibile. Ma perché lo faresti?

Tutte le piattaforme mobili supportano TLS, perché reinventare la ruota?

La crittografia è molto difficile da ottenere e facile da sbagliare. Se riesci a inventare una crittografia migliore rispetto ai ragazzi che scrivono il software TLS, non faresti questa domanda.

    
risposta data 03.03.2017 - 03:06
fonte
3

TLS non ti fornisce solo la crittografia. Ti dà autenticazione affidabile. Tutta la privacy nel mondo non importa se non sai con chi stai conversando in privato.

Senza una PKI e una CA sarebbe molto difficile implementare la propria forma di autenticazione sicura, a meno che non si desideri distribuire le chiavi in anticipo.

Quindi voterò "No", non è realmente possibile, a meno che tu non voglia fare molto lavoro.

    
risposta data 03.03.2017 - 04:46
fonte
1

È possibile, ma SSH in particolare potrebbe non essere un buon modello per questa applicazione in primo luogo.

SSH ha un approccio TOFU (Trust On First Use), che richiede all'utente di decidere se accettare o meno la chiave di un server alla prima connessione. TLS, in confronto, ha mezzi (certamente imperfetti) per cercare di determinare se una data chiave può essere ragionevolmente accettata per identificare un server. Solo se viene trovato qualcosa di insolito (ad esempio certificato autofirmato, cert non corrispondente / scaduto / non valido, ecc.) All'utente viene chiesto di pensare (e vi sono molte prove che il pensiero viene sostituito semplicemente facendo clic su OK senza leggere il messaggio).

In altre parole, è necessario che entrambi si fidino dei propri utenti e si assumano che siano in grado di prendere decisioni informate quando vengono presentati con un'associazione di fiducia. L'altro richiede di utilizzare un sistema imperfetto ma ben consolidato, e per lo più funzionale, per stabilire tale fiducia.

Un altro fattore è il fatto che la tua configurazione suona molto come se avessi una singola chiave di crittografia per i client che inviano i tuoi dati. Il che significa che, in assenza di TLS, chiunque disponga di tale chiave (ad esempio estraendolo dalla tua app) può decrittografare TUTTO il traffico inviato alla tua API. TLS risolve anche quello per te.

Potresti affermare che avresti le chiavi per client, ma che:

  • ha bisogno di gestire
  • richiede che le chiavi siano condivise in qualche modo
  • e presumibilmente, richiede che gli utenti siano in grado di comunicare con te senza crittografia ...

tl; dr : Possibile, ma anche se hai trovato un modo perfetto per fare tutto questo correttamente, avresti comunque un caso d'uso convincente per TLS per coprire tutti i tipi di edge (e molto probabilmente casi principali).

    
risposta data 03.03.2017 - 13:37
fonte

Leggi altre domande sui tag