View Full Version : [C#] Sicurezza nelle comunicazioni Client/Server - SOAP o RESTFull API
Salve,
devo sviluppare un progetto Client/Server in C#, vi spiego:
Diciamo che ho 500 PC-Client i quali devono inviare e ricevere piccole comunicazioni al Server, pochi byte a comunicazione.
Nei Client gira Windows 10 IoT Enterprise, Il software è un applicazione Win Form in C#, per l'interfaccia grafica.
La connessione dei Client è fatta con una normalissima ADSL - (IP Dinamico).
Il Server è in PC ospitato in Housing(Aruba) dove gira Windows.
In queste comunicazioni il Client invia al Server anche dati di carte di credito, dove nel Server si effettuano le transazioni bancarie tramite le API del sistema di pagamento.
Il punto è:
- serve una connessione sicura
- serve una comunicazione cifrata
- serve identificare la comunicazione per sapere se ha il permesso di entrare.
Inizialmente per soddisfare quei punti avevo pensato ad un Web Service SOAP.
Poi mi sono documentato sulle API RESTFull
Ora non sono deciso su come procedere.
Cosa ne pensate?
pabloski
15-05-2018, 11:14
REST o SOAP, il punto è che quella roba dev'essere cifrata e dev'esserci un meccanismo per la verifica delle identità.
Per l'identificazione si può usare la crittografia a chiave asimmetrica, cioè usarla durante la prima connessione della sessione, per poi assegnare una chiave simmetrica ai client.
Quello che avviene con https in pratica.
REST o SOAP, il punto è che quella roba dev'essere cifrata e dev'esserci un meccanismo per la verifica delle identità.
Per l'identificazione si può usare la crittografia a chiave asimmetrica, cioè usarla durante la prima connessione della sessione, per poi assegnare una chiave simmetrica ai client.
Quello che avviene con https in pratica.
+1
imho la soluzione migliore è fare delle web api su protocollo https così per la sicurezza ti affidi a tls
REST o SOAP, il punto è che quella roba dev'essere cifrata e dev'esserci un meccanismo per la verifica delle identità.
Per l'identificazione si può usare la crittografia a chiave asimmetrica, cioè usarla durante la prima connessione della sessione, per poi assegnare una chiave simmetrica ai client.
Quello che avviene con https in pratica.
L'identità la faccio con il certificato del server, ma credo che come dici tu è più univoca, in caso di furto del Client anno pure il certificato per entrare...
+1
imho la soluzione migliore è fare delle web api su protocollo https così per la sicurezza ti affidi a tls
E' sufficiente comunicare su https ?
Dato che invio anche dati di carte di credito, non è meglio SOAP cosi cifro i dati inviati?
Il problema è questo, se riesco a capire che SOAP per la mia applicazione non è troppo pesante, vado con quello.
Come posso capire se è eccessivamente "Pesante" o "Lento", che calcoli devo fare?
Per lento si intende che risponde dopo 5 secondi.... o altro??
Per pesante si intende su una linea ADSL da 2Mb con 5 chiamate ogni 10 minuti..., o altro??
E' sufficiente comunicare su https ?
Dato che invio anche dati di carte di credito, non è meglio SOAP cosi cifro i dati inviati?
rest o soap non è che cambi un gran che lato dati puoi inviare dati cifrati anche su https facendo una cifratura a due livelli
https ti garantisce che la connessione avviene su un canale sicuro (scambio di chiavi simmetriche mediante protocollo asimmetrico ) poi i dati che mandi li gestisci come vuoi
es mando un json contenente i dati cifrati secondo un algoritmo simmetrico con chiave univoca per il client
rest o soap non è che cambi un gran che lato dati puoi inviare dati cifrati anche su https facendo una cifratura a due livelli
https ti garantisce che la connessione avviene su un canale sicuro (scambio di chiavi simmetriche mediante protocollo asimmetrico ) poi i dati che mandi li gestisci come vuoi
es mando un json contenente i dati cifrati secondo un algoritmo simmetrico con chiave univoca per il client
OK, chiarissimo, quindi tu sei più d'accordo a sviluppare il tutto con RESTFull API ?
OK, chiarissimo, quindi tu sei più d'accordo a sviluppare il tutto con RESTFull API ?
non è che sono d'accordo, non vedo particolari problemi lato sicurezza ad usare sia l'una che l'altra tecnologia.
la scelta del protocollo è più una questione architetturale e diventa difficile scegliere senza avere tutti gli elementi :D
non è che sono d'accordo, non vedo particolari problemi lato sicurezza ad usare sia l'una che l'altra tecnologia.
la scelta del protocollo è più una questione architetturale e diventa difficile scegliere senza avere tutti gli elementi :D
Ti chiedo solo un ultima cosa e poi chiudo,
Diciamo che REST inviando pochissimi byte ha la medesima velocità di una chiamata ad una pagina web,
Come posso capire quanta è la lentezza di SOAP??
Tutti dicono che è molto lento e inoltre ci vuole pure una banda adeguata...
Ma come è possibile che una ADSL da 1Mb non soddisfi la portata delle chiamate anche se sono 10 al secondo ??
Mi sta bene la lentezza di risposta che è dovuta all'elaborazione nel server, ma la banda adeguata!!!
Ti chiedo solo un ultima cosa e poi chiudo,
Diciamo che REST inviando pochissimi byte ha la medesima velocità di una chiamata ad una pagina web,
Come posso capire quanta è la lentezza di SOAP??
Tutti dicono che è molto lento e inoltre ci vuole pure una banda adeguata...
Ma come è possibile che una ADSL da 1Mb non soddisfi la portata delle chiamate anche se sono 10 al secondo ??
Mi sta bene la lentezza di risposta che è dovuta all'elaborazione nel server, ma la banda adeguata!!!
diciamo che rest e pochissimi byte non stanno bene nella stessa frase senza una negazione in mezzo :D
le api rest fanno chiamate http quindi il protocollo è abbastanza pesante e soap è abbastanza similare (protocollo testuale anche in soap json vs xml ma siamo li )
i protocolli leggeri sono altri ad esempio per iot si usa tanto mqtt :D
rest o soap non è che cambi un gran che lato dati puoi inviare dati cifrati anche su https facendo una cifratura a due livelli
https ti garantisce che la connessione avviene su un canale sicuro (scambio di chiavi simmetriche mediante protocollo asimmetrico ) poi i dati che mandi li gestisci come vuoi
es mando un json contenente i dati cifrati secondo un algoritmo simmetrico con chiave univoca per il client
Riprendo la tua risposta precedente e la lego all'ultima.
Se REST e SOPA diciamo che siamo li....., perchè non fare come mi hai detto qui nella QUOTE, niente SOAP e niente REST, un semplice invio di dati json cifrati e lato Server uno script che "accoglie, elabora e risponde" ai i dati inviati.
I miei invii sono roba tipo cosi:
"id=4d34g234hj&im=200&ty=50&q=42ui23i4234y3yujhjh565mm5n"
Tutto qui, ogni chiamata al server invio massimo questa roba, altrimenti anche la metà.
Io in passato ho utilizzato i servizi ASMX, Client può gestire il servizio come semplici chiamate ai metodi delle classi.
Ho letto che è diventato obsoleto, è vero?
pabloski
18-05-2018, 14:15
I miei invii sono roba tipo cosi:
"id=4d34g234hj&im=200&ty=50&q=42ui23i4234y3yujhjh565mm5n"
Tutto qui, ogni chiamata al server invio massimo questa roba, altrimenti anche la metà.
Praticamente ti basta il POST del HTTP/HTTPS. Si potrebbe usare il GET, ma è preferibile il POST in un contesto cifrato, in quanto riduce a zero i possibili leak e consente ( in ogni caso ) maggiore flessibilità nel numero e dimensione dei dati.
Praticamente ti basta il POST del HTTP/HTTPS. Si potrebbe usare il GET, ma è preferibile il POST in un contesto cifrato, in quanto riduce a zero i possibili leak e consente ( in ogni caso ) maggiore flessibilità nel numero e dimensione dei dati.
Scusa le domande magari scontate per te ma sono a digiuno di questi argomenti.
1) Quale è la differenza tra creare una comunicazione Client/Server con api oppure con https+POST con stringa cifrata?
2) Quindi come ha detto fazz sopra:scambio di chiavi simmetriche mediante protocollo asimmetrico
3) tu che ne pensi dei web services asmx, sono obsoleti? Quale è il tuo commeto a riguardo?
pabloski
18-05-2018, 15:41
1) Quale è la differenza tra creare una comunicazione Client/Server con api oppure con https+POST con stringa cifrata?
Standard. HTTP è uno standard e quindi interoperabile con altri software, qualora dovesse essercene la necessità.
L'uso di HTTP per quel tipo di servizi va sotto l'acronimo REST ( o RESTful ).
E considera che avrai a disposizione gazillioni di librerie e strumenti che implementano lo standard.
2) Quindi come ha detto fazz sopra:scambio di chiavi simmetriche mediante protocollo asimmetrico
Esatto, ed è parte dell'handshake di HTTPS. Cioè HTTPS fa così.
3) tu che ne pensi dei web services asmx, sono obsoleti? Quale è il tuo commeto a riguardo?
Humm obsoleti non direi. Mi pare si usino ancora oggi. Che poi MS abbia implementato WCF come successore di ASMX è vero. Ed è vero che WCF è più flessibile, infatti sfrutta altri protocolli oltre a HTTP. Ma non vedo che differenza possa fare nel tuo caso.
Ma non vedo che differenza possa fare nel tuo caso.
Solo di praticità,
non so se hai mai utilizzato ASMX,
nel Client dopo la dichiarazione della nuova istanza del servizio, gesti tutti i suoi metodi pubblici come se tu avessi le classi nella soluzione del tuo Client, chiami i metodi, passi i parametri, etc...
è un po come estendere e/o implementare il Client con classi/metodi del client stesso, in realtà utilizzi quelle del web service.
Ho detto che non chiedevo più nulla ma questa è veramente l'ultima:
Ma se il web service fosse sviluppato in PHP sarebbe in grado di gestirlo un Client RESTFull in C# ?
Solo di praticità,
non so se hai mai utilizzato ASMX,
nel Client dopo la dichiarazione della nuova istanza del servizio, gesti tutti i suoi metodi pubblici come se tu avessi le classi nella soluzione del tuo Client, chiami i metodi, passi i parametri, etc...
è un po come estendere e/o implementare il Client con classi/metodi del client stesso, in realtà utilizzi quelle del web service.
Ho detto che non chiedevo più nulla ma questa è veramente l'ultima:
Ma se il web service fosse sviluppato in PHP sarebbe in grado di gestirlo un Client RESTFull in C# ?
ovviamente si client e server sono due sistemi completamente isolati e puoi farli come ti pare (pensa che io ho fatto una volta ho dovuto fare un client rest su microcontrollore scrivendo manualmente tutto il protocollo)
secondo me se già conosci c# il web server ti conviene farlo con un progetto web api direttamente in c# se vedi gli esempi è di una banalità assurda e hai un linguaggio nettamente più potente di php e con la possibilità di fare debug e passo passo della parte server
pabloski
18-05-2018, 17:09
Ma se il web service fosse sviluppato in PHP sarebbe in grado di gestirlo un Client RESTFull in C# ?
Visto che uno degli scopi è proprio disaccoppiare server e client, direi di si. Parliamo di RESTful ovviamente. Non so se ASMX faccia cose strane e non standard.
Che poi alla fin fine REST usa gli URI e i metodi del HTTP. In PHP tu hai $_SERVER['REQUEST_METHOD'] per sapere che metodo è stato invocato e $_SERVER['PATH_INFO'] per catturare l'URI.
ovviamente si client e server sono due sistemi completamente isolati e puoi farli come ti pare (pensa che io ho fatto una volta ho dovuto fare un client rest su microcontrollore scrivendo manualmente tutto il protocollo)
secondo me se già conosci c# il web server ti conviene farlo con un progetto web api direttamente in c# se vedi gli esempi è di una banalità assurda e hai un linguaggio nettamente più potente di php e con la possibilità di fare debug e passo passo della parte server
Anche a me piace molto di più C#, oggi mi hanno confermato che le API per l'acquisto dei bitcoin dall'Exchange me le danno sviluppate in PHP, ancora non ho la documentazione ma credo di avere capito da terze persone che non hanno API REST ma è un Client API come coinbase:
https://developers.coinbase.com/docs/wallet/guides/bitcoin-wallet
Apepna ho la documentazione vedrò come procedere.
pabloski
18-05-2018, 17:34
Anche a me piace molto di più C#, oggi mi hanno confermato che le API per l'acquisto dei bitcoin dall'Exchange me le danno sviluppate in PHP, ancora non ho la documentazione ma credo di avere capito da terze persone che non hanno API REST ma è un Client API come coinbase:
https://developers.coinbase.com/docs/wallet/guides/bitcoin-wallet
Apepna ho la documentazione vedrò come procedere.
Ma Coinbase usa REST https://developers.coinbase.com/api/v2#list-address39s-transactions
E sarebbero stati pazzi a non farlo. Ti danno una libreria PHP per rendere più facile l'interazione con le loro API. Ma nessuno vieta ad un terzo di riscrivere la libreria in C#, Python, Go, Rust, Haskell o quello che gli pare.
Ma Coinbase usa REST https://developers.coinbase.com/api/v2#list-address39s-transactions
E sarebbero stati pazzi a non farlo. Ti danno una libreria PHP per rendere più facile l'interazione con le loro API. Ma nessuno vieta ad un terzo di riscrivere la libreria in C#, Python, Go, Rust, Haskell o quello che gli pare.
Si lo so, stò già lavorando con loro, era per farti l'esempio...
Credo che questi che devo lavorarci la prossima settimana mi danno solo la libreria in PHP, questo volevo dire.
Comunque tutto ok.
rest o soap non è che cambi un gran che lato dati puoi inviare dati cifrati anche su https facendo una cifratura a due livelli
https ti garantisce che la connessione avviene su un canale sicuro (scambio di chiavi simmetriche mediante protocollo asimmetrico ) poi i dati che mandi li gestisci come vuoi
es mando un json contenente i dati cifrati secondo un algoritmo simmetrico con chiave univoca per il client
Sono in disperazione...
- Ho deciso di fare una api restful in C# e il client chiaramente in C#
- Vorrei fare come mi hai detto tu sopra nella QUOTE
- Ho trovato decine di articoli/guide/video/etc.., ma nessuno mi spiega il metodo che tu mi hai presentato.
Puoi consigliarmi qualche link per vedere se riesco a capire come fare un "server e un client che si parlano" con le sicurezze che tu hai detto?
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.