[C#] Sicurezza nelle comunicazioni Client/Server - SOAP o RESTFull API

[race2]

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]

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.

[!fazz]

Originariamente inviato da pabloski

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

[race2]

Originariamente inviato da pabloski

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...

[race2]

Originariamente inviato da !fazz

+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?

[race2]

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??

[!fazz]

Originariamente inviato da race2

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

[race2]

Originariamente inviato da !fazz

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 ?

[!fazz]

Originariamente inviato da race2

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

[race2]

Originariamente inviato da !fazz

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

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!!!

[!fazz]

Originariamente inviato da race2

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

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

[race2]

Originariamente inviato da !fazz

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à.

[race2]

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]

Originariamente inviato da race2

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.

[race2]

Originariamente inviato da pabloski

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]

Originariamente inviato da race2

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.

Originariamente inviato da race2

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ì.

Originariamente inviato da race2

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.

[race2]

Originariamente inviato da pabloski

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# ?

[!fazz]

Originariamente inviato da race2

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]

Originariamente inviato da race2

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.

[race2]

Originariamente inviato da !fazz

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...bitcoin-wallet

Apepna ho la documentazione vedrò come procedere.