Most of the website which use https protocol to communicate have the HTTP port of the web server in open position. Is there any need for it to be left open ?
If the website serve https, it may leaves http open to redirect requests to https: Even if the websites use HSTS preloaded, older browsers may not be aware.
Links to the websites may be (wrongly) prefixed by http://
Users can write the domain name in the url (so the browser will prefix by http://)
There is few security advantage to close the http ports for an https only website.
Related
I am injecting some script tags in a website, with source such as http:localhost:3000/css/my-page-css.css . While its working on almost all sites, there's this particular website that is somehow sending all my http requests as https. How do I handle such a case?
I have configured an https server also on my nodejs app which listens to port 8443 and http listens to 3000. But, when I inject my script tags, they have src URLS which point to port 3000. So even if I have an https configured on my nodejs app, it won't work since it would be listening to a different port.
You are using HTTP Strict Transport Security (HSTS)
Using the securityheader.com website on your URL, or Chrome Developer tools we see the following HTTP Header is sent back by your site:
Strict-Transport-Security max-age=7889238
This HTTP Header will be configured in your webserver and is a way of your webserver telling the browser "For the next 7889238 seconds only use HTTPS on this domain. If someone tries to use HTTP (either by typing or by clicking on a link) then automatically switch HTTP to HTTPS before you send it on to the server."
This is a security feature as currently the default (if a scheme is not explicitly given) is HTTP. This allows website owners to switch the default and, even strong that that, prevents it being able to be switched back.
HSTS is set at a domain level and it is not possible to have it on for one port (e.g. 443) but not for another (e.g. 3000) - it's either on for that domain or off.
If you really want to use HTTP then you need to remove this header and remove the remembered value of this header from your browser. While chrome allows you to do this by typing chrome://net-internals/#hsts in the URL and using the delete option, the easiest way to do this is to change the max age from 7889238 to 0, and then load the website again. And then remove the header completely.
This can be especially annoying for sites like localhost where you proxy requests and inadvertently set it for that dummy host name. You should see if your node proxy server allows you to strip off that HTTP header. Some might say it would be better if browser makers ignored HSTS for localhost, however I think it would be better if developers just stopped fighting HTTPS and used that even for development environments using a self-signed certificate that is added to your local trust store. This was you can avoid problems like mixed content, and also use features that are HTTPS only (including Brotli, HTTP/2, Geo Location...etc.) while developing (though some browsers like Chrome still allow these on http://localhost).
Alternatively set up a local DNS alias for each of your dev sites and use that with or without HTTPS as appropriate for the site in question.
Currently in the process of setting up a new personal server. I've been reading about HSTS (thanks EFF!), as well as the steps for implementing on Nginx (ex: here).
What I haven't seen clearly spelled out is how to handle the initial redirect. Do I serve some static error content at port 80, redirecting to the actual site at HTTPS?
A lot of what I've read so far suggests that serving from HTTP is making your site vulnerable to MITM attacks. Others seem to suggest that as long as you have the Secure flag set on any cookies instantiated, you're good. Of course, plebeian that I am, I'm not on the preloaded HSTS site list, so that's out.
What's the deal here? Should I serve port 80 and redirect for convenience of site visitors, or am I exposing them to attack?
Full-disclosure: Non-Ops by trade, and non-secure content being served, just a hungry mind with a learning opportunity.
On your site at port 80, you just respond with a 301 response code redirecting the user to your HTTPS site at port 443. The secure site then send the "Strict-Transport-Security" header.
This will still leave your users vulnerable to man-in-the-middle attacks the very first time they visit your site. You can only mitigate this by getting your site on the preloaded HSTS list.
Don't set any cookies from the insecure site and always use the secure flag when setting cookies from the secure one.
On my windows 2003 server I have two websites: 2send.co.il & oferavnir.co.il
For 2send.co.il I installed SSL.
When I adding Https to oferavnir.co.il (the site without the SSL) the other site content is displayed -
(https://oferavnir.co.il displays the content from 2send.co.il)
Host headers for both site seems to be ok.
What could it be?
By default, the SSL certificate is probably bound to all IP addresses on your server. If you have individual IPs for each site, you can update the binding to only listen on the IP for 2send.co.il. If you are using host headers and a single IP, the 2send.co.il site will respond for all https requests. You could use a product like ISAPI Rewrite to check the URL used for an HTTPS request and ensure that it matches 2send.co.il or else route it to the appropriate http site for the URL
http://forums.iis.net/t/1195794.aspx/1?HTTPS+displays+other+site+contnet
I recently moved servers and redeveloped the website at the same time. Previously all pages were served via https and I wanted to change this so only cart pages were via https. Also I wanted to clean up the url a bit. Old urls were:
https://secure.mydomain.com/onlinestore/index.php
and I removed the secure prefix and the subfolder so it is now:
http://www.mydomain.com/index.php
Problem is I wanted people who clicked on old links or bookmarks to be redirected to the new page. I got this working with htaccess. However the new SSL only covers the root domain and not the secure subdomain. So if someone clicks an old link it brings up "This Connection is Untrusted" before it can redirect. Works fine if i change https to http.
So what I want to know is if there is anyway I can force http instead of https before it checks the SSL cert.
Hope that makes sense!
The short answer is no. With conventional SSL, your web server doesn't even get to see the URL before certificate negotiation happens. It just sees a connection on port 443 and starts doing SSL negotiation. The browser then sees the mismatched cert and throws an exception.
However, more modern browsers and web servers (see Wikipedia for the list) support a TLS extension called Server Name Identification (SNI), which allows the client to send the hostname it's requesting before the server has to respond with a certificate. At that point you'll need to have certificates for both secure.mydomain.com and www.mydomain.com on that server, and it'll need to be configured to respond with the proper certificate.
how can i change my http sensitive pages to https while i don't now what is difference between http and https and how to do that
HTTPS is the secure version of HTTP:
traffic gets encrypted,
the user knows for sure that the site
he is talking to is the real deal
Depending on your webserver, you'll have to add support for HTTPS in the configuration file. For example, for the Apache Webserver, you need to edit use the mod_ssl module.