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.
Related
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!
Basically, I'm using a remote object that access to a secure EndPoint. This
EndPoint is located into my server. It means that my channel is a
SecureAMFChannel. If I accept the certificat by going directly to this URL with
my browser, then I'm able to run my flex application and to exchange some data.
However, if I'dont go to this url to accept the server's certificat, and launch
my Flex application, the remoteObject is not able to accept the certificat. And
of course, any information can be exchanged.
My problem is, how to accept automatically a certificat in a Flex application.
Do I need to configure something to accept it? Maybe my manipulation is not
correct.
My certificat is self-signed, do you think that this problem could be solved by buying a Certificat signed by a CA?
Could you tell how to solve this?
Thank you very much,
Bat
You can't accept a self-signed certificate in Flex. The Flash Player trusts only those CAs that are trusted by the browser.
So, either add your own CA which you used to sign your certificate to the trusted CAs of your browser or buy a certificate from a well known CA. I'd strongly advise you to do the latter since using self-signed certificates is more or less as insecure as using no SSL/TLS at all.
I have some knowledge on my question but not exactly. What exactly programatically happening after http request?
Scott Hanselman said in one of his blog posts:
Describe, in as much detail as you think is relevant, as deeply as you can, what happens when I type "cnn.com" into a browser and press "Go".
My question is exactly this,
That's like asking "describe how to perform a coronary bypass". Yes, one can explain how, but one is better first studying medicine and learning about the basics, before starting with specific procedures. However, in bulletpoints:
Your browser will want to know the IP address of cnn.com. It doesn't do DNS lookups itself, but rather asks the operating system.
Your browser will connect to that IP address on port 80
Your browser will send a HTTP GET request
The webserver will reply with statuscode 200 and the body contents
Your browser will parse the HTML
In the HTML, other resources (images, scripts, css-files...) might be included, which the browser will also fetch.
After the browser is done, it will close the connection. If it doesn't, the webserver will.
Browser tries to resolve the name cnn.com into its ip address.
Browser TCP connects to cnn.com's ip address on the default HTTP port (80)
Browser sends a GET request to the server, asking for the / page
Browser says that it's trying to connect to "cnn.com" (cnn.com and bbc.com could be hosted on the same hosting company, with the same IP address)
Browser also says what's your browser, browser engine, browser version, operating system and the plug-ins that you have installed.
Server sends a header saying what's coming on your reply, the kind of data you're going to receive (in this case, HTML), and the size of the response if it's available.
Server closes the connection if there isn't any keep-alive instruction from the browser. Otherwise it will use this opened connection to ask for other things that might be needed (images within the page, for example.)
By the way, download and install Wireshark if you want to go deep and see what's really going on behind the curtains.
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...
In a testing environment, I self-signed a cert and installed it on a web site in IIS 6. This is using .NET 2.0. Cert seems fine (minus the fact that client services don't fully trust it as one would expect). I can do whatever I want to by hitting the site locally from the server on HTTPS or HTTP.
The problem is coming in when accessing this site remotely. If the page has an exception on it, the connection drops. Not return an error, but just flat-out drops, where the browser says it couldn't find the site (this is after it churns for a few seconds, where I can see TCP traffic from the client IP coming in).
The interesting part is that I can create a blank ASPX page, with nothing on it, and it's fine over HTTPS. But the minute I put throw new Exception(); on the page, it goes back to dropping. By the way, it seems to act completely normal if I hit the same page using HTTP instead.
So I'm a bit stuck. Anyone seen something like this?
My first inclination is to go after the proxy/firewall rules between my remote client machine and the server, but I want to make sure it's not something I could fix before I bug other teams.
EDIT ...looks to be a firewall whitelisting problem. Others on my subnet have the same problem, but people in other locations can hit it just fine.
This is not a proxy or firewall issue, because the Yellow Screen Of Death is just text which transmits through any firewall just fine. Here are a couple things that I would try first.
Make sure that the fact that you are using HTTPS isn't the root cause of the problem, such as the problem isn't caused in your program, by handling HTTPS. Such as some special handling of Error code.
Create a new cert and see if the same issues occures.
Try to reproduce this issue on another machine, it could just be a configuration issue.
Try getting a real cert from GoDaddy, they are only 29.99.
That is all that I can come up with right now. One thing that you didn't mention was which version of IIS you were using, which will be helpful.
Have your thrown the exception and then tested the page using regular HTTP? Is the same thing happening, or does it only happen if you throw an exception and access it using HTTPS?