L'autenticazione tramite HTTPS rallenta la mia applicazione?


11

Sto creando un'applicazione Web e un servizio Web RESTful.

Ho letto vari articoli sul modo migliore per autenticare le richieste al servizio web.

L'opzione migliore per me sembra essere quella di utilizzare l'autenticazione di base HTTP. Praticamente ogni articolo che leggo dice che l'autenticazione dovrebbe essere crittografata su SSL o equivalente.

Non sono del tutto sicuro di cosa implichi. Questo significa che il mio intero servizio web dovrà essere su un server sicuro? Questo rallenterà le cose?


Un pensiero, cachability dei dati caricati su https. Non sono sicuro al 100% su se / come questo avrà un impatto.

non sono sicuro di seguire. Stai dicendo che la memorizzazione nella cache non è possibile?
Gaz_Edge,

Ci sono interazioni tra ssl / https e il server web che potrebbero non essere intenzionali con REST - cxf.547215.n5.nabble.com/… - Non ho approfondito troppo REST in un ambiente sicuro, quindi questo non è stato un problema per me. È più dai pensieri e dai suggerimenti dei miei giorni come amministratore di Apache.

Grazie. Dici di non aver usato REST in un ambiente sicuro. Ciò significa che non stai utilizzando l'autenticazione? O lo stai facendo in modo diverso da http basic.
Gaz_Edge,

Non è un'autenticazione, di base o basata su ip ... e puramente in una rete intranet (nulla rivolto verso l'esterno).

Risposte:


11

Prima di tutto, cerca di capire come funziona l'autenticazione SSL (HTTPS) e HTTP.

I soliti metodi di autenticazione HTTP (Digest, Basic e qualsiasi modulo + schema di autenticazione basato su cookie che puoi implementare su HTTP) sono tutti insicuri da soli, perché inviano più o meno informazioni di autenticazione in chiaro. A prescindere dal fatto che i dati si trovino nei campi o nelle intestazioni POST e che venga applicata la codifica base64, la questione è chiaramente visibile a chiunque abbia accesso al traffico di rete. Ciò significa che l'autenticazione HTTP su un canale non attendibile è inutile: tutto ciò che serve a un utente malintenzionato per leggere la password è un po 'di sniffing della rete.

SSL implementa un canale di comunicazione sicuro su un canale intrinsecamente insicuro. Funziona approssimativamente come segue:

  1. Il server invia un certificato firmato
  2. Il client convalida il certificato in base a un elenco di chiavi di firma note valide; le firme dei certificati possono essere concatenate, in modo che ogni nodo dica "se la firma che mi firma è buona, allora lo sono anch'io", ma alla fine la catena deve risolversi in una delle poche autorità fidate preconfigurate sul client.
  3. Il client utilizza la chiave di crittografia pubblica del server per inviare un segreto condiviso
  4. Il server decodifica il segreto condiviso usando la chiave privata (poiché solo il server legittimo ha la chiave privata, gli altri server non saranno in grado di decrittografare il segreto condiviso)
  5. Il client invia i dati della richiesta effettiva, crittografati utilizzando il segreto condiviso
  6. Il server decodifica i dati richiesti, quindi invia una risposta crittografata
  7. Il client decodifica la risposta e la presenta all'utente.

Nota alcuni punti importanti qui:

  • La catena di certificati consente ai client di assicurarsi che il server con cui stanno parlando sia quello reale, non qualcuno che intercetta le loro richieste. Ecco perché dovresti acquistare un vero certificato SSL e perché i browser ti lanciano avvisi spaventosi quando colpisci un sito che utilizza un certificato non valido, scaduto o altrimenti errato: tutta la crittografia nel mondo non aiuta se sei parlando con la persona sbagliata.
  • La crittografia pubblica / privata utilizzata per scambiare il segreto assicura che la comunicazione riuscita funzionerà solo tra questa particolare coppia di client e server: i pacchetti di rete sniffati saranno crittografati e richiederanno la chiave privata del server per ottenere i dati.
  • La crittografia simmetrica viene utilizzata per la maggior parte della richiesta, poiché ha un sovraccarico di prestazioni molto inferiore rispetto alla crittografia a chiave privata / pubblica. La chiave (segreto condiviso) viene scambiata utilizzando la crittografia della chiave privata / pubblica, poiché è l'unico modo per farlo in modo sicuro (tranne per il trasporto su un canale separato, ad esempio un servizio di corriere).

