I recall the syntax of a hack when routing a request to local IIS but I cannot recall what it does. It popped up randomly in the browser during a debug session this morning and when I recognized it, I went looking for documentation on the technique to refresh my memory and came up blank.
So, if you were to enter
http://localhost:8080 and
http://localhost.:8080
into two separate browsers, what difference would you expect "the dot" to make?
I found the explanation (and when I recalled that Fiddler involved, I also recalled what the hack did)
Fiddler and IE7
It isn't related to IIS; It's a workaround for Internet Explorer to force the browser to not bypass a proxy. Since Fiddler is implemented as a proxy, http://localhost:8080 will completely bypass it but http://localhost.:8080 will not bypass the proxy, allowing monitoring tools to capture traffic.
Internet Explorer (7 and 8, I think) is written to bypass proxy servers for resolving "localhost" resources. Appending a trailing dot to "localhost" provides a valid DNS name that does not match the rules that "Old IE" uses for this bypass logic. Internally, the trailing dot gets trimmed from name resolution and you force IE to not execute its internal logic that bypasses the proxy server.
From what I understand, this was changed in IE9.
Related
As far as I know, browsers treat localhost and other domains differently. Like, not everything works on localhost. Do you know what specifically is different? What does "localhost" means in this context? Anything that resolves to 127.0.0.0/8? What about port/scheme?
As far as I know, browsers treat localhost and other domains differently. Like, not everything works on localhost.
Quite the opposite. http://localhost is considered a secure origin by many browsers, so you can do development with many features that would normally be disabled without HTTPS.
See When is a context considered secure?:
A context is considered secure when it meets certain minimum standards
of authentication and confidentiality defined in the Secure Contexts
specification. A particular document is considered to be in a secure
context when it is the active document of a top-level browsing context
(basically, a containing window or tab) that is a secure context.
For example, even for a document delivered over TLS within an
, its context is not considered secure if it has an ancestor
that was not also delivered over TLS.
However, it’s important to note that if a non-secure context causes a
new window to be created (with or without specifying noopener), then
the fact that the opener was insecure has no effect on whether the new
window is considered secure. That’s because the determination of
whether or not a particular document is in a secure context is based
only on considering it within the top-level browsing context with
which it is associated — and not whether a non-secure context happened
to be used to create it.
Locally-delivered resources such as those with http://127.0.0.1 URLs,
http://localhost and http://*.localhost URLs (e.g.
http://dev.whatever.localhost/), and file:// URLs are also considered
to have been delivered securely.
Note: Firefox 84 and later support http://localhost and
http://*.localhost URLs as trustworthy origins (earlier versions did
not, because localhost was not guaranteed to map to a local/loopback
address).
Resources that are not local, to be considered secure, must meet the
following criteria:
must be served over https:// or wss:// URLs
the security properties of the network channel used to deliver the resource must not be considered deprecated
According to the following article the special things about localhost are:
Although it's HTTP, it's generally treated as HTTPS.
You can't set a cookie on localhost that is Secure, or SameSite:none, or has the __Host prefix.
You can't reproduce mixed-content issues.
Browsers don't (Not all browsers) rely on DNS resolvers for localhost and subdomains.
And "localhost" in this context means localhost and subdomains, with or without a custom port.
I've got a requirement to detect if a webpage is being served on the internet or intranet, i.e. assuming a url of https://accessibleanyway.com, is the phone connected to the work wifi or to something else like their home wifi or the phone network?
What different ways are there to do this?
(1) Use WebRTC to get the local ip address. Not widely supported
(2) Try to access a local web page using jsonp/cors/iframe
The problem with 2 is that the webpage is https and the local resource is likely to be http which you can't do in IE afaik. If I make the local resource https then it's via a self cert which means installing CAs on the phones (can you buy certificates for the intranet anymore?)
Any suggestions?
The problem with (2) was that the same page was trying to use http and https, and even with an iframe you get issues.
What you could do instead is start on a http loading page, use an iframe to access a local resource which you can only access if you are on the intranet, jsonp will work fine for this. Once that's worked or failed, redirect to your start page with some token in the querystring to indicate that you are on the intranet or not
NB jumping from http to https would probably have some security issues if you are on the same website (authentication cookies being initially visible), but I would have thought it would be fine if you are going to a different one
Obviously there'll be some security needed around the token as otherwise the user could just generate their own but that's a different matter which depends on individual setups. It would obviously have to be generated by a server call, otherwise someone could just read the client code.
NB I think the IP address approach is never going to work as you have no way of knowing what a companies intranet setup looks like until you go there, so it's not a generic answer
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.
Having a strange issue - we have a page that uses a query string to get some information, this query string happens to contain the word set. When this happens, the page returns a 406 error (Client browser does not accept the MIME type of the requested page.)
The URL looks like example.com/folder/file.asp?variable=sunset boulevard. If I change the space to %20 it still returns 406.
On my local machine running IIS 5.x this doesn't happen, on our test server running IIS 7.x this doesn't happen, only on our production server running IIS 7.x over SSL. Note however that a self signed certificate on my local machine over SSL still doesn't produce the error.
So my question is, what does the set keyword in the URL tell IIS to do and is there an easy way to avoid it happening? I would like to avoid changing the space to a different character if possible.
Does your server have additional filters installed? Smells like the work of an agressive filter designed to prevent certain types of attack.
It took me a while to learn that I have to put a dot after the "localhost" in the URL so that I can use fiddler with my development server.
Why do I need to put this dot here to make fiddler work for my local:
http://localhost.:1888/MyPage.aspx
What does it stand for?
thanks
It's not that you're making fiddler work, but you're making Internet Explorer work. Internet Explorer is written specifically to bypass the proxy server for "localhost" . By attaching a trailing dot, you're providing a valid DNS name that does not match the mechanism within IE that checks the domain (IE does a stricmp(userdata, "localhost") or equivalant).
localhost. just makes the hostname visible to Fiddler; otherwise, IE bypasses proxies.
You can also substitute "ipv4.fiddler" for "localhost" -- which can help prevent confusion, since the dot is easy to miss.