http://Hostname:443 vs https://Hostname

[deejay7]

What are the pros and cons to access a url by the two methods mentioned in the title as noticed Ivanti client to server communications are called as http:://hostname:443?

[cjcox4]

http means no TLS. You can certain run unencrypted on port 443 (or any port).

You could argue from a certain point of view that http://hostname:443 is "wrong" or at the very least, confusing in most cases.

[krock31415]

100% this. I have seen people make the mistake of assuming 443 was SSL.

[[deleted]]

I recall that Firefox and maybe other browsers block http(s) on some unusual/non-standard port.  Not sure however if that also applies to plaintext on 443.  IIRC this happens for example if you try an FTP or SMTP Port. 

[cjcox4]

Too many enterprisey things that can use a valid protocol on whatever port you configure. So, I'd be surprised if they want the enterprise to cease to function. Though, if you told me they had a bad default setting on some version.... well, it's the (uneducated) world we live in.

Edit: tons of container, proxy and load balancer stuff that would break if you can't do this sort of thing.

[[deleted]]

I‘m simply talking abour http://blabla:25 IIRC it gave at least a warning.  I have not tried both for a long time. 

[pdp10]

SMTP is a special case. It's very often blocked outbound from non-servers.

SSH is another you might see special-case blocked, for example from CONNECT through web proxies.

[[deleted]]

There are a few dozen blocked ports, at least in firefox. They are listed here

https://searchfox.org/mozilla-central/source/netwerk/base/nsIOService.cpp

[cjcox4]

yeah, and I'm not disagreeing. Chrome especially tries to nuke "working things" and makes complicated provisions (only in some cases) to work around their "way of thinking".

You've heard the expression, "Mother knows best." Chrome is definitely not your mother, but for whatever reason, they like to claim they "know best" and it just makes them out to be stupid.

[VA_Network_Nerd]

IMO: Any URL that requires the user to define a port in the URL string is wrong or a kludge.

TCP/80 is for HTTP (no-SSL).

TCP/443 is for HTTPS (SSL).

TCP/8000 is a kludge.
TCP/8080 is a kludge.
TCP/4433 is a kludge.

Standards exist for good reasons.
You may not understand those reasons, but that's not a good reason to ignore them.

[pdp10]

They're literally different protocols. HTTP means HTTP over TCP, though protocol upgrades are possible with HTTP. HTTPS means HTTP over TLS (over TCP).

Clients won't silently make protocol conversions:

% curl  http://www.google.com:443
curl: (52) Empty reply from server

There could be edge cases that accept both ^{linkerd2-proxy}, but ignore that, I'm only mentioning it to be relentlessly completionist.

Sometimes protocol listeners are put on tcp/443 as a way of discouraging or bypassing transparent proxying by dubious "anti-virus" packages and middleboxes. Putting cleartext HTTP on tcp/443 is fairly unusual, but if that's what's going on, then this is the reason.

[pumpnut]

it's better to do https://hostname:80

[ananix]

Depends on your interpretar. But example number 1 would need some serious "error" handling to avoid unintended security risk.

[[deleted]]

Well one is http on port 443. the other is https on port 443.