I have a website hosted via S3 and served through Cloudfront. The web requests I see coming from my domain are all served over http1.1 and not http2, even though it is checked (by default!). Are there additional tasks I need to do to be able to see my content being served using http2?
I can see in the network tab in Chrome that some assets are being loaded via http2 (resources that do not come from my Cloudfront) but everything being loaded from my Cloudfront is http1.1
Update 2
It seems as though other users are seeing my site loaded over http2 correctly, and I tried using Firefox, and see the same results. So this is a Chrome issue, not a Cloudfront issue.
This was not an issue with Cloudfront, instead I think it was combination of antivirus, network firewall/VPN, and Chrome caching. I turned off all VPN, antivirus, cleared cache in Chrome, restarted my computer and Bam! Page loads over HTTP2
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.
I understand the CSP that won't allow mixed content on Firefox and Safari, though Chrome allows it.
Is there any way to whitelist an HTTP call to http://localhost:1234 from an online website accessed via HTTPS (without modifying browser config)?
I have been looking for a way to make sure my web server is secure against a man in the middle attack. It does seem that Google Chrome and Firefox work in blocking requests to my server even if I select to advance after the security warning. I am testing this by using Charles Proxy to intercept Https traffic without having trusted the Charles Cert on my Mac.
When I run the same tests with Safari it will let me through if I chose to ignore the secure warning, which I expect a certain number of users to do. So it seems there is more configuration needed to lock down Safari traffic. I know this is possible because when trying to navigate to github.com with the same scenario I get the following message:
Does anyone know what GitHub is doing to block Safari traffic on an untrusted connection?
Looks like Safari is supporting HSTS and that github is using it. Their HTTP response contains the following header:
Strict-Transport-Security:max-age=31536000; includeSubdomains; preload
This way a browser supporting HSTS knows that for the foreseeable time this site should only be visited with https and any attempts to use http only will automatically be upgraded by the browser.
Apart from basic HSTS which only works after the first visit of the site github also adds the preload directive. This tells browser makers that github likes to be included in the preloaded HSTS list shipped with the browsers, so that the browser applies HSTS even if the site was never visited before by the user. See HSTS Preloading for more information.
I have a nodejs app with express as backend which is running on localhost. I have subdomains associated with it like user1.localhost. These subdomains are opening in Chrome but Firefox throws Server Not Found error.
Does Firefox needs some configuration to allow subdomains?
I think the reason is that Chrome resolves *.localhost to localhost internally and other browsers request DNS server for subdomain.localhost (which obviously fails). You can use hosts files to make it work for them.
The reason Chrome does this is security reasons, you can read more about it here.
I recently put my website under SSL. I've been able to adapt the website so that most of the content is under SSL, but some data, like Twitter avatars, are on an http website, so I'm receiving warnings, at least in Chrome.
Is there a policy in IIS to enable fetching non-ssl data from pages outside website's domain?
Is it depending on browser, on the source code, or on server settings?
If you insert direct HTTP links, the browser will complain (and this is correct). One of the options is to cache the data on your server and send it as "own" links for the server.
I believe it will, but the browser will complain about unsecured links usually.