I am trying to implement the "Public-Key-Pinning" on my IIS server but even when I enter a wrong hash, the page is still accessible without any kind of error (tested on google chrome)
The header is as follow
Public-Key-Pins:
max-age=90;
pin-sha256="[Hash]"
I know that it meanignless to have a "max-age" value of 90, but I am only testing the header behavior.
I used the https://report-uri.io/home/pkp_hash to generate my hash and used the Root Certification Authority
Here how I tried to make my website unaccessible for those with an invalid pin
Configure the header with a "Max-age" of 90 seconds
Navigate to the web site in google chrome
Modify the pin-sha256 of the header to put one invalid (replacing one letter)
Closing Google chrome
Navigate back to my web site
I though I would have the "invalid pin error" (I did it under 90 seconds) but nothing happen
What am I doing wrong?
Related
I'm running a Node.js server for my college final year project. It's running on my local machine and I'm accessing it via the machine's private IP address. The application needs to record a short snippet of audio and send it back to the server, which will then send back a result based on the content of the audio file. Because the browser needs access to the microphone, it has to be HTTPS, even though I am not dealing with any sensitive information or even opening it to the internet. I just need to show it working at a demonstration, which I can do on a local network.
After hours of trial and error I managed to modify my current application to use HTTPS using a self signed certificate as described here. I can now access the web page over HTTPS (albeit with a huge red "This page is not actually secure" warning that I have to accept first) and chrome will grant me access to the microphone. However, when I click the button that sends a post request with the audio, chrome gives me either
POST https://192.168.178.30:8443/notes net::ERR_CERT_AUTHORITY_INVALID
or
POST https://192.168.178.30:8443/notes net::ERR_CERT_COMMON_NAME_INVALID
I have installed the cert as a trusted root certificate as outlined here.
I set the common name on the cert as the IP address (192.168.178.30) but chrome still won't accept it, and I don't have a domain name (it's running locally).
So my question is: how do I either make a trustworthy OpenSLL certificate, or force chrome to ignore such errors. I have a day to get this working along with other aspects of the application so I ned a quick fix. This is for the purpose of a demonstration, it is not going live to the internet.
I recently got a hosting provider from US to host one of my websites. Everything is good besides the fact that when I first tested my website from my phone and tablet I got some strange warnings.
//Website format:
http://www.mywebsite.com
On the phone I got this alert:
Service www.mywebsite.com sent a certificate with a different name than the one you asked for. Accept like this?
And the detail descriptions:
WebSite:
www.mywebsite.com
Issuer:
AlphaSSL CA - SHA256 - G2
GlobalSign nv-sa, BE
Subject:
*.fcomet.com, Domain Control
Validated, fcomet.com
Key utilisation:
undefined
Valability from 08.09.2015 to 08.09.2016
Certificate format:
X.509
Algoritm:
SHA2RSA
Serial number:
//some long code here
Digital sign SHA1
//some long code here
Digital sign MD5
//some long code here
On the tablet I did not get all the message but it was something with a certificate also and some aditional text which I noted:
google-analytics.com
Google Inc
Serial number:
//some serial number here
Sent by:
Google Internet Authority G2
Google Inc
Valid from 13.07.2016 to 05.10.2016
What bothers me is that I can not reproduce this "bug" again. On my phone I pressed accept only this time but even if I enter the website again I don't get that message anymore (in order to send a screenshot to the hosting provider because he sais that I should not get this error at all). I even cleaned the cache from my mobile devices and also from my website because I use a Wordpress and I cleaned the cache from Nginx Cache, WP Super Cache and Autoptimize.
What I suspect is that the hosting provider try to make some redirects to https or something like that, I can't explain.
If I try to enter on my website using https I get this message:
Your connection is not secure
The owner of www.mywebsite.com has configured their website improperly. To protect your information from being stolen, Firefox has not connected to this website.
If I press Advanced button I get some detalis:
www.mywebsite.com usses an incorect security certificate
The certificate is valid only for this names:
*.fcomet.com, fcomet.com
Error code: SSL_ERROR_BAD_CERT_DOMAIN
If I add and confirm the exception I will be redirected successful to https://www.mywebsite.com, a blank page with this text Index of /. This seem strange because on any other website I enter and try to change the http protocol to https I won't be alowed to access the website with https protocol.
I also tried to test my website here and here but it does not work, I get a white page. If I test with any other website, I get the website content. Mabey this will help you to understand what is the problem.
Does somebody have any ideea what is the problem here and how can I solve this? Thanks
I have a site which is completely on https: and works well, but, some of the images served are from other sources e.g. ebay, or Amazon.
This causes the browser to prompt a message: "this website does not supply identity information"
How can I avoid this? The images must be served from elsewhere sometimes.
"This website does not supply identity information." is not only about the encryption of the link to the website itself but also the identification of the operators/owners of the website - just like it actually says. For that warning (it's not really an error) to stop, I believe you have to apply for the Extended Validation Certificate https://en.wikipedia.org/wiki/Extended_Validation_Certificate. EVC rigorously validates the entity behind the website not just the website itself.
Firefox shows the message
"This website does not supply identity information."
while hovering or clicking the favicon (Site Identity Button) when
you requested a page over HTTP
you requested a page over HTTPS, but the page contains mixed passive content
HTTP
HTTP connections generally don't supply any reliable identity information to the browser. That's normal. HTTP was designed to simply transmit data, not to secure the data it transmits.
On server side you could only avoid that message, if the server would start using a SSL certificate and the code of the page would be changed to exclusively use HTTPS requests.
To avoid the message on client side you could enter about:config in the address bar, confirm you'll be careful and set browser.chrome.toolbar_tips = false.
HTTPS, mixed passive content
When you request a page over HTTPS from a site which is using a SSL certificate, the site does supply identity information to the browser and normally the message wouldn't appear.
But if the requested page embeds at least one <img>, <video>, <audio> or <object> element which includes content over HTTP (which won't supply identity information), than you'll get a so-called mixed passive content * situation.
Firefox won't block mixed passive content by default, but only show said message to warn the user.
To avoid this on server side, you'd first need to identify which requests are producing mixed content.
With Firefox on Windows you can use Ctrl+Shift+K (Control-Option-K on Mac) to open the web console, deactivate the css, js and security filters, and press F5 to reload the page, to show all the requests of the page.
Then fix your code for each line which is showing "mixed content", i.e. change the appropriate parts of your code to use https:// or, depending on your case, protocol-relative URLs.
If the external site an element is requested from doesn't use a SSL certificate, the only chance to avoid the message would be to copy the external content over to your site so your code can refer to it locally via HTTPS.
* Firefox also knows mixed active content, which is blocked by default, but that's another story.
Jürgen Thelen's answer is absolutely correct. If the images (quite often the case) displayed on the page are served over "http" the result will be exactly as described no matter what kind of cert you have, EV or not. This is very common on e-commerce sites due to the way they're constructed. I've encountered this before on my own site AND CORRECTED IT by simply making sure that no images have an "http" address - and this was on a site that did not have an EV cert. Use the ctrl +shift +K process that Jürgen describes and it will point you to the offending objects. If the path to an object is hard coded and the image resides on your server (not called from somewhere else) simply remove the "http://servername.com" and change it to a relative path instead. Correct that and the problem will go away. Note that the problem may be in one of the configuration files as well, such as one of the config.php files.
The real issue is that Firefox's error message is misleading and has nothing to do with whether the SSL is an EV cert or not. It really means there is mixed content on the page but doesn't say that. A couple of weeks ago I had a site with the same problem and Firefox displayed the no-identity message. Chrome, however, (which I normally don't use) displayed an exclamation mark instead of a lock. I clicked on it and it said the cert was valid (with a green dot), it was a secure connection (another green dot), AND had "Mixed Content. The site includes HTTP resources" which was entirely accurate and the source of the problem (with a red dot). Once the offending paths were changed to relative paths, the error messages in both Firefox and Chrome disappeared.
For me, it was a problem of mixed content. I forced everything to make HTTPS requests on the page and it fixed the problem.
For people who come here from Google search, you can use Cloudflare's (free) page rules to accomplish this without touching your source code. Use the "Always use HTTPS" setting for your domain.
You can also transfrom http links to https links using url shortener www.tr.im. That is the only URL-shortener I found that provides shorter links through https.
You just have to change it manually from http://tr.im/xxxxxx to https://tr.im/xxxxxx.
I'm using SSL on my website and it is giving me the lock with yellow triangle icon ("The site uses SSL, but Google Chrome has detected insecure content on the page.")
On clicking the lock icon it says:
Your connection to domainname is encrypted with 256-bit encryption. However, this page includes other resources which are not secure. These resources can be viewed by others while in transit, and can be modified by an attacker to change the look of the page. The connection uses TLS 1.0. The connection is encrypted using AES_256_CBC, with SHA1 for message authentication and DHE_RSA as the key exchange mechanism. The connection is not compressed.
How do I ensure I get the green lock?
You must have resources (images, stylesheets, scripts, etc...) which are embedded on the page but are not served over https. Make sure all your resources are served over https, and that warning should go away.
I had the same problem and it occoured because I included a script from Google Analytics using HTTP.
With a provider like Google, one can simply change HTTP to HTTPS - and it will work. This will not work with all providers.
If you are trying to load something from a website that you own, you will have to secure that website with HTTPS.
Google Chrome will detect this and automatically not load the insecure content (from the HTTP domain) which may take away some functionality from the website.
Certain AV/Malware softwares will also detect this and give a security warning which may frighten your visitors away.
If you are using Google Chrome, then you might not notice such a warning, because the AV/Malware software never sees this HTTP-link because it is blocked by Google Chrome.
And if you do not have the kind of AV/Malware software that detects this then you may never notice such a warning while the visitors are.
What you must do is:
Install Google Chrome and go to the website.
Click on "Tools >> JavaScript Console" and see if any warning appears. (this has been commented by Brad Koch on the question as well)
Go throught the different pages on your website and see if any errors appear - if so, then go change the URLs to HTTPS (if this is possible) or find another provider for this javascript.
make sure all references to resources such as images, js files, css files, ads, etc are served through https. If the uri to the resource is relative, e.g. /images/logo.png, then the resource is fetched from the same host and port and protocol as the page itself, in your case https. I would use fiddler to find what files get fetched over http:// when the page is loaded.
This is what I get when I go to TOOLS and then click on JAVASCRIPT CONSOLE ::
Failed to load resource chrome://thumb/https://accounts.google.com/ServiceLogin?service=chromiumsyn...
s%3A%2F%2Fwww.google.com%2Fintl%2Fen-US%2Fchrome%2Fblank.html%3Fsource%3D1
Failed to load resource chrome://thumb/http://www.xe.com/
What do I do after this?
Working on troubleshooting an interface consumed by 3rd parties. The quick overview:
3rd party sends the user out our site example.com/login to let the user authenticate with us
After signin we redirect the user back to thirdparty.com
thirdparty.com consumes a dynamic JS file on our site used to return information about the logged in user example.com/dynamicJs.js
Since this request is made against example.com it should include the cookies dropped during login (they are required for it to serve its purpose)
for IE, they are no longer being included in the request
In researching:
the cookies themselves don't appear to have changed, and manually navigating IE to the URL of dynamicJS.js results in the necessary cookies being transmitted.
example.com has P3P policies in place and is not generating any visible warnings/errors with IE
other browsers include the cookies
So, what other variables could be influencing IE and resulting in it omitting the example.com cookies when loading example.com/dynamicJS.js?
After much research we identified the root of the issue was within IIS's Custom HTTP Response Headers.
Previously we had configured the site to return a P3P header, but in diagnosing this issue we found that somehow the header was now being returned as 3P. Returning the key to P3P resolved out issue.
In researching the actual cause of this change we found that the bad header originated in the web.config, within the <httpProtocol><customHeaders> element -- however it appeared to have been placed there some time ago and remained dormant until the AppPool was stopped/restarted for maintenance.