Quindi, ovviamente, ci sono alcune spese generali, ma non è così male come si potrebbe pensare - è principalmente nella scala in cui "lanciare più hardware" è la risposta appropriata, a meno che non si stia preparando per quantità di traffico assolutamente enormi ( pensa a Google o Facebook). In circostanze normali, vale a dire l'utilizzo tipico delle applicazioni Web, l'overhead SSL è trascurabile e, di conseguenza, non appena si dispone di dati riservati, è meglio eseguire tutto su SSL, comprese le risorse. SSL è anche l'unico modo possibile per proteggere il traffico HTTP; altri metodi semplicemente non sono così standardizzati e quindi non ampiamente supportati, e tu non vuoi assolutamente implementare queste cose da solo, perché onestamente, è semplicemente troppo facile sbagliarle.

TL; DR: Sì, l'autenticazione SSL + di base è una buona idea, sì, hai bisogno di un server sicuro (e un certificato valido ), sì, rallenterà un po 'le cose, ma no, questo non è qualcosa di cui preoccuparsi, giusto adesso.


12

HTTPS (SSL) non è FYI di autenticazione utente. Fornisce solo la crittografia tra 2 endpoint.

Ma sì, c'è un piccolo piccolo sovraccarico da esso (anche se non abbastanza per giustificare un cambiamento nei piani / hardware). Vedere qui :

/programming/548029/how-much-overhead-does-ssl-impose


7
+1 meglio per essere troppo sicuro che non abbastanza sicuro dato il piccolo overhead
Earlz

2
Questa risposta è molto fuorviante. SSL è autenticazione, di solito non è autenticazione dell'utente . SSL autentica che il server con cui stai parlando è davvero chi dice che sia. (Il compito della CA è di rilasciare certificati solo da facebook.com a Facebook.) Inoltre, SSL può eseguire l'autenticazione utente con certificati client.
josh3736,

@brian: concordo con josh3736. SSL fornisce autenticazione nel senso crittografico della parola. Senza l'autenticazione (ad es. Server) sei aperto agli attacchi man in the middle. SSL può fornire l'autenticazione client (utente) sicura utilizzando smart card o se ha autenticato il server in altri modi (ad esempio nome utente / password) possono essere utilizzati sul canale sicuro.
Guy Sirton,

In realtà, era ovvio che l'OP chiedeva l'autenticazione dell'utente e non si preoccupava del client che autenticava con chi stava parlando / l'uomo in mezzo agli attacchi. Ho modificato il mio post di fronte a una grave pedanteria;) tecnicamente corretto è il miglior tipo di corretto, dopotutto
Brian

6

Con l'autenticazione di base HTTP, il nome utente e la password forniti dall'utente vengono inviati con ogni richiesta al server. Ciò significa che sono in chiaro anche nelle aree del tuo sito che non devono necessariamente essere sicure. Ovviamente, ti consigliamo SSL qui per proteggere i tuoi utenti.

In teoria, è possibile utilizzare l'autenticazione con cookie e inserire SSL nella pagina di accesso (dove vengono inviati nome utente e password). Se i tuoi cookie sono abbastanza sicuri e protetti contro gli attacchi replay, un utente malintenzionato non sarebbe in grado di fare nulla con loro anche se riuscisse a ottenerne uno.


3

L'autenticazione di base sta impostando un nome utente e una password nell'intestazione della richiesta http. Se non usi SSL o equivalenti, quel nome utente e password vengono inviati in testo semplice ed è banale per chiunque rubarlo.

Oggigiorno la maggior parte dei server Web supporta HTTPS e, sebbene aggiunga overhead a ogni chiamata, tale overhead è minimo.

È possibile proteggere alcuni endpoint e non altri (ovvero disporre di un endpoint autenticato che produce un token che può essere utilizzato per altre chiamate). Consiglio vivamente SSL per l'intero servizio, anche se è molto più sicuro. (se non altro impedisce l'intercettazione di dati sensibili)


