link e link referem-se ao protocolo em uso.
link é usado para comunicação de texto não criptografado não criptografado, o que significa que os dados transferidos podem ser interceptados e lidos em linguagem simples por um ser humano. Campos de nome de usuário / senha podem, por exemplo, ser capturados e lidos.
link refere-se à comunicação criptografada por SSL / TLS. Deve ser descriptografado para ser lido. Normalmente / idealmente apenas os pontos de extremidade são capazes de criptografar / descriptografar os dados, embora esta seja uma declaração com ressalvas ( veja editar abaixo ).
Portanto, os https podem ser considerados mais seguros que o http.
: 80 e: 443 referem-se apenas à porta do servidor em uso (ou seja, é "apenas um número") e não tem significado algum em relação à segurança.
No entanto, existe uma strong convenção para enviar http pela porta 80 e https pela porta 443, o que torna as combinações na questão mais do que pouco ortodoxas. Eles são tecnicamente perfeitamente utilizáveis, desde que os terminais estejam de acordo e não haja objetos de filtro intermediários.
Então, para responder, o link é menos seguro do que link e a diferença é prática (embora possa ser compensada de várias maneiras) e não meramente teórica.
Você pode facilmente testar a validade dessas declarações usando um servidor e cliente onde você manipula a porta do servidor e o status de criptografia, enquanto captura e compara cada sessão com um decodificador de protocolo, como o wireshark.
[<> EDIT - advertências sobre a segurança do caminho do cliente / servidor ]
O que essencialmente equivale a um ataque do tipo "https man-in-the-middle" pode ser executado para fins de interceptação ou falsificação de identidade. Pode ser feito como um ato de malevolência, benevolência ou como se verifica mesmo devido à ignorância, dependendo da circunstância.
O ataque pode ser feito através da exploração de uma fraqueza de protocolo, como o heartbleed bug ou a vulnerabilidade do Poodle , ou instanciando um proxy https entre o cliente e o servidor no caminho de rede ou diretamente no cliente .
O uso malévolo não precisa de muita explicação, eu acho. O uso benevolente seria, por exemplo, uma organização que faz proxy de conexões https recebidas para fins de logging / ids , ou conexões https de saída para filtragem de aplicativos permitidos / negados . Um exemplo de uso ignorante seria o exemplo do Superfish da Lenovo vinculado acima ou o variação recente da Dell do mesmo deslize.