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.
Related
I am trying to debug one third party mobile application, specifically network calls, When I am using fiddler and charles proxy on the first network call itself. the app shows error that client certificate on the device is not trusted and ask me to switch to mobile network instead of wifi. also when I accept the risk using the same network. The app shows that there is no internet connection.
I think the app is able to detect that the ceritificate is not the orignal client cert. and thus throwing the warning. Can I download the website or app HTTPS certificate and put it in PC as well as iPhone just like I did for fiddler root certificate.
Same issue is happening with charles proxy also.
I see that you are using an iPhone, have you looked at About/Certificate Trust Settings and enabled the full trust switch after installing the (Charles) certificate?
There are several articles on NiFi secure cluster setup and ldap integration.
After following Pierre Villard's Integration of NiFi with ldap and Bryan Bende's Authorization and Multitenancy I'm able to run a secure nifi cluster which works seemlessly from firefox browser.
But, when I access the same url from chrome, i get the following error:
Attackers might be trying to steal your information from xyz.abcd.com (for example, passwords, messages, or credit cards). NET::ERR_CERT_REVOKED
I haven't generated any user certificates because LDAP login is expected which actually works fine with firefox. Is there anything extra that needs to be done for chrome which firefox actually doesn't require? The issue has been same from all the users who are using chrome to authenticate into my cluster.
I believe Chrome after version 56 enforces stronger certificate validation. In addition, Chrome uses the OS keychain, while Firefox provides its own. So you may have marked the generated server certificate as trusted within Firefox but this would not translate to Chrome. Is there a text link below that message to go into "Advanced Settings" or similar?
Depending on how you generated this certificate, check that it has not expired, it was not actually revoked by the issuing CA, etc.
In my work computer, Firefox always gives me the "sec_error_unknown_issuer" error. This happens only on all HTTPS sites.
I have browsed Mozilla's support forums and understood that this is most probably caused by a software that performs an HTTPS scanning. The software presents its "fake" certificates to Firefox and hence, Firefox says that it does not know the issuer of these certificates.
However, I don't know which software is performing the HTTPS scanning and presenting its "fake" certificates to Firefox.
Is there a way to determine which software is performing the HTTPS scanning so that I will be able to add its certificates to Firefox and hence, be able to use the Firefox properly?
In my work computer,...which software is performing the HTTPS scanning
This is probably legal SSL interception done by a firewall in your company. If you want to know the exact software used for scanning ask your local network administrator.
... so that I will be able to add its certificates to Firefox and hence, be able to use the Firefox properly?
If you look at what certificates your server sends you have a look at the certificate details in the browser, especially at the chain certificates. But to make sure that what you get is really the companies certificate used for SSL interception and not some malicious man-in-the-middle attack you should verify your finding with your network administrator. And I'm pretty sure that if they do legal SSL interception they also help you do add the certificate to your browser - at least as long you are allowed to install alternative browsers to your computer and/or your own computer to connect to the companies network.
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'm running mitmdump (from mitmproxy) on my Macbook Pro, and I'm connecting to the proxy through my Windows desktop PC.
However, Chrome (running on the PC) refuses to connect to so many sites because of the invalid certificates which mitmproxy provides.
Chrome throws the error: ERR::NET_CERT_AUTHORITY_INVALID
Here's what mitmdump shows:
But why? What's wrong with mitmproxy's certificates, why can't it just send back google's as if nothing happened?
I'd like to know how I can fix this and make (force) my desktop PC to connect to any website through my Macbook's mitmproxy.
Answering this question for people who may find this important now. To get the proxy working, you have to add the certificate as trusted in your browser.
For windows follow this: https://www.nullalo.com/en/chrome-how-to-install-self-signed-ssl-certificates/2/
For linux follow this: https://dev.to/suntong/using-squid-to-proxy-ssl-sites-nj3
For Mac-os follow this: https://www.andrewconnell.com/blog/updated-creating-and-trusting-self-signed-certs-on-macos-and-chrome/#add-certificate-to-trusted-root-authority
There are some additional details in the above links; tldr; import the certificate in your chrome://settings url and add the certificate as trusted. That shall do.
This will make your browser trust your self-signed certificate(mitm auto generated certificates too.)
The default certificates of mitmproxy is at ~/.mitmproxy/ directory.
Per the Getting Started page of the docs you add the CA by going to http://mitm.it while mitmproxy is running and selecting the operating system that you are using. This should solve your problem and will allow https sites to work with mitmproxy.
This is the expected behavior.
mitmproxy performes a Man-In-The-Middle attack to https connections by providing on-the-fly generated fake certificates to the client while it keeps communicating to the server over fully encrypted connection using the real certificates.
This way the communication between client and proxy can be decrypted. But the client has to actively approve using those fake certificates.
If that wasn't the case then SSL would be broken - which it isn't.
The whole story is very well explained here:
http://docs.mitmproxy.org/en/stable/howmitmproxy.html