Best practice on choosing alternative SSL ports
-
The ports designated for the purpose described are 49152–65535. You can pick any ports you want in this, the ephemeral range. No one can request a port assignment from this range.
For easy of use, I would start at 50,000 and increment by one as needed for each additional port.
-
Or I would follow @johnhooks idea and put an nGinx proxy in front of everything so that only port 443 need be used.
-
@scottalanmiller said:
Or I would follow @johnhooks idea and put an nGinx proxy in front of everything so that only port 443 need be used.
Agreed, assuming IIS can't do it directly, stand up a proxy to make your life easier.
-
Or you can cheat a little bit. This works using IIS, Apache, or whatever other web service you want...
Export Port 80 on your web server, assuming you have one available to the public...
Then setup folder structures... ie: /services/spiceworks
In the spiceworks folder, put an index.html file that reads:
<meta http-equiv='refresh' content='0;url=https://my.server.name:mysslport' />That will automatically redirect your users to the HTTPS server and port and they dont' have to remember port numbers, etc. for themselves.
-
@dafyre said:
That will automatically redirect your users to the HTTPS server and port and they dont' have to remember port numbers, etc. for themselves.
Ah, so able to use HTTP Header detection with SSL, then redirect for SSL. Tricky.
-
@dafyre said:
Or you can cheat a little bit. This works using IIS, Apache, or whatever other web service you want...
Export Port 80 on your web server, assuming you have one available to the public...
Then setup folder structures... ie: /services/spiceworks
In the spiceworks folder, put an index.html file that reads:
<meta http-equiv='refresh' content='0;url=https://my.server.name:mysslport' />That will automatically redirect your users to the HTTPS server and port and they dont' have to remember port numbers, etc. for themselves.
Sure, but doesn't that leave port 80 actually open to attack? Wouldn't this be better served at the firewall?
What I don't know is.. is port 80 any more vulnerable to attack than port 443?
-
@Dashrender said:
Sure, but doesn't that leave port 80 actually open to attack?
The IIS ports have to be open, period. That can't change unless you have a full proxy out in front. What are you thinking is the issue here? Why is port 80 mentioned?
-
@Dashrender said:
What I don't know is.. is port 80 any more vulnerable to attack than port 443?
All ports are identical. They are just ports, addresses. Is 114 Mockingbird Lane more risky than 118 Mockingbird Lane based solely on the street address? Same thing with ports.
-
@scottalanmiller said:
@Dashrender said:
What I don't know is.. is port 80 any more vulnerable to attack than port 443?
All ports are identical. They are just ports, addresses. Is 114 Mockingbird Lane more risky than 118 Mockingbird Lane based solely on the street address? Same thing with ports.
Point taken - I just didn't know if the service sitting behind port 80 was more susceptible to attack than the TLS service that sits behind port 443.
-
@Dashrender said:
Point taken - I just didn't know if the service sitting behind port 80 was more susceptible to attack than the TLS service that sits behind port 443.
Service is IIS in both cases.
-
SSL and TLS protect people from spying on an existing communications channel, but does nothing to protect the end points. It's just a service that has to respond to any incoming request.