Sì, penso che questa sia l'idea migliore. La mia applicazione web gestirà la sessione degli utenti ecc. In modo da poter salvare il token lì. Ma qualcuno potrebbe ancora ficcare il token per quella sessione, giusto? Potrebbe essere ancora un rischio per la sicurezza dei dati
Gaz_Edge,

Sì generalmente. Ci sono cose che puoi fare per proteggere i cookie (cioè crittografarli) ma il percorso più semplice ed efficace è proteggere l'intero sito. A meno che tu non abbia un caso d'uso specifico, consiglierei la soluzione più semplice
Tom Squires,

2

Jeff Atwood non ha scritto molto tempo fa un breve post sul blog se la crittografia completa sia la strada da percorrere. Descrive alcuni esempi del mondo reale e ha alcune righe anche sulle considerazioni sulle prestazioni.

Inoltre, fa riferimento a questo articolo su un case study di Gmail, citando quanto segue:

Nel gennaio di quest'anno (2010), Gmail è passato all'uso di HTTPS per impostazione predefinita. In precedenza era stata introdotta come opzione, ma ora tutti i nostri utenti utilizzano HTTPS per proteggere la loro posta elettronica tra i loro browser e Google, sempre. Per fare ciò non abbiamo dovuto distribuire macchine aggiuntive e nessun hardware speciale. Sulle nostre macchine frontend di produzione, SSL / TLS rappresenta meno dell'1% del carico della CPU, meno di 10 KB di memoria per connessione e meno del 2% dell'overhead di rete. Molte persone credono che SSL richieda molto tempo sulla CPU e speriamo che i numeri di cui sopra (pubblici per la prima volta) aiuteranno a dissiparlo.

Cita anche alcuni recenti miglioramenti alla memorizzazione nella cache delle pagine sul lato client tramite HTTPS da parte del browser .

Nonostante ciò, sottolinea, ci sono altre penalità, molte delle quali non sono le prestazioni ma i costi di implementazione:

  • Mantenere la qualità del software aggiungendo ulteriore complessità per i team già impegnati,
  • La memorizzazione nella cache del proxy è molto più difficile da configurare correttamente e necessita anche di modifiche al codice,
  • È difficile ottenere la sicurezza giusta per un mashup di contenuti da diverse fonti,
  • I dispositivi mobili di fascia bassa potrebbero avere difficoltà con la crittografia.

Espandi la tua risposta e includi alcuni punti salienti del blog.
Walter,

I punti salienti del post sul blog sono stati aggiunti.
Daniel Dinnyes,

0

L'autenticazione HTTP di base senza la tua gestione della sessione ti lascerà probabilmente aperto agli attacchi di contraffazione della richiesta su più siti. Probabilmente puoi usarlo se ti accoppi con la tua gestione della sessione, ma potresti avere problemi a fornire una funzione di "logout" pulita.

Indipendentemente da ciò che si utilizza per l'autenticazione, sarà necessario utilizzare HTTPS per crittografare la connessione (a meno che non si acceda all'applicazione Web solo su una rete controllata e sicura). Potrebbe rallentare un po 'le cose (gli stabilimenti di connessione sono costosi, ma i browser tendono a mantenere le connessioni per un po'), ma se si desidera un'applicazione sicura, non sarà comunque possibile evitarlo, quindi non è proprio necessario di cui preoccuparsi.

Nota: "Autenticazione HTTPS" (che hai citato nel titolo) è fuorviante: potrebbe riferirsi all'autenticazione del certificato client SSL, che ha poco a che fare con il testo della tua domanda e ha il suo set di vantaggi e problemi. Probabilmente non vuoi toccarlo.


0

Come hai intenzione di realizzare l'autenticazione di base?
Se si tratta di un nome utente / password codificato e stai utilizzando la funzionalità integrata del tuo server web per farlo, probabilmente avrà un impatto quasi nullo. Se stai facendo cose folli in un database o qualcosa di simile, allora sì, potrebbe esserci un impatto.

Come altri hanno già notato qui, SSL e l'invio delle intestazioni extra renderanno tecnicamente le cose più lente ma non saranno significative in alcun modo.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.