La distribuzione SSL può incorrere in problemi di prestazioni [chiuso]

Does SSL deployment for secure server-client communication incur any performance overhead?

• SSL / TLS non è più costoso dal punto di vista computazionale .
• Infatti, in alcuni casi e con alcune ottimizzazioni, può essere effettivamente più veloce del semplice HTTP. Controlla questo: link

Why not just use HTTPS for standard web browsing when it is proven that it protects our privacy?

Tradizionalmente, le persone non si sono preoccupate di HTTPS perché:

• Coinvolge più lavoro come ottenere certificati, reinstallare nuovi certificati dopo la scadenza ecc.
• è difficile (o talvolta non è possibile) configurarlo sui server di hosting condiviso.

Questo sta cambiando velocemente, grazie a iniziative come letsencrypt che rendono i certificati facili da creare e gratuiti.

Inoltre, Google Chrome sta facendo un ottimo lavoro spingendo le persone ad adottare HTTPS. Ci sono due iniziative nella pipeline che renderanno / forzeranno molti proprietari di siti Web a passare a https. Da questo annuncio :

• A partire da gennaio 2017 (Chrome 56), contrassegneremo le pagine HTTP che raccolgono password o carte di credito come non sicure
• Allafine,pianificanodietichettaretuttelepagineHTTPcomenonsicureedicambiarel'indicatoredisicurezzaHTTPconiltriangolorossocheusiamoperHTTPSspezzato.

Viste queste iniziative, dovremmo assistere a un'adozione molto positiva di https nel prossimo futuro.

Sto assumendo dalla domanda che intendevi SSL. SSH o shell sicura è un'alternativa a telnet per ottenere l'interfaccia amministrativa remota. Non è correlato al traffico web o alla navigazione.

Per quanto riguarda la tua query, sì, c'è un overhead delle prestazioni quando viene utilizzato HTTPS anziché HTTP.

La ragione di ciò sono le strette di mano e le comunicazioni coinvolte nella configurazione di una connessione SSL.

Durante l'accesso a un normale sito Web HTTP il client completerà l'handshake a tre vie TCP, stabilirà la comunicazione e inizierà a inviare richieste HTTP.

D'altra parte, in un sito Web https, esiste una rinegoziazione aggiuntiva per stabilire i parametri di sicurezza per TLS. Questo è un consumo di risorse e porta a un sovraccarico computazionale.

Il codice crittografico della rete di Google sia per Chrome che per i server ha scritto nel 2010 che l'overhead della CPU di TLS su Google era dell'1%.

TLS non è stato lento per un tempo molto lungo. Dire che è lento è quasi come dire "Ho sentito che l'8087 è lento, quindi non uso il numero in virgola mobile nel mio codice". Inoltre, ci vorrebbe 1 minuto per Google questo fatto.

SSH ha un caso d'uso molto diverso dal web. È per gli utenti tecnici che accedono ai sistemi interni. Viene sempre distribuito in un modo che richiede l'autenticazione del client sul server e non solo sul server per il client.

La tecnologia nel moderno SSH e TLS moderno è la stessa, altrettanto sicura e veloce: AES-GCM o ChaCha20-Poly1305 per la riservatezza e l'integrità di massa, RSA o ECDSA o EdDSA firme digitali per l'autenticazione, ECDHE su P-256 o X25519 per lo scambio di chiavi e il segreto di inoltro. Le moderne CPU Intel fanno più di 2 GB al secondo per core di AES e poche migliaia di handshake RSA al secondo. EdDSA è più veloce di RSA ma sarà disponibile solo per TLS il prossimo anno.

SSH è stato più veloce con la standardizzazione di X25519 e EdDSA, ma l'adozione di nuove versioni e suite di crittografia è più veloce con TLS, entrambe le cose per motivi non tecnici complicati.

Entrambi i protocolli consentono ai client di essere autenticati dal server utilizzando chiavi pre-condivise o chiavi pubbliche, con la chiave privata potenzialmente presente su una smartcard.

Entrambi i protocolli possono utilizzare chiavi pre-condivise o PKI affidabili al primo utilizzo. SSH si imposta automaticamente su trust-on-first-use. Il valore predefinito del Web è distribuito con la cache di trust-on-first-use tramite certificati webpki validati dal dominio. I client possono e spesso eseguono l'autenticazione non predefinita (ad esempio, i certificati aggiunti dalla CA aziendale).

Dopo le rivelazioni di Snowden, alcune organizzazioni, in particolare Google, hanno dichiarato guerra al traffico non criptato e stanno spingendo tutti a utilizzare TLS. I siti che supportano TLS devono essere impostati su TLS e potrebbero non supportare il testo in chiaro. Perché lo stackexchange.com non è predefinito in TLS? Non lo so.

La risposta alla tua domanda è "sì". La vera domanda non è se sia lenta in quanto può essere attribuita a molteplici fattori variabili come velocità di rete, larghezza di banda e carico di traffico. Tuttavia, se chiedi "È più lento?" allora la risposta è sì. Tuttavia, su una rete sufficientemente capace la differenza è trascurabile.

Per essere onesti, @ Z.T. ha il diritto di farlo anche se potrebbe essere più dettagliato di quello che stai cercando.