In my wp8 app,
I enter a open wifi which is operated by communication operator
blocked by a portal page that needs using account and password to log in
after I post some data to a https url
I have the ability to use the wifi network to access to internet freely.
Now,I encounter a problem:
before the https connection established successfully,it will be running the Online Certificate Status Protocol (OCSP)
OCSP needs to access to CA like veriSign to verify the server certificate status
but I have no internet access at this moment.
So,my app return a Webexception whose description is "The remote server returned an error: NotFound".I think it is because of the failure of OCSP.
Based on above,I want to find a solution to sovle this:
My point is to disable the OCSP mechanism，Do you know how to do this?
And I also would like to know if there is another solution to sovle the problem.
Hope your advice,Thanks!
The way you'd do that on .NET is to set the ServicePointManager.ServerCertificateValidationCallback delegate and perform the logic you want to perform. But, unfortunately that is not yet available on Windows Phone.
There are various uservoice suggestions related to this, for example:
http://windowsphone.uservoice.com/forums/101801-feature-suggestions/suggestions/2146033-allow-self-signed-and-corporate-certificates-for-s
http://windowsphone.uservoice.com/forums/101801-feature-suggestions/suggestions/4299617-client-ssl-certificate-authentication
They don't apply to you directly, but if they end up gaining access to ServicePointManager then you'll be able to do what you want to do.
Related
I'm new to Federation Services and I'm trying to understand how ADFS works as a whole and I've started to get down into the details. I followed along with creating an app using OIDC to authenticate a user, however, within the tutorial, they specified using a "Server Application" when setting up an Application Group. This ended up not working for me so I tried setting up a "Native Application" application group for kicks and was able to successfully login.
The thing that threw me off is, I ended up hosting ADFS on a server outside of the domain in which I had my application running, so I'm confused as to how that is "native" in terms of ADFS.
I went looking for this answer within microsoft's documentation but I didn't find the information very clear.
Native Application:
"Sometimes called a public client, this is intended to be a client app that runs on a pc or device and with which the user interacts."
Server Application:
"A web application that runs on a server and is generally accessible to users via a browser. Because it is capable of maintaining its own client 'secret' or credential, it is sometimes called a confidential client."
This may seem simple to some, but I'm trying to really get a grip on what would be used when. To me it sounds like a native application is used when you're running the application natively on a pc in which the user is also using the same pc, and the server application is run remotely in which the user would not be using the same machine. Is it really that simple or am I misunderstanding?
A native application (in Microsoft speak) is something that is not browser based e.g. mobile. The code runs client side. It may use JavaScript in which case the secret key is publicly accessible. (The secret key is one of the OAuth parameters). You use ADAL / MSAL to access it.
A server application runs server side e.g a web API. The secret key is not publicly accessible. You use OWIN to access it.
These terms have no relevance to where ADFS is actually installed. Native applications typically are not domain joined.
I'm debugging a local site.
I'm getting the following message in chrome.
Your connection is not private
Attackers might be trying to steal your information from t.buyamerica.com (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_COMMON_NAME_INVALID
This is not new, and normally I just click ADVANCED and Procced ...
but lately it just stuck in a loop and display the error message again.
This is a local site therefore the key-pair is indeed invalid, but is there a way to by-pass this issue without installing a proper https for all my local (vagrant based) servers?
NOTE:
The current by-pass for me is to use the same domain as the original site, so that the local site is www.somesite.com, and the actual site is somesite.com
I solved this issue as follow:
In
System Preference -> Network -> WiFi -> Advanced -> Proxies I saw that Secure Http Proxy (HTTPS) is checked and the value for the proxy is localhost:8888
I unchecked the Secure Http Proxy (HTTPS) and it seems to solve the issue.
NOTE: this is a specific MAC issue that apparently caused by a system upgrade (my current version is 10.10.5 (14F2511) Yosemite, MacBook Air (13-inch, Mid 2012))
I never set a proxy server or run any proxy on localhost:8888
You change your local domain something like http://yourdomain.test.
Don't forget the 'http'. And if you're using .dev, change it to .test
Our setup is like this: we use a coldfusion 10 server, and files are on a local intranet. Users use a domain login to access any files over https. I'm interested in using html5 websockets, but the first attempt gave me an error because no credentials were supplied. Is there a way around this? If not, is there a recommended technology for this scenario?
The user does log in on the client side. If it's possible, what I'd really like to do here is pass those credentials when making the connection to the server.
you should be able to supply the authentication header to your web socket server before the elevation to web socket read that and send it back in the headers for the elevation (first frame) then when the browser connects it should have the authentication it needs.
if your using a custom authentication E.G in page not authentication header you can also do this by passing any custom header to your server.
Or mandate that the first thing your web client sends is the authentication details this could be something like {username_hash}.{password_hash} if they don't close the socket to them.
Do not do this.
You're now responsible for sending and encrypting the authentication credentials yourself, bypassing something that already works and is tested.
Anyone can snoop on an unencrypted websocket port. Use HTTPs for an intranet, use stable solutions, don't reinvent this wheel because it tickles your fancy.
In a couple of years some colleague will have to maintain this and will have to figure out how your homebrew version works versus something that's solid like plain browser authentication.
My advice: Leave this to the browser and to well-tested coldfusion libraries.
Compare the 2 screencaps below.
Each is to a different unsecured page where a login can be performed.
Why does Chrome warn only in the first instance and not the second?
I'm assuming it is something to do with encryption... and if yes, what exactly?
Note:
the first screencap is from a visit to: http://test.idempiere.org/
the second screencap is from a visit to a PrestaShop installation on a private VPS. PrestaShop is a popular e-Commerce CMS
If you use http connections you are always prone to many attack vectors, but they are still so used that no browser warns about them yet (although, see Mozilla proposal for deprecating unencrypted http). But you are right, those connections are definitely insecure.
However, currently HTTPS connections are checked against "known good" Certificate Authorities. If your connection does not have a trusted certificate chain, it is frowned upon.
Thankfully, these days you can get a free HTTPS validation thanks to EFF's initiative Let's Encrypt.
First the SSL Certificate is created by PrestaShop, not by an SSL company, your os does not know the issuer of the SSL Cert. And the cert is expired. You can make a certificate at letsencrypt, if you want to make it free: https://letsencrypt.org/.
That was my browser say(in german)
If I access my glassfish server at http://localhost:8080, I receive the glassfish welcome page, as it should be. But if I try to access the other http listener at https://localhost:8181, I receive a message like that:
(illustrative image)
How can I avoid this error message (thinking that I don't want my clients to see it)?
This is because GlassFish generates self-signed certificates for authentication (s1as and glassfish-instance). Your browser is (rightly) complaining that it doesn't trust these certificates, because anyone can fake them for a "man-in-the-middle" attack.
To get around this, you will need to obtain a new private key and certificate from a trusted CA to replace the self-signed ones.
These can then be imported to your keystore,jks and cacerts.jks, or you can create new keystores. If you're unfamiliar with how this works, I would suggest making backups of the originals, then importing to the existing keystores, since the communication between DAS and instances relies on certificates for authentication in a lot of places.
The GlassFish 4 Security Guide [PDF] should help you.