This question already has answers here:
What is point of SSL if fiddler 2 can decrypt all calls over HTTPS?
(3 answers)
Closed 7 years ago.
I have just discovered that Fiddler can decrypt HTTPS traffic.
For instance, I deployed a website on localhost using HTTPS. When inspecting the data packets in Fiddler, I was able to view all the information since it has an option to decrypt it.
My question is, why make use of HTTPS when Fiddler can easily decrypt it?
Fiddler performs a MITM technique.
To make it work, you need to trust its Certificate:
http://www.fiddler2.com/fiddler/help/httpsdecryption.asp
If you don't, it won't decrypt anything...
how can Fiddler2 debug HTTPS traffic?
A: Fiddler2 relies on a "man-in-the-middle" approach to HTTPS
interception. To your web browser, Fiddler2 claims to be the secure
web server, and to the web server, Fiddler2 mimics the web browser.
In order to pretend to be the web server, Fiddler2 dynamically
generates a HTTPS certificate.
Fiddler's certificate is not trusted by your web browser (since
Fiddler is not a Trusted Root Certification authority), and hence
while Fiddler2 is intercepting your traffic, you'll see a HTTPS error
message in your browser [...]
In order to decrypt HTTPS traffic you must first install the Fiddler's root certificate in to your "trusted/root certificates" list. Fiddler's root certificate is NOT a Root certificate which by default comes with your Operating System. The OS will usually warn you when you're trying to install this.
In doing so, you explicitly begin to trust any certificate signed by Fiddler's root certificate. When you now make a https request, Fiddler will perform a Man in the middle attack with you.
Suppose you make a request in the form https://google.com. Fiddler will now act as the actual Google server and will create a dummy certificate for Google.com and sign it using Fiddler's Root certificate. You will receive this dummy certificate which has been signed by Fiddler. This certificate will pass your device's validation since Fiddler's Root certificate is now in your trusted certificates. Now, your device will start communicating with Fiddler through a secure HTTPS connection. Fiddler will relay your messages to Google.com and back to you. Of course Fiddler will able to decrypt them.
It is to note that the traffic from Fiddler to Google will occur through a second Secure https channel.
Therefore, not to worry about the security provided by https.
Related
Short story
I'm trying to send a POST request from a PL/SQL script using the utl_http utility in Oracle. I've been able to send the request using http, but not https. I've added what I thought was the necessary certificates to a Oracle Wallet, and I believe they are being imported and used (but in all honesty, this is a little hard to verify). My current assumption is that calls from our DB server are passing through a proxy server, and that that is somehow messing up some part of the https / certificate functionality.
Supporting evidence (possibly?): I tried to make calls (POST requests) to a dummy service at webhook.site. Again, I got this working with http, but not https - the latter results in a cert validation error.
I then tried to replicate the behavior using postman, and that basically produces the same result, unless I fiddle around with the settings:
Initial Postman result:
Could not get any response
There was an error connecting to https://webhook.site/950...
Disabling SSL verification
Under the Post man settings, I turned off SSL Certificate Verification, and tried again. This time, I got a 200 OK response, and confirmed that the webhook received the post request fine.
It seems clear that the error is due to a missing cert, but I can't figure out which, or how to configure it. My assumption is that if I can get this to work for a webhook-url from Postman (without disabling cert verification), then I should also be able to get it to work from PL/SQL later.
When I look at the webhook site in a browser and inspect the certs, the webhook cert is the lowest cert (leaf node?). Above it there is one intermediate cert related to the company I'm working for, and then a root cert also related to the company. The root node is named something like "Company Proxy Server CA" - So I'm assuming the proxy somehow manipulates my requests and inserts it's own cert here.
I've tried downloading all of these certs and importing them into my cert store, as well as importing them under the Postman settings (under Certificates) in various combinations, but nothing seems to make any difference; all attempts at posting with HTTPS produces the following error in my Postman Console:
POST https://webhook.site/9505...
Error: unable to verify the first certificate
Any ideas about how to resolve this, or at least obtain more information about what to do would be greatly appreciated.
Switching OFF "SSL Certificate Verification" in Postman only means that it (i.e. Postman) will not check the validity of SSL certificates while making a request. Meaning that it will just send the certificates as they are. Because your connection fails if the setting in ON, this means Postman cannot verify the validity of your certificates.
This is most likely the case with the actual service you're trying to POST to, they cannot verify the certificates. Is that service outside your company network? And is it a public one or one owned by your company? Where is that service hosted? What certificate do they need?
BTW, TLS client certificates are sent as part of establishing the SSL connection, not as part of the HTTP request. The TLS handshake (and exchange/validation of client and server certificates) happens before any HTTP message is sent.
I'm thinking this might be a blocked port issue.
You said... ""Company Proxy Server CA" - So I'm assuming the proxy somehow manipulates my requests and inserts it's own cert here."
That means your client software needs your Company Proxy Server CA in its trusted certificates list. If that client's list is that of the oracle wallet...
https://knowledge.digicert.com/solution/SO979.html
This talks about how to do that.
Also, if your system running postman has a non-oracle based wallet trusted certificate (probably the operating system?) you'll have to execute something like adding the trust to your account on the workstation
https://www.thewindowsclub.com/manage-trusted-root-certificates-windows
in order to have the proxy server certificate trusted.
Once the certificate you're making the connection with has a root of trust per the effective configuration of the client being used, then you'll be able to verify the certificate.
A couple of possible issues:
The server doesn't actually support HTTPS. Connect a browser to the URL that you POST to, and see if you receive a response. (It looks like you already did this, but I'm documenting it for completeness.)
The server uses the Server Name Indication (SNI) extension to determine what certificate chain to send back, but your POSTing client doesn't send that extension. You can identify this case by looking up the IP for the host you're POSTing to, then going to https://nnn.nnn.nnn.nnn/ (obviously use the IP here, instead of the literal string 'nnn.nnn.nnn.nnn') in your browser, and checking the certificate chain it returns. If it is not the same as you get from step 1, this is your problem, and you need to figure out how to either get SNI support in your Oracle PL/SQL client or get the POST endpoint exposed on that hostname. (alternatively, you might be able to use these certificates to prime your Oracle Wallet, but they might have an issue with the hostname in the certificate not matching the hostname you connect to.)
You have a proxy in the way. I don't think this is what's going on, since that would basically only cause problems if you were doing client-side certificate authentication. (If this is the problem or is a condition, you need to import those certificates into your trusted wallet; you also need to ensure that the server you're posting from is going through the same proxy. Otherwise, you need to ensure that the certificate authority for the proxy that the machine actually running the code sees is in the wallet. This may require the assistance of the system/network administrators who run that machine and its connection to the network.)
HTTPS is a finicky beast. Many, many things must work exactly correctly for TLS connections to work and the certificates to correctly verify (the TLS port must respond, the client and server must agree to speak the same version of TLS, the client and server must agree to use the same cipher combination, the certificate chain presented by the server must be issued by a CA the client recognizes, and the leaf certificate in that chain must certify the name client requested).
SNI is needed to support multiple names on a single host without messing with the certifications of other names on the same host. Unfortunately, SNI is one of those things that has been standardized for over a decade (RFC 3546), but many enterprise-grade softwares haven't implemented.
By a sniffer (Fiddler), I can check out the stream sent through my PC to network. Surprisingly, I found when I log in google's account (https), the password is sent in a clear text, e.g.
POST https://accounts.google.com/ServiceLoginAuth HTTP/1.1
...
Email=abc#gmail.com&**Passwd=12345678**
My question is: why the password is passed without encryption even with a https protocol?
HTTPS encrypts the entire request and response.
However, you're telling Fiddler to decrypt using an untrusted root certificate.
In other words, you're MITMing yourself, and telling the browser to ignore the untrusted certificate.
No, the password is not sent without encryption to Google as clear text. Google is using SSL, don't worry. But you installed Fiddler on your PC. When you did so, Fiddler registered a specific root level certificate on your computer and is able to decrypt the traffic between your web browser and the internet. By installing Fiddler, you explicitly granted this application the possibility to decrypt the traffic. So, yeah, anyone able to get administrator access to a PC is able to install a root level certificate to this PC and consequently is able to decrypt all traffic between this PC and the internet. What did you expect? How do you think trojans work?
But any man-in-the-middle attacks won't work because they won't be able to decrypt the SSL traffic between your web browser and the internet.
Someone please please tell me this is not correct. Reading this link, seem like one can de-crypted https traffic via fiddler. Does it mean if I am doing online banking via https, someone who can intercept this traffic can read my account and pin key information?
Fiddler requires you to install a special SSL root certificate for it to be able to listen to HTTPS traffic. Once you install it, Fiddler can install itself as a proxy (middleman), faking that it's every HTTPS site on the Internet. In short, yes, it can listen to everything over HTTPS, but you need to manually install the certificate on your machine first to allow it.
In theory, any root certificate you install on your machine - Fiddler or not - will allow the person generating it to impersonate any Internet site, so never do it without considering the ramifications.
In SSL terms, what Fiddler does is that it installs itself as a certificate authority on your machine. When you access a HTTPS site for which it is acting as middleman, it quickly generates a certificate claiming to be the site in question. Since the root certificate is on your machine, it will trust Fiddler's certificate and happily let it decrypt everything.
Fiddler will act as a Man in the Middle, using its own SSL certificate, and thus triggering browser warnings. If you are suitably deterred by those warnings, nobody will snoop on your online banking sessions.
For more on how this works, you can read about public-key cryptography.
You have to accept the ssl certificate issued by fiddler but yes you can monitor ssl traffic with fiddler. If you dig a bit deeper there are more sophisticated tools for MITM attacks like: https://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
I've been playing with the twitter API for an iPhone test application, and I've missed the ability to proxy the requests I did to the twitter API with a software like Charles (http://www.charlesproxy.com/). Even though it has a SSL Proxying feature, twitter seems to not like the fact that there's a different certificate in the middle signing the requests.
Is there any way to do this? I'd be very useful to be able to see the requests and the way Charles formats the JSON responses, etc...
Twitter can't know that there is a man in the middle. I've not used Charles, but I've used Fiddler2. Try that one.
http://www.charlesproxy.com/documentation/proxying/ssl-proxying/
http://www.fiddler2.com/fiddler/help/httpsdecryption.asp
Decrypting HTTPS works by the proxy making its own certificate, and giving it to the browser. The browser will notice it connects with a bad certificate and give a warning, but the server (Twitter) will just see the proxy as another browser. The proxy-server connection uses Twitter's certificate, so it's still secure.
Perhaps this is your problem:
Q: Can Fiddler intercept traffic from Apple iOS devices like
iPad/iPhone/iPod Touch and Android devices? A: Yes, but these devices
may not be compatible with the default certificates Fiddler generates.
To resolve the incompatibility, you may replace Fiddler's default
certificate generator with one that generates certificates containing
flags (e.g. AKID, SKID) that are compatible with these platforms.
Simply download and install the new Certificate Maker and restart
Fiddler.
I am planning to implement a small standalone program that will make a https request to a server. Does that require a valid ssl certificate in the client? How does the SSL handshake work in that case? Are there any security issues in the client not have an SSL certificate?
Apart from encrypting the network traffic, HTTPS is normally used to authenticate the server. That is, to give clients reassuring information about who owns the server, etc. For that to work, the client needs to inspect the trust chain in the certificate published by the server. For that to happen automatically, the client machine should have a certificate installed that describes a Certification Authority that issued the server's certificate. Normally such certificates are found on your machine in a store called "Trusted Root Certification Authorities" and most OS come with a set of common CAs already installed.
In addition, many web servers offer a feature where the client can authenticate itself to the server by supplying a client certificate. The web server is able to inspect the certificate coming from the client and map it onto a set of permissions on the server. This "client authentication" is not necessary for a working HTTPS session however, it's just an option.
In short, you don't actually need any certificate on the client, but you will probably want to have a root CA certificate in order to validate the server's identity. If you don't have that certificate it will be impossible for you to trust the server (unless you have another good reason to do so), but you might choose to exchange data with it anyway.
If you wish to learn more about the HTTPS handshake and what is negotiated, i fully recommend you look at this excellent write up at moserware
http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html
A client certificate is required only if the server requires one. A client certificate allows the server to authenticate the client, but this is only useful if the server has a list of all authorized clients. That's generally not the case with a web server, so it's quite rare for them to require client certificates.
When present, the client-side certificate does not affect establishment of the secure channel. (Only the server's certificate is required for that and adding a client certificate into the mix doesn't change the process.) Once a secure channel is established, the server will use the client's certificate the authenticate the client (generally by comparing the client's public key or name with a list of authorized clients).
You dont need a certificate to make a HTTPS connection, but you do need to if you want to know with whom you are communicating.