Invio di dati sensibili su HTTPS e dati non sensibili su HTTP?

Questa è una cattiva idea.

I dati non crittografati possono essere letti non solo da un uomo nel mezzo. Può anche essere modificato. Quindi, se una parte minuscola del codice HTML non è crittografata, un utente malintenzionato può inserire JavaScript dannoso che legge i dati sensibili una volta che è stato decodificato nel browser. Boom, l'intera crittografia viene sconfitta.

Questo è anche il motivo per cui è necessario servire l'intero sito e non solo la pagina di accesso su HTTPS .

Per quanto riguarda la tua seconda idea, in realtà non aiuta nulla con le prestazioni, ma ha lo stesso tipo di preoccupanti implicazioni per la sicurezza come la tua prima idea. Il contenuto nel suo complesso non è più sicuro del link più debole.

Quindi perché non aiuta con le prestazioni? La ragione principale per cui cripto può danneggiare le prestazioni è che complica l'incasso. La cripta più debole non lo risolverebbe. Potrebbe esserci qualche algoritmo leggermente più veloce di AES-128 ma meno sicuro, ma sarebbe un guadagno molto marginale nelle prestazioni che si pagano in termini di sicurezza.

E non ho nemmeno menzionato tutto il lavoro che dovresti passare per separare i dati "sensibili" dal "non sensibile" ...

Modifica: non si dovrebbe essere categorici ... Se si è per esempio programmando un gioco potresti voler inviare i dati di gioco in tempo reale (chi spara cosa e dove) su qualcosa di veloce come TCP non criptato, mentre hai una connessione HTTPS separata per es. invio di nome utente e password al server. Ma questo è abbastanza lontano dal caso d'uso della pagina web HTTP.

La crittografia / decrittografia / separazione di dati sensibili / non sensibili nell'applicazione probabilmente causa un sovraccarico maggiore rispetto a HTTPS. Non reinventare la ruota! Nel 2017, la scelta della protezione TLS causa un sovraccarico così insignificante legato ai prezzi della larghezza di banda del server o degli utenti, che non vale nemmeno la pena menzionare.