So I have this little add on in Chrome called Live HTTP Headers.
There is this one url I go to, lets say "www.example.com"
When I inspect the headers I see:
GET / HTTP/1.1 Host: www.example.com:443
So port 443 is directly being asked for, but how come? Should not it be :80 ?
Port 443 is default port number for HTTPS, so
http://www.example.com comunicates on port 80, but
https://www.example.com comunicates on port 443.
Of course, you could always have a different port number and in this case is mandatory to explicitly show the port number in use, i.e.:
https://www.example.com:1443
You can actually run a webserver on any port within the valid range of 0 to 65535.
Internet Assigned Numbers Authority (IANA) do have port recommendations for serving and receiving different types of network traffic which you can read about here https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt
But technically I think you can do whatever you like.
As others pointed out 443 is the default https port. But this just means example.com have configured their webserver to serve secure http (https) content on port 443. They could if they wanted to, serve it on 8443. Most browsers however are configured to automatically send https traffic to 443 if no port is specified in the url. This means if you wanted to server https traffic on port 8443 the user would have to put in the address https://example.com:8443 explicitly.
Related
I'm setting up 4 servers that each have RESTful APIs that go over HTTPS. Because we're in the early stages of a startup, I'm going to host these in my closet.
I have business-class Comcast service, so I can get a static IP address or a series of them. The IP addresses are $10/ea per month, so I can save about $30 if I get just one. I realize this sounds like I'm being super cheap, but we're pinching pennies until we get some customers.
We will probably use one server as a "tools" server that will allow us to reach the other servers via SSH; the other 3 servers will need to have HTTPS open to the internet on the LAN.
I'm considering getting one static IP address, and then using my router to forward HTTPS traffic to the various servers. The port forwarding would look something like:
WAN Port LAN Port Server
22 22 Tools
1443 443 Server 1 (API via SSL)
2443 443 Server 2 (API via SSL)
3443 443 Server 3 (API via SSL)
I would then set up A NAME records in my DNS that would be:
tools.mydomain.com -> <static IP address>:22
server1.mydomain.com -> <static IP address>:1443
server2.mydomain.com -> <static IP address>:2443
server3.mydomain.com -> <static IP address>:3443
Is this a reasonable approach? Will it work?
You cannot direct traffic to a specific TCP port with DNS records. You can only point at an IP-address. The client by default uses tcp port 80 for HTTP and port 443 for HTTPS (unless you explicitly name the port to use in the URL).
Furthermore you cannot have multiple HTTPS-based hosts using the same IP address unless they also use the same SSL certificate. That is because the SSL handshake takes place before the client reveals to the server which hostname it was trying to reach, so the server can only give out an SSL certificate based on the IP address (and port) that was connected to.
In this particular instance, if you have four servers that actually have the same domain, you can get a wildcard SSL certificate (i.e. it covers *.mydomain.com) and then you can actually get away with one single public IP address for all four servers. Just point all DNS records to the same IP address and then you have the server give out your wildcard certificate which is valid regardless of which hostname the client is using. After the SSL handshake is thus completed, the server can look at the Host: -header in the client request to determine which server the request was actually intended for, i.e. you have one server acting as the HTTPS-endpoint where all HTTPS-requests are received and then internally forwarding to unencrypted request to the correct server (or handle all servernames virtually by one physical server).
If you are using Apache HTTP server I suggest you read about name-based virtual hosts and proxy forwarding:
http://httpd.apache.org/docs/current/vhosts/name-based.html
http://httpd.apache.org/docs/current/rewrite/vhosts.html
http://httpd.apache.org/docs/current/rewrite/proxy.html
I have use nginx for reverse proxy which listen on port 80. and I have a web application listen on port 9999, I config nginx with reverse proxy to redirect client request from port 80 to port 9999.
Now I found that when access 80 port, browser will show web application response (this is correct.), however, if browser directly access 9999 port, it will also show web application response.
So, How can I configure nginx that browser can only access port 80, not port 9999. Thanks!
i will recommend you two solutions:
You can bind your application to listen on localhost:9999 rather than *:9999
you can edit your firewall to don't allow traffic for 9999 port and only allow for port 80. for that you can edit iptables by going to /etc/sysconfig/iptables
Is it possible to run couchdb on port 80? I'm looking to host a couchapp from it and don't want my users to have to type a port number in the url.
When I change the port to 80 in the couchdb config it becomes unavailable, and I have no access to it on 80 or any other port. I have to change the port back in the local.ini file.
Is this not a recommended setup? Would I be better hosting behind a reverse proxy? If so, any tips on how to get it working behind an IIS reverse proxy? I tried that too using ARR and URL Rewrite, with no success.
EDIT:
First, this chapter of the CouchDB definitive guide seems to suggest it is ok to server web apps directly from couch. Curious what the community thinks:
http://guide.couchdb.org/editions/1/en/standalone.html
Second, I installed CouchDB on a second machine that does NOT have IIS installed on it and it ran on port 80 just fine, so I suspect that even though I've turned off all websites in IIS it is still hogging port 80. Any way to make IIS give up port 80?
Ok I figured it out. By default IIS listens for port 80 on ALL IPs. So it also grabs 127.0.0.1 and listens on port 80 there as well, EVEN IF YOU TURN OF ALL WEBSITES listening on 80.
To remedy this you need to add an IP address to the IP listen list. By default this list is empty and IIS decides to just listen to all IPs. But if you add an IP or IPs to this list IIS will only listen to those IPs.
First here's how you can see what IPs are in the listen list:
netsh http show iplisten
If the list is blank IIS is listening on all IPs. To add an IP to the list:
netsh http add iplisten XXX.XXX.X.XXX (where the X's are your IP)
Now IIS and CouchDB can exist together on port 80 in happiness, as long as they both have their own IP's to listen to.
I gave an answer to following thread. but in the comment a user suggested that network admin can change the default port of http from 80 to something else.
As for as I know if I open a page eg. http://www.example.com without port that means it is running on port 80.
I just want to clarify that is it possible for network admin to change default port?
When using a browser, http://www.example.com will always try and connect to the server's TCP port 80, like it's port 443 for HTTPS connections. These port numbers (defined here) are hard coded in any browser.
Yet a web server can be configured to listen to any other port, which rarely makes sense though. If it does, the browser will be unable to connect (unless the port no. is explicitly given as in http://myserver.com:81).
This is a network programming question. I need to block all HTTP traffic using a layer 4 firewall (i.e it can look headers only upto TCP/UDP layers ). Is this possible?
As I was searching for a more accurate answer , I got to know that even if we cannot access HTTP header, we can access HTTP message field using layer 4 firewall.
No.
You can drop all TCP port 80 and port 443 traffic, but this might include traffic that isn't HTTP. (80 and 443 are open almost everywhere, so people (ab)use them often.) It will also miss HTTP traffic that happens on non-standard ports. (People do HTTP to port 8000 or 8080 or 8088 or 8888 all the time, in part because you don't need CAP_NET_BIND to be able to use high ports, in part because the numbers are easy to remember if port 80 is already used for something else.)
You can use the incoming port (ie 80) to detect HTTP traffic.
However you can't be 100% sure that's HTTP. But since it's the common port fort HTTP, I don't think many other applications use the port 80 for their communication.
If another port is used with HTTP protocol, you won't be able to block it this way, but it's a start.