I am intercepting HTTPS requests of android apps in my phone through Fiddler for pentesting purpose. I have installed fiddler certificate in my android phone, so that I can intercept HTTPS request.
My question is that, I can see the HTTPS requests from and to my phone in clear text in Fiddler. So, is it a bug of an android app or is it normal to see HTTPS request in clear text ?
please help I am new in pentesting world :)
It doesn't sound like anything is wrong.
HTTPS is HTTP wrapped in an encrypted tunnel created using the Transport Layer Security (TLS) protocol (which in many contexts is synonymous with SSL). It sounds like you're installing the Fiddler Certificate Authority certificate on the phone. By doing this, you're telling the phone: "Fiddler is allowed to generate new TLS certificates for any host". The phone should then be perfectly happy to accept a TLS certificate generated by Fiddler rather than the actual app's TLS cert, Fiddler can therefore intercept the HTTPS traffic, intercept it and pass it upstream. In the real world it would be infeasibly difficult for the attacker to install a CA certificate on a target's phone, thus the attacker would be prevented from intercepting and reading the HTTPS traffic.
It is possible to force an application or user agent to only accept a given certificate (this is called certificate pinning). It's also possible to force an application to only use HTTPS (HTTP Strict-Transport-Security). There are other relevant controls but these are probably worth looking into.
In the mean time, check out https://en.wikipedia.org/wiki/Certificate_authority.
Related
I'm trying to redirect all insecure HTTP or HTTPS requests on my IIS Server(e.g. http://example.com/file/file1.txt) to FILE (file:////example.com/file/file.txt).
Is it possible to do this somehow?
I tried through IIS Rewrite, but Chrome writes an error - UNSAFE_REDIRECT and does not redirect.
I am not sure how you distinguish insecure HTTP/ HTTPS requests.
Generally, using of file:// protocol is not recommended due to security reasons while giving the response for the request that comes to your site which is hosted on the webserver.
If you redirect the request on your system using the file:// protocol then it could leak confidential data and someone could misuse it. They could try accessing other files on your systems and it could also lead to other unwanted issues.
By default, Chromium browsers will not allow using File:// protocol from your site and it will give you errors.
Please refer to this helpful answer.
As a workaround, you could create a virtual directory in the IIS and map the folder with it. Then you could access it using the HTTP or HTTPS protocol.
For more information, please refer to this answer.
I have started developing a web app using React.js that serves as the front-end for a bigger project. Cutting to the chase, my issue is that I cannot find a way to communicate with a secure (https) API. This is running locally, and since my organization has self-signed certificates the browsers do not accept them. Namely, Chrome, Firefox, Edge, and Opera were used, with all of them resulting in more or less the same error: NET::ERR_CERT_COMMON_NAME_INVALID and Cross-Origin Request Blocked.
Some context regarding the followed process around the certificates. They were installed both at the user and at the local machine levels as trusted authorities, without and with administrative rights. They were also imported into the browsers, all the while every endpoint has CORS enabled. Still, the errors remain and I am unable to seize data from a single axios GET call. As expected, when trying to communicate with the same non-secure (http) API, all calls go through without issues. Additionally, Postman and curling both yield desirable results in every case.
I have not found a way to bypass this error so that I can move on with my implementation. I have also advised several other questions here, like:
How to generate a self-signed SSL certificate using OpenSSL?
Getting Chrome to accept self-signed localhost certificate
accepting HTTPS connections with self-signed certificates
Any assistance is most welcome. I bid you all a lovely day!
I'm looking to implement a running express server using https, powering an AngularJS application. Currently I have the majority of the application running just on http, but would like to switch over. This isn't a publicly available application. Am I ok to simply use self-signed certificates to implement this in our production environment? Or should I be going through a trusted certificate authority even for internal use?
Using OpenSSL seems pretty simple to generate the key and pem files... but I feel dumb when it comes to acquiring something through a trusted authority. If it's recommended that I DO in fact use a trusted CA, and not self-signed, could someone point me in the right direction on where to go for this?
The answer is "it depends".
You can certainly use self-signed certs, but you will have to manually make sure that all your endpoints are configured to trust your self-signed certs. This is what a trusted certificate authority is used for. The browser has pre-built trust for certificates issues by various public certificate authorities and, in turn, they agree to follow certain procedures related to issuing their certificates. If you go through that process, then browsers will automatically recognized and trust https connections using your certificates (assuming everything is as expected with the connection). If you don't go through that process, then you have to manually tell each endpoint that is going to access your application to trust your certificates. For closed applications with a small number of controlled endpoints, this is very feasible. For open applications or applications with a wide variety of endpoints (random browsers, phones, etc...), this is difficult.
And, you do not want to "teach" your user base to either ignore security/certificate warnings or to blindly trust things that the browser tells them might be insecure so you want to not leave this to your users - you want to pre-configure the endpoints to trust your new self-signed certs.
To give you an example, there are home security camera systems that have web access. If the only ways you need to do web access are from 2 or 3 different browsers, it's not really a problem to use a self-signed cert and configure those 3 browsers to trust it.
But, if you had some web application that many different people would access, then it wouldn't really be practical to manage the certificate trust on a rotating set of browsers and it would just be a lot less complicated and a lot more likely to be secure to use a trusted CA.
Personally I prefer using CA trusted certificates over self-signed certificates for production environments (or even developer environments) since you need to trust/add exceptions or overwrite programatic SSL checks when you are using self-signed certificates.
If you decide to use CA trusted certificates, I recommend looking into Certbot + Let's Encrypt. It is a trusted CA and supports most of the famous servers. It is also free and really easy to use. The only downside is that you need to renew the certificate every 3 months. This too can be automated depending on your platform/server.
We can activate secure connection for backends but as oppose to front-end we get this certificate warning: (is there a solution to no get this warning?)
This is probably not the site that you are looking for!
You attempted to reach backend.xxxx.appspot.com, but instead you actually reached a server identifying itself as *.appspot.com. This may be caused by a misconfiguration on the server or by something more serious. An attacker on your network could be trying to get you to visit a fake (and potentially harmful) version of requestprocessor.qminer-trial.appspot.com.
You cannot proceed because the website operator has requested heightened security for this domain.
Help me understand
When you connect to a secure website, the server hosting that site presents your browser with something called a "certificate" to verify its identity. This certificate contains identity information, such as the address of the website, which is verified by a third party trusted by your computer. By checking that the address in the certificate matches the address of the website, it is possible to verify that you are securely communicating with the website that you intended and not a third party (such as an attacker on your network).
In this case, the address listed in the certificate does not match the address of the website that your browser tried to go to. One possible reason for this is that your communications are being intercepted by an attacker who is presenting a certificate for a different website, which would cause a mismatch. Another possible reason is that the server is set up to return the same certificate for multiple websites, including the one you are attempting to visit, even though that certificate is not valid for all of those websites. Google Chrome can say for sure that you reached *.appspot.com, but cannot verify that that is the same site as requestprocessor.qminer-trial.appspot.com which you intended to reach. If you proceed, Chrome will not check for any further name mismatches.
This is a known issue: http://code.google.com/p/googleappengine/issues/detail?id=7288
It's a limitation of SSL and browser implementations: Wildcard subdomains on appengine over https on firefox
The workaround, as per docs, is to use -dot- in place of dots in your subdomain name: subdomain-dot-domain.appspot.com
This surely works for subdomains (tested), but I'm not sure if it works for backend domains. Please test it and let us know.
Update:
I tested this on one of my test backends (forgot it's still up) and it works as expected with the -dot- workaround.
I am working on writing a OMS implementation. I have verified that service is compliant with the service and schema definitions.
When trying to set up the account in Outlook 2007 to test the service, it allows me to use an https address, but not an http address.
According to the documentation (http://msdn.microsoft.com/en-us/library/bb277363.aspx) "The URL of the OMS Web service can be either http or https, but it is https if not otherwise specified"
I have not been able to find any doucmentation that would explain why Outlook will not even let me try to do anything in the wizard if the service url does not start with https.
The error that it returns when a http address is entered is:
The web service address is incorrect or corrupted. Check the web service address or contact your administrator
I have also tried creating a temporary cert on my local machine to test the service, but outlook is rejecting the cert because it is not valid.
Is there any way to test the service or run it over http?
You are not alone in seeing this error, we've also come across this issue, one of the 3! comments on the msdn documentation also reports an issue with using http (http://msdn.microsoft.com/en-us/library/community/history/bb277363.aspx?id=2)
Apart from exposing your service as https there doesn't seem to be a way around this :(
Connection Security
To protect the information as it is
transferred over the Internet, OMS Web
services are required to support SSL
(Secure Socket Layer) encryption. SSL
can be used to establish more secure
connections on untrusted networks,
such as the Internet. SSL enables
encryption and decryption of messages
exchanged between client and server,
thereby helping to protect messages
from being read during transfer.
http://msdn.microsoft.com/en-us/library/bb277361(v=office.12).aspx#OfficeOutlook2007OMSMobileServicesGuidelinesPt1_CommunicationProtocols