At the company where I work, we have a web proxy and the browser prompts for login/pass every time I open it. After seeing this, I installed squid in my computer, configure my company web proxy as a parent cache in my squid.conf (with my login:password).
I set my browser settings to use my IP as the web proxy.
The problem is: when I visit some sites (it doesn't happen to every site), I'm prompted for user/password, even though I haven't configured squid to ask for authentication. I can click "cancel" and continue visiting the site without typing my credentials.
AFAIK, I wouldn't have to type my credentials, as my squid isn't configured to authenticate the user (at least I'm thinking it's not).
Why does this happen? How can I turn this prompt off? How can I configure my squid for not ask credentials? Thanks in advance.
My squid.conf is:
acl all src all
http_port 3128
http_access allow all
cache_peer 10.20.0.100 parent 3128 0 no-query default login=username:password
never_direct allow all
Well, after some tests with another browser, I found out that only Firefox (among those browsers I've tested) prompted for credentials. With that in mind, I think the "problem" is not Squid. If someone is experiencing this with Firefox, try changing the browser and see whether the problem keeps or not.
I hope this can help someone else.
EDIT: I made some tests with Chromium and Konqueror (besides Firefox). None of them prompted for credentials.
Related
I have a website hosted on IIS which can accessed across the Local Area Network by using the IP address of the Server computer. But I can only access the website on client computers using http, when I use https I get security alert on the browsers as shown in the image below,
I even got a self signed certificate on the server computer and in the server computer I can use https without any security alert but I can't do the same on client computers on LAN. Is it possible to achieve that? If so please let me know. Thanks in advance :)
Your certificate is not trusted by other computers, because they don't recognize you as a trusted authority, the solution is easy, even if you ask google it will respond with steps to do this (for chrome in this example):
Go to Chrome Settings.
Click on "advanced settings"
Under HTTPS/SSL click to "Manage Certificates"
Go to "Trusted Root Certificate Authorities"
Click to "Import"
There will be a pop-up window that will ask you if you want to install this certificate. Click "yes".
Better idea maybe, instead of making them trust your self-signed certificate would be to generate a certificate by some verified authority.
I have recently generated a free certificate by the https://letsencrypt.org/ portal (and no, I do not have any interest in promoting it) except it's free and it simply works fine.
I have fiddler set to decrypt https request. But for some reason, the site I'm trying to check, always fail when I set it to decrypt "from all processes".
The decrypt https only seem to work with that option - as I get the "tunnel to" stuff, so it's my only choice to see the encrypted contents.
Any way to fix this - or know what's wrong with it? I can't find anything that explains what might be wrong. I know for a fact, it was working a few days ago. If the ssl cert was changed for the site - might that be the problem?
What does always fail mean, specifically?
What browser or client are you using?
Have you configured Windows to trust Fiddler's root certificate?
No, Fiddler doesn't care about the remote site's certificate, unless the remote certificate is invalid and you click the Don't continue button shown in Fiddler.
We have deployed our website to the live webserver, Windows Server, IIS 7.5. Website asp.net, .NET 4.5
I have configured the website bindings to allow https requests for this website.
Asked the hosting provider to open up the port 443.
I can access the website over internet with port 80, no issues at all. (http://mysite.com)
But I can not access via https, (https://mysite.com).
But I can access the site via SSL from the server itself, that means SSL configurations are fine.(https - localhost)
But I can telnet (telnet mysite.com 443), it responds to GET request via telnet.
I have rechecked the certificate and changed it to a self-signed certificate, issue is still there.
These requests not being tracked in IIS logs as well, seems like the request is not reaching IIS. Hopefully something goes wrong before it reaches the server.
But, when I access the website as http://mysite.com:443, it works.
I m bit confused with this behaviour. Obviously the port 443 is open by the hosting company. But something is wrong with requests over HTTPS, which is supposed to send a request to port 443. Please help.
Because your site is working when you access http://mysite.com:443, I am almost sure that you created wrong binding on IIS. Instead of selecting https from combo box you selected default http.
There is a tutorial on how to do this on youtube: Changing IIS 7.5 Bindings by David Johnson
You've establish that the port is open and the hostname binding is there, otherwise http://mysite.com:443 would not work. Its the SSL part that's not working, hence you can connect directly by port and telnet (port 443 but not SSL) but not a browser via https. It's only a browser connecting to a https url that will expect SSL.. I'm pretty sure I've had the same issue, but cannot recall the exact cause but it was definitely related to an invalid SSL configuration or SSL binding.. The behaviour was like there is no connection, nothing, which is unusual, its the bad config causes the browser to abort the connection. If I remember what, I'll update or comment below.
So you can access the site using https://localhost? Your question is not quite clear on this point... what is the exact URL you are using? If it's https://localhost, that is actually an indication that your certificate is configured incorrectly. You seem to be interpreting this as an indicator that it's working OK and that is not the case. The domain name is tied to the certificate and SSL will work only when accessing the site using that domain name. So if it works for "localhost", something is wrong.
Finally I found the solution. Issue was a setting in the load balancer of the hosting provider. I have asked the question from them and they have figured out the issue. Anyways it was a good learning curve for me. And this knowledge is going to help others.
The firewall was already allowing both HTTP/HTTPS, which is why we could telnet through and run a GET / and still pull down content from the 404 page of the IP address.
It appears there was a certain profile applied to the HTTPS configuration in the load balancer which would only work for HTTP, so they have disabled that.
When they set this up for HTTP and HTTPS they were not able to test HTTPS, because to do so would require an SSL certificate in IIS - which it appears we have already provided.
Thanks everyone for your help on this!
How do i check the client browser SSL certificate in my ASP.net code behind
I want to ensure that if any https proxy like fiddler is running then my application does not load
I have done the following till now without any success:
My site is on Https
In IIS i have set
Require SSL= true
Require 128 bit encryption =true
accept certificate = true
in my default.aspx Page_Load i am trying to read the value of Request.ClientCertificate, the collection is coming as empty.
There is no way to do what you're trying to do unless you run an ActiveX control on the client.
Internet Explorer and other browsers do not expose the server's SSL certificate information to the JavaScript in the page, meaning that there's no way for your page, running on the client, to know whether or not it was delivered with your certificate or another certificate.
Having said that, even if such a method was offered, it probably wouldn't help you anyway. Presumably, you want to do this to prevent viewing/modification of your traffic, but there are other tools that plug into the browser directly (post HTTPS-decryption, pre HTTPS-encryption) that can view/modify traffic without resigning it as Fiddler and other proxies do.
Furthermore, your code would fail in corporate environments where the edge proxy (e.g. BlueCoat, Forefront) does content-inspection using the same mechanisms that Fiddler uses.
Are you expecting the client to have a certificate installed? Most users do not have client certificates installed.
Nonetheless, I'm not sure how exactly a client certificate is going to protect you in the situation you describe...
I'm setting up a (ASP.NET) website to be used internally at my company. In IIS, I've turned on Integrated Windows authentication and turned off anonymous access. Once I've done this, the website pops up the "enter your username/password" box whenever you visit the site, but won't log you in even if the username/password are correct. This happens even if you're logged in to your computer with a domain account as opposed to a local account.
However, if I enter the IP of the site in my hosts file, the site works perfectly (logs the user in without the additional challenge).
I guess I have two questions.
1) Why does the hosts entry have this affect?
2) How can I get the site to succeed without a) forcing everyone to edit their hosts file or b) the site challenging them and failing to log them in?
EDIT: I checked, and we do have our DNS server set up to point those URLs to the correct servers. That's why pinging the URL displays the right IP. However, it appears that in addition to having that DNS entry, we also have to have the hosts file entry for the site to work.
You probably are having an issue with Kerberos authentication.
Since you're using a url of Site.DomainName.com, I'm assuming DomainName.com is your AD's name also.
On the server that's running IIS, copy SetSPN.EXE from the resource kit tools and run the following:
setspn -A http/site.domainname.com IISServerName
Where SITE is your URL and IISServerName is the name of the server.
This sure sounds like a dns problem. Does the dns server know about the hostname you are using? Sounds like the dns server does not know the forward lookup (hostname to ip) for the host you are trying to connect to.
We recently set up an intranet site with windows authentication here. The network guys setup a group policy and pushed changed to IE and Firefox.
For IE, it added the site to "Intranet Sites" and for Firefox it modified the configuration file so that our intranet..com would be trusted.
So... we got it to work. Here's what happened.
While looking around at the DNS Manager on test.DOMAINNAME.com, my coworker noticed that a different site on the same server was set up as a "Host (A)" entry, whereas the site we were working on was set up as an "Alias (CNAME)" entry. Several other sites on that computer were also set up as Alias entries, and he mentioned that the one site with the Host entry was "rock-solid", and he'd had sporadic issues with at least one other site that was set up as an Alias.
We talked to the AD/DNS admin, and as a test, he switched our entries from Alias to Host, and once we cleared our local DNS caches, it worked perfectly (without requiring entries in our .hosts file).
So the question still sorta stands. This was a Win2k3 box serving as one of three internal DNS servers, and making this modification fixed our problem. If anyone can add any additional information, we'd be very grateful, but in the meantime, we're debating going back and fixing all our other sites.