http y https se refieren al protocolo en uso.
http se usa para la comunicación de texto sin cifrar, lo que significa que los datos transferidos pueden ser interceptados y leídos por un humano. Los campos de nombre de usuario / contraseña pueden, por ejemplo, capturarse y leerse.
https se refiere a la comunicación encriptada SSL / TLS. Debe ser descifrado para ser leído. Normalmente / idealmente, solo los puntos finales son capaces de cifrar / descifrar los datos, aunque esta es una declaración con advertencias ( consulte la edición a continuación ).
Por lo tanto, https puede considerarse más seguro que http.
: 80 y: 443 se refieren solo al puerto del servidor en uso (es decir, es "solo un número") y no tiene ningún significado en lo que respecta a la seguridad.
Sin embargo, existe una fuerte convención para enviar http sobre el puerto 80 y https sobre el puerto 443, lo que hace que las combinaciones en la pregunta sean poco ortodoxas. Sin embargo, son técnicamente perfectamente utilizables, siempre que los puntos finales estén de acuerdo y no haya objetos de filtro intermedios.
Entonces, para responder, http://example.com:443 es menos seguro que https://example.com:80 y la diferencia es práctica (aunque puede compensarse de varias maneras) y no meramente teórica.
Puede probar fácilmente la validez de estas declaraciones utilizando un servidor web y un cliente donde manipula el puerto del servidor y el estado de cifrado, mientras captura y compara cada sesión con un decodificador de protocolo como wireshark.
[ EDITAR - advertencias sobre la seguridad de la ruta del cliente / servidor ]
Lo que esencialmente equivale a un ataque https man-in-the-middle se puede realizar con fines de espionaje o suplantación. Puede hacerse como un acto de malevolencia, benevolencia o como resultado incluso por ignorancia, dependiendo de las circunstancias.
El ataque puede realizarse explotando una debilidad del protocolo, como el error de heartbleed o la vulnerabilidad de Poodle , o creando instancias de un proxy https entre el cliente y el servidor en la ruta de red o directamente en el cliente .
El uso malévolo no necesita mucha explicación, creo. El uso benéfico sería, por ejemplo, una organización que representa las conexiones https entrantes para fines de registro / ids , o conexiones https salientes para filtrar aplicaciones permitidas / denegadas . Un ejemplo de uso ignorante sería el ejemplo de Lenovo Superfish vinculado anteriormente o la reciente variación de Dell del mismo error.
EDITAR 2
¿Alguna vez has notado cómo el mundo mantiene las sorpresas? Un escándalo acaba de estallar en Suecia, donde tres organizaciones de salud del consejo del condado han utilizado la misma cadena de suministro para registrar eventos de atención médica a través de llamadas telefónicas de pacientes.
Por así decirlo, la pregunta obtiene una respuesta a gran escala de las cosas. Si solo fuera una broma práctica y no un evento real ...
Simplemente pegaré dos fragmentos traducidos del texto de las noticias en Computer Sweden :
"Computer Sweden hoy puede revelar uno de los mayores desastres de la historia de la seguridad del paciente y la integridad personal. En un servidor web abierto sin ningún tipo de protección con contraseña u otro método de seguridad, hemos encontrado 2,7 millones de llamadas grabadas de pacientes a la atención médica a través del número de aviso médico 1177. Las llamadas se remontan a 2013 y contienen 170,000 horas de voz sensible llamar archivos que cualquiera podría descargar y escuchar.
[...]
Las llamadas se han guardado en el servidor de almacenamiento Voice Integrated Nordics en la dirección IP http://188.92.248.19:443/medicall/ . El puerto Tcp 443 indica que el tráfico se ha pasado por https, pero la sesión no está encriptada.
No puedo decidir si este es otro ejemplo más de ignorancia, o si estamos viendo una categoría completamente nueva. Por favor aconséjame.