http e https si riferiscono al protocollo in uso.
http viene utilizzato per comunicazioni in chiaro non crittografate, il che significa che i dati trasferiti possono essere intercettati e letti in modo chiaro da un essere umano. I campi nome utente / password possono ad esempio essere acquisiti e letti.
https si riferisce alla comunicazione crittografata SSL / TLS. Deve essere decrittografato per essere letto. Normalmente / idealmente solo gli endpoint sono in grado di crittografare / decrittografare i dati, sebbene si tratti di un'istruzione con avvertenze ( vedi modifica sotto ).
Pertanto https può essere considerato più sicuro di http.
: 80 e: 443 si riferiscono solo alla porta del server in uso (ovvero è "solo un numero") e non ha alcun significato per quanto riguarda la sicurezza.
Tuttavia, esiste una forte convenzione per inviare http sulla porta 80 e https sulla porta 443, il che rende le combinazioni nella domanda più che poco ortodosse. Sono tecnicamente perfettamente utilizzabili, purché gli endpoint siano in accordo e non vi siano oggetti filtro intermedi.
Quindi, per rispondere, http://example.com:443 è meno sicuro di https://example.com:80 e la differenza è pratica (anche se può essere compensata in diversi modi) e non solo teorica.
È possibile testare facilmente la validità di queste istruzioni utilizzando un server Web e un client in cui si manipolano il serverport e lo stato della crittografia, acquisendo e confrontando ogni sessione con un decodificatore di protocollo come WireShark.
[ EDIT - avvertenze relative alla sicurezza del percorso client / server ]
Ciò che equivale essenzialmente a un attacco https man-in-the-middle può essere eseguito a scopo di intercettazione o imitazione. Può essere fatto come un atto di malevolenza, benevolenza o come risulta anche a causa dell'ignoranza, a seconda delle circostanze.
L'attacco può essere fatto sfruttando una debolezza del protocollo come il bug heartble o la vulnerabilità di Poodle , oppure attraverso l'istanza di un proxy https tra il client e il server nel percorso di rete o direttamente sul client .
L'uso malevolo non ha bisogno di molte spiegazioni, penso. Un uso benevolo sarebbe ad esempio un'organizzazione che proietta connessioni https in entrata a fini di registrazione / ID o connessioni https in uscita per filtrare le applicazioni consentite / negate . Un esempio di uso ignorante sarebbe l'esempio di Lenovo Superfish collegato sopra o la recente variante Dell dello stesso errore.
MODIFICA 2
Hai mai notato come il mondo continua ad arrivare le sorprese? Uno scandalo è appena scoppiato in Svezia, dove tre organizzazioni sanitarie del consiglio di contea hanno utilizzato la stessa catena di approvvigionamento per la registrazione degli eventi sanitari attraverso le telefonate dei pazienti.
Per così dire, la domanda ottiene così una risposta su vasta scala delle cose. Se solo fosse uno scherzo pratico e non un evento reale ...
Incollerò semplicemente due frammenti tradotti dal testo delle notizie in Computer Svezia :
"Computer Sweden oggi può rivelare uno dei più grandi disastri di sempre per quanto riguarda la sicurezza dei pazienti e l'integrità personale. Su un server Web aperto senza alcuna forma di protezione tramite password o altro metodo di sicurezza, abbiamo trovato 2,7 milioni di chiamate registrate dai pazienti all'assistenza sanitaria attraverso il numero di consulenza medica 1177. Le chiamate risalgono al 2013 e contengono 170.000 ore di voce sensibile chiama i file che chiunque può scaricare e ascoltare.
[...]
Le chiamate sono state salvate sul server di archiviazione Voice Integrated Nordics all'indirizzo IP http://188.92.248.19:443/medicall/ . Tcp-port 443 indica che il traffico è stato passato su https, ma la sessione non è crittografata.
Non riesco a decidere se questo è ancora un altro esempio di ignoranza o se stiamo vedendo una categoria completamente nuova. Per favore, consiglio.