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
Related
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 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.
I need to create licensing server for my application.
Application should ping licensing server and if license expired stop working.
How should it be done securely? I haven't found any articles about this.
More exactly, what confuses me is how to prevent attacker to do the following
Look where I make requests (using fiddler e.g.)
Create his own server
Point his PC to that server using etc/host file.
Any best practices about this?
You can do this by enabling HTTPS on your server. Your application will need to verify the HTTPS certificate to ensure the remote host is not a fake licensing server.
This article describes the attack you mention, and how is it possible to avoid it using HTTPS.
Here's a useful sample :
Defeating Active Attackers
Verifying the server’s authenticity is key to defeating active attackers. Fortunately, TLS has this covered as well. As you recall, HTTPS is really just HTTP running over TLS. When HTTPS is implemented correctly, here is what happens to active attackers.
Because the legitimate server’s Certificate Authority (CA) verifies
ownership of the domain (yourwebsite.com), an active attacker cannot
fake the certificate. Encryption prevents the attacker from reading or
modifying any intercepted data. In short, the entire CIA triad is
satisfied and both passive and active attackers are defeated.
In your case, the roles are slightly different : the user is your application, while the potential attacker is the application user who doesn't want to pay for a license. ;)
We have an AppEngine that receives automatic data via email from remote sites and stores it into the datastore. We're using a 3rd Party SMTP host now, and /_ah/mail/ is working properly.
A lot of this data is coming from legacy microcontrollers, PLCs, smart meters and the like. They all have a configuration for email address, SMTP server, SMTP user/pass, From address, and interval.
We'd like to setup postfix on a g1-small Compute Engine instance to handle authenticated direct-SMTP connections for the incoming data, but there are no examples of anyone else doing this. Is it as simple as writing a postfix filter to take the data and POST it over to /_ah/mail on AppEngine?
Alternately, is there an easier way that we're missing? We are converting some of the devices to use POST/PUT where possible, but we have a lot of different devices, and that will take time.
Google App Engine provides an SMTP service for inbound email - messages sent to <anything>#<app_id>.appspotmail.com will be sent to /_ah/mail/<anything>. If your devices only need to send email into your system you could point them directly to GAE's mail servers.
Your suggestion of running a inbound mailserver on GCE and using it to forward to HTTP on your app is also a viable solution, and doesn't require abusing email servers. There are even companies that will do this for you!
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.