Bem ... dado que tenho o mesmo problema em relação à nossa política corporativa (como um SysAdmin onde trabalho, inclusive), e fui explicitamente instruído pelos meus superiores, eu poderia e deveria usar a ideia abaixo para "solucionar" alguns nossas restrições políticas, não vejo o mal em compartilhar o conhecimento.
http e https não são portas, são protocolos. Portas tem números. A porta padrão usada para http é 80 (com 81 e 8080 sendo valores alternativos comuns) e a porta padrão para https é 443. Não há nada que diga que o tráfego nesses protocolos não pode usar uma porta diferente ou protocolos diferentes não podem usar essas portas em vez dos protocolos padrão.
Dado que, não há nada que o impeça de configurar um servidor TS / RDP em outro local (talvez em casa, ou em uma instância de nuvem) que escuta conexões de entrada em uma porta não padrão para RDP (talvez porta 443 ) e tente se conectar a ele por trás do firewall corporativo instruindo mstsc.exe a se conectar através de uma porta não padrão (a mesma porta não padrão sendo ouvida na outra extremidade, como 443 neste exemplo puramente hipotético). Através desta sessão RDP, pode-se controlar o computador remoto e, por exemplo, executar um aplicativo Java para executar negociações ocasionais com um corretor. Ou qualquer outra coisa que venha à mente.
Isso pode ou não funcionar de fato, com as outras opções que os firewalls corporativos têm para restringir o tráfego, mas também podem.
É claro que, se você tentar isso, você desejará ter certeza de que o computador remoto (talvez em casa, ou em uma instância da nuvem) esteja corretamente bloqueado, protegido por uma senha strong em todos https tráfego também, sem sucesso, o que resultaria em tráfego https real na porta 443 para a máquina em questão falhando.
Se você quisesse experimentar algo assim, poderia pesquisar por aqui ou pelo SuperUser para obter respostas sobre como alcançar tudo isso.